Illustration: en pakke med en sikkerhedsrettelse når kun den første server i en lang række, mens resten stadig står med åbne hængelåse

Kort fortalt

  • PHP udsendte rettelser til PHP2Shell den 21. oktober ca. kl. 16.00. Det lukker hullerne i PHP, ikke på din server.
  • De Docker-tags, de fleste bygger på, havde rettelsen cirka 3½ time senere, og en container er først rettet, når den er genbygget med --pull og deployet igen.
  • Cirka 48,4 % af alle PHP-sites kører en version, som PHP-projektet ikke længere retter.
  • Tjek den PHP, der faktisk kører, med php -v og phpinfo(), og genstart PHP-FPM efter en opdatering.

Onsdag eftermiddag lukkede PHP to kritiske huller, og medierne skrev, at faren var drevet over. Men en rettelse beskytter ingen, før den er nået helt ud til den enkelte server, og knap halvdelen af alle PHP-sites kører versioner, som slet ikke får den.

Hvad der skete

Den 21. oktober 2026 udsendte PHP-projektet nødopdateringer til to kritiske sårbarheder i selve PHP, CVE-2026-109618 og CVE-2026-109619. Samlet har de fået navnet PHP2Shell og en alvorlighed på op til 9,2 ud af 10. De gør det muligt for en angriber uden login at køre kode på en webserver. Fejlen sidder i PHP selv, så ifølge forskerne bag fundet kan selv et simpelt "Hello World"-program være ramt, når det kører på en sårbar version. Hullerne blev fundet af Wiz Research, OpenAI Codex Security og Calif.

Ifølge PHP er alle installationer, der svarer på webforespørgsler, i risiko: PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP og LiteSpeed. Rettelsen findes i PHP 8.2.35, 8.3.36, 8.4.27 og 8.5.12, og PHP skriver selv, at kun en opdatering beskytter fuldt ud.

Samme eftermiddag stod der i medierne, at hullerne var lukket. Det var de også, i PHP. Men en rettelse i PHP's kildekode beskytter ikke en eneste server, før den er kommet hele vejen ud til den.

Lukket i PHP er ikke lukket på din server

En rettelse skal gennem en kæde af led, før den virker. PHP udgiver den. Linux-distributionen pakker den. Docker-images bliver bygget igen. Hostingudbyderen opdaterer. Og til sidst skal din egen server faktisk hente den nye version og genstarte. Hvert led tager tid, og hvert led kan gå i stå.

Fra rettelse til din serverFra rettelse til din server (dansk tid)19. okt.Rettelserne er klar i PHP's kildekodeUnder embargo, ingen kan hente dem20. okt. aftenPHP varsler to kritiske hullerDetaljer holdes tilbage21. okt. ca. 16.00PHP 8.2.35, 8.3.36, 8.4.27 og 8.5.12 udkommerMedierne skriver: hullerne er lukket21. okt. 17.37Første rettede Docker-tags dukker opEt af dem kan ikke hentes til almindelige servere21. okt. 19.18 til 19.33Standard-tags som php:8.3-fpm peger på rettelsenCa. 3½ time efter udgivelsenDerefterDin server er rettet, når den er genbygget eller opdateret og genstartetDet sker kun, hvis nogen gør det

Vi fulgte Docker Hub tæt den eftermiddag, fordi det er der, en stor del af moderne PHP-hosting henter sin PHP fra. De rettede versions-tags kom godt halvanden time efter udgivelsen, men et af dem, php:8.3.36-fpm-alpine, kunne klokken 18.20 stadig ikke hentes til en almindelig server: tagget fandtes, men uden et image til den mest udbredte processortype. De tags, de fleste bygger på, som php:8.3-fpm, pegede først på den rettede version omkring halv otte om aftenen, cirka 3½ time efter udgivelsen.

