Rettelsen til PHP2Shell er klar, men for de fleste af de websteder, der har brug for den, er der ingen knap, man kan trykke på. Sårbarhederne findes i selve PHP, motoren, der driver alle WordPress-, Joomla- og Drupal-sider, under CMS’et, dets plugins og login-skærm. En opdatering af WordPress gør intet ved dem. Den rettede fortolker skal komme fra den, der driver serveren: hostingfirmaet, Linux-distributionens pakke eller containeraftrykket. Indtil det sker, må webstedet vente, uanset hvad ejeren gør.

Det er den del af historien, som overskrifterne om at «opdatere nu» springer over. PHP-teamet har gjort sit arbejde. At få rettelsen ud på en given server afhænger af en leveringskæde, der bevæger sig i tempoet hos sit langsomste led, og den første dag viste, hvor langt der er mellem leddene. En ejer, der ikke ved, hvor webstedets PHP kommer fra, kan ikke afgøre, hvor udsat det stadig er.

Derfor løser en WordPress-opdatering ikke problemet

Fordi fejlene ligger i fortolkeren, omfatter PHP’s sikkerhedsmeddelelse alle installationer, der håndterer webanmodninger, fra PHP-FPM og Apaches mod_php til php-cgi, FrankenPHP og LiteSpeed. The Hacker News bemærker, at selv en helt enkel «Hello World»-side på en sårbar version kan angribes. Det værste tilfælde er mod_php, hvor en enkelt anmodning fra en person uden en konto kan udløse angrebet, før nogen applikationskode kører. Derfor opdager hverken et sikkerhedsplugin eller en login-skærm noget.

Wordfence, sikkerhedsleverandøren bag WordPress, fortalte webstedsejere, som The Verge rapporterede, at rettelsen ikke kan komme via automatiske opdateringer, og at de må finde ud af, hvem der har ansvaret for deres PHP. Laravel Forge sagde det samme til sine egne kunder om deres servere: De automatiske sikkerhedsopdateringer retter ikke PHP, og Ubuntus uovervågede opdateringer henter kun pakker fra Ubuntus eget arkiv, ikke fra de tredjepartspakker, som Forge installerer PHP fra.

Disse pakkekilder blev ikke opdateret samtidigt. På udgivelsesdagen meldte webstedsadministrationstjenesten mySites.guru, at cPanels EasyApache 4 havde rettede versioner klar få minutter efter sikkerhedsmeddelelserne, mens Ondřej Surýs PPA, Ubuntus pakkekilde, som Laravel Forge selv bruger, og Remis arkiv endnu ikke havde nogen. InMotion Hosting oplyste, at deres delte servere og WordPress-servere ventede på CloudLinux-versionerne. Blandt de aktive websteder, som mySites.guru overvåger, havde 0,08 % en rettet PHP-version kl. 13.52 UTC.

Versionsnummeret kan føre dig på vildspor

Det er ikke så ligetil at kontrollere, som blot at aflæse et nummer. Ubuntu, Debian og Red Hat bagudfører sikkerhedsrettelser uden at ændre den oprindelige versionsbetegnelse, så en rettet Ubuntu 24.04-server viser stadig en 8.3.6-pakke. The Hacker News henviser til Debian og anbefaler, at man søger efter CVE-nummeret i pakkens ændringslog i stedet for at stole på versionsstrengen. mySites.guru peger på en anden faldgrube: PHP-binærfilen, som svarer på php -v på kommandolinjen, er ofte ikke den, der leverer siderne. Kontrollér derfor den version, som selve webstedet rapporterer.

Derefter skal rettelsen indlæses. Både PHP’s sikkerhedsmeddelelse og Forge understreger, at Apache, PHP-FPM og alle langvarige processer skal genstartes. Køarbejdere og tilsvarende baggrundsprocesser fortsætter med at bruge den gamle fortolker, indtil de genstartes, uanset om filerne på disken er blevet rettet.

Hvem får ingen officiel rettelse?

