Kritisk "PHP2Shell" i PHP (CVSS 9,2): Hvorfor udeblev dommedag – og hvad er den reelle risiko?

1. Hvorfor opstod den store bekymring?

Når du besøger en hjemmeside – uanset om du tjekker vejret på DMI, slår noget op på Wikipedia eller handler i en webshop – ligger der en "motor" på serveren, som opbygger siden. På langt størstedelen af internettet hedder den motor PHP.

Da nyheden om to kritiske fejl i selve PHP-kernen slap ud den 20.–21. oktober, vakte det straks stor bekymring i it-branchen. Mange frygtede en gentagelse af Log4Shell-krisen fra 2021, hvor automatiserede angrebsrobotter kompromitterede tusindvis af servere på få timer. Bekymringen skyldtes først og fremmest et rodet forløb omkring offentliggørelsen:

• Et førtidigt læk og et fængende navn: Dagen før den planlagte udgivelse lækkede selve sårbarhedsnumrene og det dramatiske øgenavn "PHP2Shell" på sociale medier sammen med rygter om den maksimale alvorsgrad på 10,0 (PHP-holdet selv vurderede den efterfølgende til 9,2).
• En uheldig video-demo: Et af de involverede sikkerhedsfirmaer kom ved en fejl til kortvarigt at publicere en demonstrationsvideo, før rettelsen var klar. Det fik bl.a. Wikimedia (folkene bag Wikipedia) til præventivt at slukke for dele af deres udviklingssystemer, mens danske og europæiske myndigheder og tjenester som DMI hasteopdaterede.
• Defekte angrebs-scripts og støj på linjen: Da hemmeligheden først var ude, lagde flere personer lynhurtigt såkaldte Proof-of-Concepts (test-angrebskoder) på GitHub. Kort efter meldte flere sikkerhedsfirmaer om "aktiv udnyttelse i vildskab".

Efterfølgende analyser fra bl.a. Recorded Future og Pentera har dog dokumenteret, at stort set alle de offentlige angrebs-scripts på udgivelsesdagen slet ikke virkede. Sikkerhedsforskeren bag de mest delte scripts måtte endda trække sin teori tilbage. Det, som overvågningssystemer verden over registrerede som "angreb", var i virkeligheden sikkerhedsforskere og automatiserede scannere, der skød i blinde med ufarlige eller defekte forespørgsler.

2. Hvorfor er sårbarhederne så svære at udnytte i virkeligheden?

For at forstå, hvorfor internettet ikke brød sammen onsdag nat, skal man kigge på, hvilken type fejl der er tale om. Det er nemlig ikke en simpel logisk fejl, hvor man bare sender en skjult kommando i en formular. Begge sårbarheder er klassiske, dybtliggende hukommelsesfejl (memory corruption) dybt inde i PHP's indre maskinrum, kaldet Zend-motoren.

Ifølge tekniske gennemgange fra bl.a. Datadog Security Labs og watchTowr skal en angriber overvinde tre enorme forhindringer for at gå fra blot at få en enkelt server-proces til at genstarte, til reelt at kunne køre egne kommandoer på serveren:

Forhindring 1: Kirurgisk timing på mikrosekundet

Den første fejl (CVE-2026-109618) opstår, når PHP indsætter data i et internt kartotek (en tabel) i arbejdshukommelsen. PHP tæller først pladsen i kartoteket som "optaget" og reserverer bagefter selve hukommelsen til indholdet.

Kun hvis serveren løber tør for tilladt hukommelse (memory_limit) i præcis dét mikrosekund mellem optællingen og selve reserveringen, går det galt: PHP afbryder opgaven i panik, og oprydningsrutinen forsøger bagefter at rydde op på en plads i kartoteket, der aldrig blev skrevet færdig. Angriberen skal altså sende en forespørgsel, der rammer serverens eksakte hukommelsesgrænse på nøjagtigt det rigtige tidspunkt.

Forhindring 2: Som at ramme en skydeskive i mørke (ASLR)

Selv hvis det lykkes at fremprovokere fejlen, vil serveren i 99,9 % af tilfældene blot afbryde den ene forespørgsel med en intern fejl (en Segmentation fault) og straks starte en frisk proces op uden skade.

