Kort sagt: Om PHP-uppgradering eller backport är rätt val beror på hur länge ert system ska fortsätta köras och hur väl backporten är belagd. En backport från den egna distributionen på ett operativsystem som stöds är en fullvärdig väg. Källkodsbackporter, tredjepartskällor och kommersiell långtidssupport för PHP 8.1 och äldre är broar med utgångsdatum. På sikt hjälper bara övergången till en PHP-version som PHP-projektet fortfarande officiellt stöder.
Varför frågan är brådskande efter PHP2Shell
Den 21.10.2026 rättade PHP-projektet PHP2Shell i versionerna 8.5.12, 8.4.27, 8.3.36 och 8.2.35. För PHP 8.1 och äldre finns inga officiella utgåvor längre, bara minimala källkodsbackporter för 7.4, 8.0 och 8.1. Enligt fackpressen berörs nästan alla versioner ända tillbaka till PHP 5.4.
Därmed står många som driver äldre system inför samma fråga: Räcker det att på något sätt lappa luckan, eller måste den uppgradering som skjutits upp i flera år komma nu? Vad en uppgradering betyder i praktiken beskriver vårt erbjudande om migrering från PHP 8.1 och äldre. Vad som gäller utan officiell uppdatering står under PHP 8.1 och äldre: vad som gäller nu. Det här inlägget hjälper med avvägningen däremellan.
Vilka typer av backport som finns
”Backport” är en samlingsterm. Det avser alltid att en rättelse från en nyare version förs över till en äldre. Vem som gör det och hur väl det är granskat skiljer sig dock starkt.
- Distributionens backport: Debian, Ubuntu, Red Hat och andra för in säkerhetsrättelser i PHP-paketen för sina releaser som stöds. Versionsnumret förblir då ofta detsamma; enligt rapporter visar till exempel Ubuntu 24.04 efter uppdateringen fortfarande 8.3.6. Rättelsen beläggs via paketets changelog och distributionens säkerhetsmeddelanden.
- Tredjepartskälla: Repositoryt sury.org av Ondřej Surý har enligt rapporter tillhandahållit byggen för alla grenar från 5.6 till 8.5. Det är inte Debians säkerhetsarkiv. Detaljer står under Repositoryt sury.org.
- Källkodsbackport från PHP-projektet: För 7.4, 8.0 och 8.1 finns minimala patchar i källkoden men inga färdiga utgåvor. Den som använder dem måste bygga PHP själv, testa och framöver själv underhålla.
- Kommersiell långtidssupport: Leverantörer som TuxCare ELS eller Zend/HeroDevs erbjuder underhåll för gamla versioner. Om och när de täcker PHP2Shell måste bekräftas skriftligt; det var inte belagt i de kända källorna. Mer om det under Långtidssupport för gamla PHP-versioner.
PHP-uppgradering eller backport: jämförelsen
| Kriterium | Uppgradering till version som stöds | Backport (beroende på typ) |
|---|---|---|
| Skydd mot PHP2Shell | Ja, med 8.2.35, 8.3.36, 8.4.27 eller 8.5.12 | Ja, om den är fullständig och belagd |
| Framtida säkerhetsuppdateringar | Officiellt fram till versionens supportslut | Bara så länge respektive leverantör underhåller |
| Underlag | Versionsnummer plus omstart | Paketets changelog med CVE-nummer, leverantörens bekräftelse |
| Arbetsinsats nu | Medelhög till hög, kompatibilitetstester behövs | Låg vid distribution, hög vid eget bygge |
| Arbetsinsats senare | Låg till nästa versionshopp | Växer med varje ny lucka |
| Risk för applikationen | Inkompatibiliteter med gammal kod och tillägg | Låg, beteendet förblir i stort sett detsamma |
| Lämplighet som varaktig lösning | Ja | Bara distributionens backport inom ramen för ett operativsystem som stöds |
Raden ”arbetsinsats senare” är den viktigaste. PHP2Shell kommer inte att vara den sista luckan. Varje månad på en version utan officiell support innebär att nästa meddelande åter väcker samma fråga.
Vilken målversion vid uppgraderingen?
Enligt php.net gäller för varje PHP-gren: två års aktivt stöd, därefter två år med enbart säkerhetsrättelser. Därav följer dessa slutdatum för säkerhetssupporten:
| Version | Säkerhetssupport till |
|---|---|
| PHP 8.2 | 31.12.2026 |
| PHP 8.3 | 31.12.2027 |
| PHP 8.4 | 31.12.2028 |
| PHP 8.5 | 31.12.2029 |
En uppgradering till 8.2 är därför bara en kort mellanstation. Den som ändå migrerar bör sikta på en version med längre horisont, så länge CMS, webbshop och tillägg stöder den. Det kontrollerar ni i tillverkarens systemkrav, inte ur minnet. Hur releasecykeln fungerar förklarar PHP-versioner och releasecykel.
Oavsett väg: Efter installationen måste alla PHP-processer startas om. En backport som bara ligger på disken skyddar inte så länge gamla workers körs i minnet.
En pragmatisk ordning för äldre system
- Direkt: Sätt övergångsåtgärder enligt php.net eller ta systemet tillfälligt från nätet om det inte finns någon belagd rättelse.
- Inom de närmaste dagarna: Installera en belagd backport, helst från den egna distributionen eller med skriftlig bekräftelse från leverantören.
- Parallellt: Pröva applikationens kompatibilitet med en version som stöds och fastställ en tidsplan.
- Inom de närmaste månaderna: Uppgradera till målversionen, förberedd i en testkopia, med reservplan.
Att se backporten som en bro och inte som ett mål är den avgörande tanken.
När ni inte behöver någon leverantör för detta
Körs er server på en Debian, Ubuntu eller RHEL som stöds och distributionen levererar backporten räcker en vanlig uppdatering med omstart och en titt i changeloggen. Det klarar en erfaren administratör själv. Hjälp lönar sig vid egenbyggen, tredjepartskällor, mycket gamla versioner eller en applikation vars kompatibilitet ingen längre överblickar.
Hur hjälper PHP SOS konkret?
- Vi prövar vilka PHP-versioner och paketkällor som körs på era servrar och om det finns en belagd rättelse.
- Vi installerar backporter, startar om och dokumenterar beviset via changeloggen.
- Vi testar er applikation i en kopia mot målversionen och pekar ut inkompatibiliteter.
- Vi planerar och följer uppgraderingen inom ramen för migreringen från PHP 8.1 och äldre.
Slutsats
Distributionens backport är en fullvärdig väg, alla andra backporter är broar. Den som sitter fast på PHP 8.1 eller äldre bör använda backporten för att vinna tid för uppgraderingen, inte för att skjuta upp den ytterligare.
Vanliga frågor
Är en backport lika säker som en uppgradering?
För den konkret rättade luckan kan en backport vara likvärdig om den är fullständig och belagd. Men den åtgärdar bara det som backporterats. En uppgradering till en version som stöds ger dessutom alla framtida officiella säkerhetsuppdateringar.
Hur ser jag att min backport täcker PHP2Shell?
I paketets changelog: Där bör CVE-numren CVE-2026-109618 och CVE-2026-109619 nämnas. Under Debian och Ubuntu visar apt-get changelog det, i RHEL-familjen rpm -q --changelog. Versionsnumret ensamt är inget belägg.
Hur länge får PHP 8.2 ännu säkerhetsuppdateringar?
Enligt php.net slutar säkerhetssupporten för PHP 8.2 den 31.12.2026. Den som i dag uppdaterar till 8.2 bör alltså planera nästa steg direkt.
Lönar sig kommersiell långtidssupport för gamla PHP-versioner?
Den kan vara en bro om en uppgradering på kort sikt är omöjlig. Låt skriftligt bekräfta om och från när PHP2Shell täcks. I de hittills kända källorna var det inte belagt.