De rettede udgaver er PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35. De lukker CVE-2026-109618 og CVE-2026-109619, som begge har fået vurderingen 9,2 på CVSS v4.0. PHP-projektet tilbyder ikke PHP 8.1 og ældre noget, bortset fra minimale kildekoderettelser til 7.4, 8.0 og 8.1, rettet mod dem, der selv kompilerer PHP. Nogle leverandører udfylder hullet: InMotion siger, at cPanel har bagudført rettelser til deres pakker fra 7.4 til 8.1, og at CloudLinux retter alle de versioner, de distribuerer, mens CentOS 7 slet ikke får nogen rettelse.

Den gruppe er ikke lille. Dagen før udgivelsen kørte 22,7 % af de aktive Joomla- og WordPress-websteder, som mySites.guru overvåger, PHP 8.1 eller ældre, og 16,6 % brugte stadig PHP 7 eller tidligere. Ifølge virksomheden skyldes en del af problemet WordPress selv, som anbefaler PHP 8.3, men stadig angiver den for længst udfasede 7.4 som kompatibel. PHP 8.2 fik denne rettelse, men sikkerhedsunderstøttelsen ophører den 31. december 2026.

Hvad den midlertidige indstilling blokerer

Den løsning, der blev delt inden udgivelsen, hvor man sætter session.upload_progress.enabled=0, er reel, men kun delvis. PHP siger, at den blokerer de bekræftede sessionsbaserede angrebsveje til CVE-2026-109619, men ikke andre varianter, og at indstillingen skal sættes i php.ini eller serverens eller poolens konfiguration, hvorefter alle arbejdere skal genstartes. På PHP 8.5 lukker fatal_error_backtraces=0 endnu en bekræftet angrebsvej. Ingen af indstillingerne berører CVE-2026-109618. Her foreslår PHP en indstilling af memory_limit=-1, som ikke kan tilsidesættes, en lav post_max_size og begrænsninger på anmodningsstørrelsen i webserveren eller proxyen. PHP skriver selv, at der ikke findes nogen fuldstændig afhjælpning. InMotion bemærker, at WordPress, Joomla, Drupal, Magento og PrestaShop ikke bruger uploadfremskridt, så det giver dem ingen problemer at slå funktionen fra.

Cloudflare aktiverede firewallregler på alle abonnementer, hvilket teknologidirektør Dane Knecht kaldte en midlertidig løsning. Som mySites.guru påpeger, hjælper reglerne kun, hvis serveren bag dem afviser trafik, der omgår Cloudflare og går direkte til dens IP-adresse.

Angreb indtil videre

watchTowr fortæller, at deres honeypots registrerede forsøg på at udnytte begge sårbarheder på udgivelsesdagen, og at Cloudflare så angribere ændre deres payloads for at slippe forbi reglerne. Ingen kilder har bekræftet et vellykket indbrud på en bestemt server. Nogle operatører tog ingen chancer: The Hacker News skriver, at BambooHR satte sin tjeneste offline, og at offentlige tjenester i Nederlandene, herunder DigiD, gik ned som en sikkerhedsforanstaltning. EU’s CERT og Storbritanniens National Cyber Security Centre bad organisationer, der ikke kan installere rettelsen, om at isolere udsatte apps eller tage dem offline.

Sårbarhederne blev fundet af Wiz Research, Calif og OpenAI‘s Codex Security-team. Ifølge PHP Foundation dukkede tegn på hukommelsesfejlen op i en sikkerhedsrevision i 2024, men arbejdet med en rettelse gik i stå i månedsvis. Forsinkelsen kaldte fonden «et strukturelt svigt». Forskerne siger, at AI-modeller hjalp med at gøre de ti år gamle fejl til fungerende exploits på omkring en uge.

PHP havde brug for en sikkerhedsrevision, måneders fastlåsning og en læk for at få denne rettelse ud. For et websted på delt hosting er det sidste skridt at sende en supporthenvendelse.

Tags: Cloudflare, PHP, PHP2Shell, sårbarheder, WordPress