For at tvinge serveren til i stedet at udføre en skadelig kommando, skal angriberen kende de nøjagtige adresser i serverens arbejdshukommelse. Men moderne servere blander kortene ved hver opstart ved hjælp af en sikkerhedsteknik kaldet ASLR (Address Space Layout Randomization). Det svarer til, at møblerne i et mørkt rum flyttes rundt hele tiden. Hvis angriberen ikke først har held til at lokke serveren til at afsløre et "kort over rummet" (et hukommelseslæk), eller hvis serveren kører en lidt anden Linux-udgave eller har ét enkelt ekstra PHP-modul installeret, rammer angrebet ved siden af.

Forhindring 3: "Worker-lotteriet" på travle hjemmesider

Den anden sårbarhed (CVE-2026-109619) kræver et to-trins-angreb: Første forespørgsel efterlader en "forgiftet" tilstand i den specifikke arbejdsproces (worker) på serveren, som næste forespørgsel derefter skal udnytte.

Men en moderne webserver (med f.eks. PHP-FPM) har ofte snesevis af parallelle arbejdsprocesser kørende samtidig til at betjene de besøgende. På en travl hjemmeside skal angriberen altså vinde i et lotteri, hvor forespørgsel nr. 2 tilfældigvis lander hos nøjagtigt den samme arbejdsproces som forespørgsel nr. 1 – vel at mærke inden en helt almindelig besøgende på hjemmesiden når at ramme den først.

3. Så... var det bare en storm i et glas vand?

Det korte svar er: Som "internet-apokalypse" ja – men som teknisk milepæl nej.

Frygten for, at automatiserede botnets i løbet af én nat ville kompromittere enhver uopdateret PHP-server på kloden med et simpelt script, holdt slet ikke vand. Den amerikanske cybersikkerhedsmyndighed CISA har endnu ikke engang tilføjet sårbarhederne til deres liste over aktivt udnyttede sårbarheder (KEV), fordi der fortsat ikke er dokumenteret verificerede overtagelser ude i virkeligheden.

Alligevel er sagen historisk vigtig. Det bemærkelsesværdige er nemlig, at denne fejl har ligget i PHP's grundkode siden PHP 5.4 – altså i mere end et årti. Sikkerhedsforskere har set lignende hukommelsesfejl før, men har hidtil konkluderet: "Interessant fejl, men alt for besværlig at lave et pålideligt angreb ud af."

Grunden til, at fejlen pludselig blev til en kritisk sårbarhed i oktober 2026, er, at forskere hos bl.a. Wiz og Datadog – hjulpet af moderne AI-værktøjer – rent faktisk lykkedes med at sammensætte komplette, fungerende angrebskæder mod standardinstallationer af bl.a. WordPress, Drupal og Joomla i laboratoriet. Ved at bruge kunstig intelligens til det slidsomme arbejde med at beregne hukommelses-afstande og kombinere små fejl, har sikkerhedsbranchen fået et vigtigt wake-up call: "For svært at udnytte" har fået en udløbsdato.

4. Hvad betyder det i praksis for dig nu?

Nu hvor panikken har lagt sig, kan vi gøre status for både hjemmesideejere og almindelige brugere:

• Sænk skuldrene, hvis du har opdateret: Hvis dit webhotel eller din it-afdeling opdaterede i dagene efter den 21. oktober – også selvom serveren stod uopdateret i 48 timer – er sandsynligheden for, at en tilfældig automatisk scanner er brudt ind i mellemtiden, forsvindende lille.
• Du skal stadig opdatere: Selvom sårbarheden er svær at udnytte lige nu, arbejder både forskere og kriminelle på at finpudse de færdige angrebskæder mod populære standard-opsætninger (som udbredte Ubuntu-, Debian- og Docker-miljøer). Når de først bliver pakket ind i færdige "peg-og-skyd"-værktøjer, falder sværhedsgraden drastisk.
• Husk de ældre hjemmesider (PHP 8.1 og ældre): Fordi PHP 8.1 og ældre versioner er udgået (End-of-Life), får de ingen officiel rettelse fra PHP-projektet (medmindre ens Linux-distribution vedligeholder egne sikkerhedsrettelser, såkaldt backporting). Ældre hjemmesider bør derfor planlægge et løft til en understøttet PHP-version.