Selv da var ingen container rettet. En Docker-server, der allerede har det gamle image liggende, bygger videre på det, indtil nogen bygger med --pull og deployer igen. Det samme gælder klassiske servere: Debian havde rettede pakker klar i sit sikkerhedsarkiv, men en server, der kun henter fra det almindelige arkiv, ligger stadig på en sårbar version. Og en opdateret PHP-pakke hjælper først, når PHP-FPM eller webserveren er genstartet, for de kørende processer bruger den gamle kode. PHP advarede samme dag om, at det populære, frivilligt drevne pakkearkiv rpms.remirepo.net ikke ville have opdateringer den dag.

Knap halvdelen af PHP-verdenen får ingen rettelse

Det største problem er ikke de servere, der er langsomme til at opdatere. Det er dem, der ikke kan. PHP-projektet udgiver kun rettelser til PHP 8.2 og nyere. Ifølge W3Techs bruges PHP af 69,3 % af de websites, hvor man kan se serversproget. Af dem kører 26,9 % stadig PHP 7, 7,7 % PHP 5, og blandt dem på PHP 8 kører 15,2 % version 8.1 og 5,8 % version 8.0.

PHP-versioner på PHP-sitesHvilken PHP kører PHP-sites på?PHP 4 til 734,7 %PHP 8.0 og 8.113,7 %PHP 8.2 til 8.551,6 %Rød: får ikke længere rettelser fra PHP-projektet. Kilde: W3Techs, tjekket 22. oktober 2026.

Lægger man det sammen, kører cirka 48,4 % af alle PHP-sites en version, som PHP-projektet ikke længere udgiver rettelser til. Til PHP 7.4, 8.0 og 8.1 lavede PHP denne gang minimale rettelser til dem, der selv bygger PHP fra kildekoden, og nogle distributioner og leverandører af langtidssupport retter ældre versioner selv. Men for et almindeligt webhotel eller en glemt server på PHP 7 er virkeligheden, at der ikke kommer nogen opdatering at installere. Og tallene siger kun noget om hovedversionen: en server på 8.3 er kun rettet for PHP2Shell, hvis den kører 8.3.36 eller nyere.

Og PHP er kun ét lag

PHP2Shell fik overskrifterne, fordi det ramte selve sproget. Men de fleste huller sidder i de pakker, som en moderne applikation er bygget af. I vores daglige sikkerhedsoverblik følger vi lige nu 104 udbredte open source-pakker med kritiske eller alvorlige sårbarheder i ældre versioner, heraf 14 i PHP's eget pakkeøkosystem, blandt andet skabelonmotoren Twig, Drupal core og Guzzle. 23 af pakkerne har kritiske huller, 6 har huller, der endnu ikke findes nogen rettelse til, og 4 har ikke fået en eneste ændring i kildekoden i over et halvt år.

Det er samme mønster som med PHP: at en rettelse findes, betyder ikke, at den er installeret. Den skal ind i lockfilen, bygges og deployes, og det sker ikke af sig selv.

Sådan ved du, om din server faktisk er rettet

  1. Tjek den PHP, der kører, ikke den du tror kører. Kør php -v inde i containeren eller på serveren, og se også på phpinfo() fra en side, for kommandolinjen og webserveren kan bruge hver sin PHP.
  2. Byg dine images med --pull og deploy igen. Et flydende tag hjælper ikke, hvis det gamle image ligger i cachen.
  3. Genstart PHP-FPM eller webserveren efter en pakkeopdatering, og tjek at sikkerhedsarkivet er slået til.
  4. Spørg din hostingudbyder skriftligt, hvilken PHP-version de kører, og hvornår den blev opdateret. "Vi holder systemerne opdateret" er ikke et svar.
  5. Kommer du fra PHP 8.1 eller ældre, så planlæg opgraderingen nu. PHP 8.2 mister selv sine rettelser den 31. december 2026.
  6. Kør revisionsværktøjet for dine pakker, for eksempel composer audit og npm audit, og opdater lockfilen, ikke kun dine direkte afhængigheder.

Kilder

"Hullet er lukket" er det, man skriver, når rettelsen findes. Det, der beskytter dig, er at vide præcis hvilken version din server kører i dag. Vil du have det tjekket for dine egne servere og pakker, og en prioriteret liste over hvad der skal opdateres først, så skriv til mig.