Kort sagt: Af PHP-sårbarheden PHP2Shell er grenene 8.2 til 8.5 berørt frem til releaserne fra 21. oktober 2026, ifølge fagpressen næsten alle versioner helt tilbage til PHP 5.4. Den er rettet i PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35. For PHP 8.1 og ældre findes der ikke længere officielle opdateringer, kun minimale kildekode-backports til 7.4, 8.0 og 8.1.
Hvilke versioner har PHP-sårbarheden berørt?
PHP2Shell omfatter de to sårbarheder CVE-2026-109618 og CVE-2026-109619, hver vurderet til CVSS v4.0 9,2. Begge muliggør kørsel af skadelig kode på afstand uden login. Den 21. oktober 2026 kl. 14:00 UTC (kl. 16 tysk tid) offentliggjorde PHP-projektet rettelser til alle understøttede grene.
| PHP-gren | Seneste status før rettelsen | Rettet fra | Understøttelse |
|---|---|---|---|
| 8.5 | 8.5.11 | 8.5.12 | officielt understøttet |
| 8.4 | 8.4.26 | 8.4.27 | officielt understøttet |
| 8.3 | 8.3.35 | 8.3.36 | officielt understøttet |
| 8.2 | 8.2.34 | 8.2.35 | slutter den 31.12.2026 |
| 8.1, 8.0, 7.4 | alle versioner | ingen officiel release | kun minimale kildekode-backports |
| 7.3 til 5.4 | ifølge fagpressen næsten alle berørt | ingen opdatering | i årevis uden understøttelse |
Oplysningerne om 8.2 til 8.5 stammer fra meddelelserne fra php.net. Udsagnet om versionerne til og med PHP 5.4 stammer fra fagpressen; en fuldstændig officiel liste for ældre versioner findes ikke.
For ikke-teknikere i få sætninger: Står der på jeres server en version fra kolonnen »Rettet fra« eller højere, og er alle PHP-processer genstartet bagefter, er PHP2Shell lukket. Står der et ældre nummer, er enten en backport i spil, som jeres udbyder skal bekræfte, eller sårbarheden er åben. Spørg i tvivlstilfælde jeres it-afdeling eller hostingudbyder præcis om disse tre punkter: version, backport, genstart.
Berørte driftsformer
Versionsnummeret er kun det halve svar. Berørt er alle gængse måder at drive PHP på en webserver: PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP og LiteSpeed. PHP-teamet vurderer risikoen som højest ved mod_php, fordi der dér er vist en exploit, før applikationskode overhovedet kører. Enkeltheder herom under Hvorfor mod_php bærer den højeste risiko.
Ingen beskyttelse kommer fra applikationen: Uanset om det er WordPress, Shopware, TYPO3, Laravel eller en egenudvikling, lukker en opdatering af applikationen ikke sårbarheden i PHP.
Backports: når versionsnummeret bedrager
Mange Linux-distributioner og hostingudbydere leverer PHP i egne pakker. I stedet for at springe til en ny upstream-version overtager de rettelsen som backport i deres eksisterende version. Det har en praktisk følge: Det viste nummer forbliver gammelt. Et eksempel fra den aktuelle situation er Plesk, som fortsat kan vise 8.2.34, selv om fejlen er rettet.
For jer betyder det: Tabellen ovenfor gælder for de officielle releases fra php.net. Ved pakker fra jeres distribution eller fra hostingudbyderen afgør pakkestatus og udbyderens bekræftelse. Hvordan I kontrollerer begge dele, viser Kontrollér PHP-version og rettelsesstatus korrekt. Til lynkontrollen på kommandolinjen:
php -v
apt policy php8.3-fpm # Debian/Ubuntu, pakkenavnet afhænger af version og kilde
dnf info php-fpm # RHEL-familien
Et rettet versionsnummer på harddisken betyder ikke, at det kører. Først efter genstarten af alle PHP-processer arbejder serveren med den rettede kode.
Hvad gælder for PHP 8.1 og ældre?
For PHP 8.1, 8.0 og 7.4 findes der kun minimale kildekode-backports, altså rettelser i kildekoden, som nogen selv skal overtage og kompilere. Officielle releases udkommer ikke. Visse distributioner med langtidsvedligeholdelse bygger sådanne rettelser ind i deres pakker; om det gælder for jeres system, kan kun afklares ved pakkens changelog eller hos udbyderen.
På lang sigt fører ingen vej uden om en understøttet version. Hvilken PHP-version jeres CMS eller webshop kan tåle, kontrollerer I efter producentens systemkrav, f.eks. på wordpress.org, shopware.com eller typo3.org. Mere herom under PHP 8.1 og ældre: hvad der gælder nu.
Og CVE-2026-115560?
Den 23. oktober offentliggjorde php.net en henvisning om en tredje sårbarhed. Den virker kun ved en usædvanlig sessionkonfiguration. En rettet version findes efter status fra 25. oktober endnu ikke; indtil den næste almindelige bugfix-release lyder afhjælpningen session.upload_progress.enabled=0. En versionsliste forventes først med den fulde advisory.
Hvordan hjælper PHP SOS konkret?
- Fortegnelse: Vi registrerer alle PHP-versioner på jeres servere, også sekundære installationer til enkelte websites, som gerne overses.
- Sammenholdning: For hver installation afklarer vi, om der foreligger en officiel release, en distributionsbackport eller ingen rettelse.
- Opdatering med dokumentation: Via PHP-patch-servicen indspiller vi rettelsen og genstarter alle processer.
- Migreringsplan: For versioner uden officielle opdateringer planlægger vi skiftet med migreringen af PHP 8.1 og ældre og sikrer serveren indtil da.
Ofte stillede spørgsmål
Er PHP 8.3.35 stadig sikker?
Nej, medmindre jeres udbyder har indspillet en backport. 8.3.35 er den sidste status før rettelsen; PHP2Shell er rettet i gren 8.3 fra 8.3.36. Ved distributionspakker kan nummeret forblive det samme, selv om fejlen er rettet. Så tæller pakkens changelog eller udbyderens bekræftelse.
Er PHP 7.4 berørt af PHP2Shell?
Ifølge fagpressen er næsten alle versioner helt tilbage til PHP 5.4 berørt. For 7.4, 8.0 og 8.1 findes der kun minimale kildekode-backports og ingen officielle releases. Et skifte til en understøttet version er den holdbare vej.
Hvorfor viser Plesk 8.2.34, selv om der er rettet?
Distributioner og hostingudbydere overtager nogle gange rettelser som backport i deres eksisterende pakker. Versionsnummeret forbliver så det samme, fejlen er alligevel rettet. Kontrollér pakkestatus, eller lad udbyderen bekræfte rettelsen.
Hvilken PHP-version bør jeg vælge nu?
En understøttet version, som jeres applikation er frigivet til ifølge producentens systemkrav. PHP 8.2 når slutningen af understøttelsen den 31.12.2026; den, der alligevel skifter nu, bør indregne det.