PHP2Shell (CVE-2026-109618 og CVE-2026-109619): sådan tjekker og sikrer du din server

PHP2Shell: sådan tjekker og sikrer du din server

PHP2Shell er navnet på to kritiske fejl i PHP, CVE-2026-109618 og CVE-2026-109619, som blev rettet 21. oktober 2026. De lader en angriber køre sin egen kode på serveren uden at logge ind, og de rammer næsten alle hjemmesider, der kører PHP, også WordPress.

Jeg har allerede skrevet om, hvordan min dag med PHP2Shell forløb, og om det større billede med de mange sikkerhedshuller. Det her er den praktiske gennemgang: hvad er ramt, hvordan tjekker du, hvad gør du, og hvad skal du holde øje med bagefter.

Fakta om PHP2Shell

Hvad er fejlene?

Begge fejl er af typen "use-after-free": PHP kommer til at bruge et stykke hukommelse, der allerede er frigivet. Det kan en angriber udnytte til at læse data, der ikke burde være synlige, og i sidste ende til at køre sin egen kode.

• CVE-2026-109618 sidder i den funktion, der holder styr på, hvor langt en filupload er nået (session upload progress). En særligt opbygget formular-forespørgsel med en fil kan få PHP til at lække hukommelse og køre kode. Funktionen er slået til som standard.
• CVE-2026-109619 sidder i den måde, PHP bygger en fejlrapport (backtrace) på, når der sker en fatal fejl. Den kan føre til samme resultat ad en anden vej.

Opdagerne viste fjernkørsel af kode uden login mod blandt andet WordPress, Drupal, Joomla, Magento, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel, Symfony og WHMCS. Det er altså ikke et bestemt system, der er sårbart. Det er PHP under dem.

Et vigtigt punkt: upload progress bliver håndteret af PHP, mens forespørgslen læses ind, før din hjemmesides egen kode overhovedet starter. Derfor kan en firewall, der kører som WordPress-plugin, ikke stoppe den første fejl.

Tidslinjen

• 1. august 2026: Calif finder den første fejl og melder den til PHP 11. august. PHP bekræfter 15. august.
• 21. og 24. august: den anden fejl meldes, af Calif og Wiz Research.
• 20. oktober: detaljerne slipper ud, før rettelsen er klar. PHP fremrykker udgivelsen.
• 21. oktober kl. 9.43 dansk tid: Cloudflare ser de første angreb.
• 21. oktober omkring kl. 16: PHP udgiver de rettede versioner. Docker-images og hostingfirmaernes pakker følger i løbet af aftenen og de næste dage.

Hvor meget fejlene bliver udnyttet, er kilderne ikke enige om. Amazon skriver, at de bliver udnyttet bredt, mens PHP's sikkerhedsteam ikke havde set fungerende angrebskode, da rettelsen kom. Patchstack så om eftermiddagen den 21. mest afsøgning og ingen bekræftede indbrud. Gå ud fra, at du bliver forsøgt angrebet.

Sådan tjekker du, om du er ramt

1. Find den PHP-version, hjemmesiden bruger

Det er versionen på webserveren, der tæller, og den kan være en anden end den, du ser på kommandolinjen. Jeg har set servere, hvor php -v viste 7.4, mens hjemmesiden kørte 8.3.

• WordPress: Værktøjer → Webstedets helbred → Info → Server → PHP-version.
• Hostingpanelet (cPanel, hPanel, Plesk og lignende) viser versionen under PHP-indstillinger, ofte pr. domæne.
• Egen server: læg en midlertidig fil, fx version-tjek.php, i webroden med indholdet <?php echo PHP_VERSION;, åbn den i browseren, og slet den igen med det samme.
• Docker: docker exec <container> php -v viser versionen i containeren, som er den samme som webserverens.

2. Sammenlign med de rettede versioner

Nogle Linux-distributioner og hostingfirmaer retter fejlen i deres egne pakker uden at ændre versionsnummeret på samme måde. Står du med et andet nummer, så slå op i leverandørens sikkerhedsmeddelelse.

Sådan retter du det

På delt hosting

Her er det hostingfirmaet, der opdaterer PHP, ikke dig. Tjek versionen som beskrevet ovenfor, og skriv til dem, hvis den ikke er rettet. Kan du selv vælge PHP-version i panelet, så skift til en nyere hovedversion, hvis din nuværende ikke er rettet endnu. Tjek bagefter, at siden virker.

Hostingfirmaerne har ikke været lige hurtige. Nogle havde rettet om aftenen den 21., andre stod stadig på en sårbar version dagen efter.

På egen server eller VPS

1. Installér den rettede PHP-pakke fra din distribution eller den pakkekilde, du bruger.
2. Genstart PHP bagefter: PHP-FPM (fx systemctl restart php8.3-fpm) eller Apache, hvis du bruger mod_php. Kørende PHP-processer bruger den gamle kode, indtil de genstartes.
3. Tjek versionen igen via webserveren, ikke kun på kommandolinjen.

I Docker

Hent det rettede image, og byg og genstart containerne. De officielle php- og wordpress-images blev opdateret om aftenen den 21. oktober. Bygger du dine egne images, så husk at hente det nye base-image (docker build --pull). Tjek bagefter med docker exec <container> php -v.

