Kort sagt: Om PHP-opgradering eller backport er det rette valg, afhænger af, hvor længe jeres system endnu skal køre, og hvor godt backporten er dokumenteret. En backport fra jeres egen distribution på et understøttet styresystem er en fuldgyldig vej. Kildekode-backports, tredjepartskilder og kommerciel langtidssupport til PHP 8.1 og ældre er broer med udløbsdato. På længere sigt hjælper kun skiftet til en PHP-version, som PHP-projektet stadig officielt understøtter.
Hvorfor spørgsmålet haster efter PHP2Shell
Den 21.10.2026 rettede PHP-projektet PHP2Shell i versionerne 8.5.12, 8.4.27, 8.3.36 og 8.2.35. Til PHP 8.1 og ældre findes der ikke længere officielle udgivelser, kun minimale kildekode-backports til 7.4, 8.0 og 8.1. Ifølge fagpressen er næsten alle versioner helt tilbage til PHP 5.4 berørt.
Dermed står mange driftsansvarlige for ældre systemer over for det samme spørgsmål: Er det nok på en eller anden måde at lappe sårbarheden, eller skal den opgradering, der er blevet udskudt i årevis, nu gennemføres? Hvad en opgradering praktisk betyder, beskriver vores tilbud om migrering fra PHP 8.1 og ældre. Hvad der gælder uden officiel opdatering, står under PHP 8.1 og ældre: Hvad der nu gælder. Dette indlæg hjælper med afvejningen derimellem.
Hvilke slags backports der findes
"Backport" er en samlebetegnelse. Det betyder altid, at en rettelse fra en nyere version overtages i en ældre. Hvem der gør det, og hvor godt det er kontrolleret, er dog meget forskelligt.
- Distributionens backport: Debian, Ubuntu, Red Hat og andre overtager sikkerhedsrettelser i PHP-pakkerne for deres understøttede udgivelser. Versionsnummeret forbliver ofte det samme; ifølge rapporter viser f.eks. Ubuntu 24.04 efter opdateringen fortsat 8.3.6. Rettelsen dokumenteres via pakkens changelog og distributionens sikkerhedsmeddelelser.
- Tredjepartskilde: Repositoryet sury.org fra Ondřej Surý har ifølge rapporter stillet builds til rådighed for alle grene fra 5.6 til 8.5. Det er ikke Debians sikkerhedsarkiv. Enkeltheder står under sury.org-repositoryet.
- Kildekode-backport fra PHP-projektet: Til 7.4, 8.0 og 8.1 findes der minimale patches i kildekoden, men ingen færdige udgivelser. Den, der bruger dem, må selv bygge PHP, teste det og fremover selv vedligeholde det.
- Kommerciel langtidssupport: Udbydere som TuxCare ELS eller Zend/HeroDevs tilbyder vedligeholdelse af gamle versioner. Om og hvornår de dækker PHP2Shell, skal bekræftes skriftligt; det var ikke dokumenteret i de kendte kilder. Mere herom under Langtidssupport til gamle PHP-versioner.
PHP-opgradering eller backport: sammenligningen
| Kriterium | Opgradering til understøttet version | Backport (afhængigt af art) |
|---|---|---|
| Beskyttelse mod PHP2Shell | Ja, med 8.2.35, 8.3.36, 8.4.27 eller 8.5.12 | Ja, hvis fuldstændig og dokumenteret |
| Kommende sikkerhedsopdateringer | Officielt indtil versionens supportudløb | Kun så længe den pågældende udbyder vedligeholder |
| Dokumentation | Versionsnummer plus genstart | Pakkens changelog med CVE-numre, udbyderens bekræftelse |
| Indsats nu | Middel til høj, kompatibilitetstests nødvendige | Lav ved distribution, høj ved egenbygning |
| Indsats senere | Lav indtil næste versionsspring | Vokser med hver ny sårbarhed |
| Risiko for applikationen | Inkompatibiliteter med gammel kode og udvidelser | Lav, adfærden forbliver stort set den samme |
| Egnethed som varig løsning | Ja | Kun distributionens backport inden for rammerne af et understøttet styresystem |
Rækken "Indsats senere" er den vigtigste. PHP2Shell bliver ikke den sidste sårbarhed. Hver måned på en version uden officiel support betyder, at den næste melding igen rejser det samme spørgsmål.
Hvilken målversion ved opgradering?
Ifølge php.net gælder for hver PHP-gren: to års aktiv support, derefter to år kun sikkerhedsrettelser. Heraf følger disse slutdatoer for sikkerhedssupporten:
| Version | Sikkerhedssupport indtil |
|---|---|
| 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 opgradering til 8.2 er derfor kun en kort mellemstation. Den, der alligevel migrerer, bør sigte mod en version med længere horisont, hvis CMS, shop og udvidelser understøtter den. Det kontrollerer I i producentens systemkrav, ikke ud fra hukommelsen. Hvordan udgivelsescyklussen fungerer, forklarer PHP-versioner og udgivelsescyklus.
Uanset vej: Efter indspilningen skal alle PHP-processer genstartes. En backport, der kun ligger på harddisken, beskytter ikke, så længe gamle workers kører i hukommelsen.
En pragmatisk rækkefølge for ældre systemer
- Straks: Sæt midlertidige foranstaltninger efter php.net, eller tag systemet midlertidigt af nettet, hvis der ikke findes en dokumenteret rettelse.
- De næste dage: Indspil en dokumenteret backport, helst fra jeres egen distribution eller med skriftlig bekræftelse fra udbyderen.
- Parallelt: Kontrollér applikationens kompatibilitet med en understøttet version, og fastlæg en tidsplan.
- De næste måneder: Opgradering til målversionen, forberedt i en testkopi, med fallback-plan.
At se backporten som bro, ikke som mål, er den afgørende tanke.
Hvornår I ikke har brug for en leverandør til det
Kører jeres server på en understøttet Debian, Ubuntu eller RHEL, og leverer distributionen backporten, er en regulær opdatering med genstart og et blik i changelog nok. Det klarer en erfaren administrator alene. Hjælp kan betale sig ved egenbygninger, tredjepartskilder, meget gamle versioner eller en applikation, hvis kompatibilitet ingen længere overskuer.
Hvordan hjælper PHP SOS konkret?
- Vi kontrollerer, hvilke PHP-versioner og pakkekilder der kører på jeres servere, og om der foreligger en dokumenteret rettelse.
- Vi indspiller backports, genstarter og dokumenterer beviset via changelog.
- Vi tester jeres applikation i en kopi mod målversionen og benævner inkompatibiliteter.
- Vi planlægger og ledsager opgraderingen inden for rammerne af migrering fra PHP 8.1 og ældre.
Konklusion
Distributionens backport er en fuldgyldig vej, alle andre backports er broer. Den, der sidder fast på PHP 8.1 eller ældre, bør bruge backporten til at vinde tid til opgraderingen, ikke til at udskyde den yderligere.
Ofte stillede spørgsmål
Er en backport lige så sikker som en opgradering?
For den konkret rettede sårbarhed kan en backport være ligeværdig, hvis den er fuldstændig og dokumenteret. Den retter dog kun det, der blev portet tilbage. En opgradering til en understøttet version giver desuden alle kommende officielle sikkerhedsopdateringer.
Hvordan ser jeg, at min backport dækker PHP2Shell?
På pakkens changelog: Dér bør CVE-numrene CVE-2026-109618 og CVE-2026-109619 være nævnt. Under Debian og Ubuntu viser apt-get changelog det, i RHEL-familien rpm -q --changelog. Versionsnummeret alene er intet bevis.
Hvor længe får PHP 8.2 stadig sikkerhedsopdateringer?
Ifølge php.net udløber sikkerhedssupporten for PHP 8.2 den 31.12.2026. Den, der i dag opdaterer til 8.2, bør derfor planlægge det næste skridt med det samme.
Kan kommerciel langtidssupport til gamle PHP-versioner betale sig?
Den kan være en bro, hvis en opgradering kortsigtet er umulig. Få skriftligt bekræftet, om og fra hvornår PHP2Shell er dækket. I de hidtil kendte kilder var det ikke dokumenteret.