Kritisk sikkerhedshul i PHP: opdatér til 8.4.27, 8.3.36, 8.2.35 eller 8.5.12 nu

Den 21. oktober 2026 kl. 16.00 dansk tid udgav PHP version 8.2.35, 8.3.36, 8.4.27 og 8.5.12. De retter to huller, som PHP's sikkerhedsteam selv vurderer til 9,2 ud af 10 (CVSS v4.0), altså kritisk.

Detaljerne var allerede sivet ud dagen før under navnet "PHP2Shell", og PHP rykkede derfor udgivelsen frem. Cloudflares teknologichef skrev samme formiddag, at de så de første angreb mod PHP-sites.

Hullerne sidder i selve PHP, ikke i WordPress, PrestaShop, Magento eller et bestemt plugin. Alle sites, der kører på en PHP-version under de rettede versioner, er derfor ramt, uanset hvilket system der kører ovenpå.

I begge tilfælde kan hullet udløses, før jeres egen kode overhovedet starter:

• CVE-2026-109618: Når en forespørgsel får PHP til at løbe tør for hukommelse, mens den bliver behandlet, kan hukommelsen blive efterladt i en ugyldig tilstand. Det kan fx ske under indlæsning af formulardata og filuploads (multipart). Det kan udnyttes til at køre kode.
• CVE-2026-109619: PHP kan genbruge oplysninger fra en tidligere forespørgsel i samme proces, efter hukommelsen er frigivet. Med en bestemt opbygning af hukommelsen kan det også give fuld kodekørsel.

PHP 8.1 og ældre er udgået og får ingen officiel rettelse. Kilderne bag udnyttelsen påstår, at den virker helt tilbage til PHP 5.4.

Find den PHP-version, som jeres site faktisk kører på, ikke den der er installeret på serveren. Det står i hostingpanelet, i phpinfo() eller under Systemoplysninger i jeres CMS. Opdatér derefter:

På delt hosting er det hostingudbyderen, der lægger rettelsen på. Spørg dem i dag, hvornår det sker. Har I egen server, skal php-fpm eller webserveren genstartes efter opdateringen, ellers kører den gamle version videre i hukommelsen.

Linux-distributioner som Debian, Ubuntu og Red Hat retter ofte deres egne PHP-pakker uden at skifte versionsnummer. Her skal I tjekke distributionens sikkerhedsmeddelelse, ikke kun versionsnummeret.

Kører I på PHP 8.1 eller ældre, eller kan I ikke opdatere i dag, så er de midlertidige muligheder:

• Skift til en understøttet PHP-version, hvis jeres system kan køre på den. Test på en kopi først.
• Få en tilbageført rettelse fra hostingudbyderen. Nogle udbydere og distributioner lægger rettelsen ind i ældre versioner. Bed om at få det bekræftet skriftligt.
• Læg sitet bag Cloudflare. Cloudflare har lagt regler mod de kendte angreb ind på alle planer, også gratis. Det virker kun, hvis serveren afviser trafik, der ikke kommer gennem Cloudflare. Ellers kan en angriber gå direkte på serverens IP-adresse.
• Luk sitet midlertidigt, hvis det ikke kan beskyttes. En vedligeholdelsestilstand i jeres CMS hjælper ikke, fordi PHP behandler forespørgslen, før CMS'et når at svare.

PHP-udviklerne har selv skrevet, at indstillinger i php.ini ikke beskytter mod hullerne. Det eneste, der fjerner risikoen, er en rettet PHP.

Når I har opdateret, så tjek, om nogen nåede ind inden da. Kig efter:

• nye eller ændrede PHP-filer i webroden, især i upload-, cache- og modulmapper
• nye administratorbrugere
• nye cronjobs eller planlagte opgaver på serveren
• PHP-processer, der starter shell-kommandoer eller henter filer udefra

Finder I noget, så luk sitet, gem logfilerne og skift alle adgangskoder og API-nøgler. Gendan fra en backup, der er lavet før den 20. oktober.

For de fleste er det en opdatering i hostingpanelet eller et ticket til udbyderen. Det sværeste er sites, der er låst til en gammel PHP-version, fordi systemet ovenpå ikke kan køre på en nyere. Det gælder mange PrestaShop-shops, og det har vi skrevet en særskilt artikel om.

Vil I have hjælp til at finde ud af, hvor jeres site står, eller til at opdatere, så skriv til os. Læs også om, hvordan vi arbejder med opdateringer og patching.

Kilder

• php.net
• PHP's sikkerhedsmeddelelser: GHSA-w8hw-w9fx-j79w
• PHP's sikkerhedsmeddelelser: GHSA-6wmf-4rv5-p3rp
• Sansec
• Tenable