PHP 8.1 og ældre

PHP udgiver ingen rettelse til 8.1 og ældre. Der findes rettelser i kildekoden til 7.4, 8.0 og 8.1, og nogle leverandører med forlænget support bygger dem ind i deres pakker. Den holdbare løsning er at opgradere til en understøttet PHP-version. Det kan kræve, at plugins og tema også bliver opdateret, så test først på en kopi.

Midlertidig afhjælpning, hvis du ikke kan opdatere med det samme

Indtil PHP er opdateret, kan du lukke den bekræftede vej ind ved at slå upload progress fra:

session.upload_progress.enabled = Off

PHP anbefaler også at sætte post_max_size lavt, mens man venter: 8 MB på sider uden filupload og 32 MB på sider med. Det gør angrebet sværere. Næsten ingen almindelige hjemmesider bruger upload progress, så det koster normalt ingenting at slå det fra.

Det er ikke en rettelse. Det lukker den kendte vej ind for den ene fejl, ikke selve fejlen. Opdatér stadig PHP.

Hvor indstillingen skal stå

Det afhænger af, hvordan PHP kører, og her gik det galt flere steder for mig:

• php.ini eller en fil i conf.d (egen server og Docker): PHP læser filerne i conf.d i alfabetisk rækkefølge, og den sidste vinder. Giv din fil et navn, der kommer sidst, fx zzz-php2shell.ini, ellers kan en anden fil overskrive den.
• .user.ini i webroden virker med PHP-FPM og CGI. Hos Simply virkede den med det samme, men hos Hostinger og Nordicway virkede den ikke. PHP læser filen igen med nogle minutters mellemrum, så en ændring slår ikke altid igennem med det samme.
• .htaccess med linjen php_flag session.upload_progress.enabled off virker med Apache mod_php og hos nogle LiteSpeed-hostingfirmaer. Hos Hostinger og Nordicway var det den, der virkede, mens Simply ignorerede den. Med Apache og PHP-FPM kan den give en fejl 500 på hele siden, så tjek forsiden lige efter.

Tjek, at den virker

Læg igen en midlertidig fil i webroden:

<?php echo ini_get('session.upload_progress.enabled') ? 'On' : 'Off';

Åbn den i browseren. Står der Off, virker afhjælpningen. Slet filen bagefter.

En firewall er kun en nødløsning

Cloudflare og andre har lagt regler ind mod angrebet. Det er en god ekstra sikring, men to ting er værd at vide:

• Reglerne hjælper kun, hvis serveren kun tager imod trafik via Cloudflare. Kan angriberen ramme serverens IP-adresse direkte, er der ingen beskyttelse.
• En firewall i et WordPress-plugin starter for sent til at stoppe den første fejl, som beskrevet ovenfor.

Spor efter angreb, du skal kigge efter

Fejlen blev udnyttet, før rettelsen kom, så det er ikke nok at opdatere. Kig også efter tegn på, at nogen er kommet ind i perioden før. Sikkerhedsfirmaerne peger på:

• Mange POST-forespørgsler med filer, efterfulgt af gentagne fejl 500 i adgangsloggen.
• PHP-processer der går ned eller genstarter uden forklaring.
• Usædvanligt store PHPSESSID-cookies i forespørgslerne.
• Nye eller ændrede PHP-filer i mapper, hvor der normalt ikke ligger kode, fx uploads.
• Nye brugere med administratoradgang, nye planlagte opgaver (cron) eller ukendte omdirigeringer.

Finder du sådanne spor, så behandl serveren som kompromitteret: skift alle adgangskoder og nøgler, som serveren kender (database, wp-config.php, API-nøgler og mail), gendan fra en backup fra før angrebet, og opdatér, før siden kommer online igen. Min guide til hvad du gør, hvis din WordPress er hacket gennemgår det trin for trin.

Ofte stillede spørgsmål

Er min WordPress sikker, når WordPress og plugins er opdateret? Nej, ikke mod PHP2Shell. Fejlen sidder i PHP, ikke i WordPress. Det er PHP-versionen, der skal være rettet.

Hjælper et sikkerhedsplugin som Wordfence? Ikke mod den første fejl, fordi PHP håndterer upload progress, før pluginet starter. Pluginet er stadig nyttigt til at opdage ændrede filer og nye brugere bagefter.

Jeg har ikke en webshop eller filupload. Er jeg ramt? Ja, sandsynligvis. Fejlen virker i PHP's standardopsætning og kræver ikke, at din side selv har en uploadformular.

Jeg har slået session.upload_progress fra. Er jeg færdig? Nej. Det lukker kun den kendte vej ind for den ene af de to fejl. Opdatér PHP.

Hvad med PHP 7.4 eller 8.0? De har været uden officiel support i flere år og får ingen officiel rettelse. Spørg dit hostingfirma, om de har bygget rettelsen ind, og planlæg en opgradering.

Kilder

• Calif: PHP2Shell, opdagernes gennemgang og tidslinje
• Sansec: PHP2Shell, versioner og afhjælpning
• Patchstack: PHP major vulnerability alert
• watchTowr: PHP2Shell
• Tenable: ofte stillede spørgsmål om PHP2Shell
• Upwind: første vurdering af PHP2Shell
• PHP.net: udgivelser