PHP2Shell var navnet på to alvorlige fejl i PHP’s kerne, som blev offentliggjort sammen med hasteopdateringer 21. oktober 2026. OpenAI beskriver forløbet som mere end en AI-assisteret opdagelse: I to måneder samarbejdede vedligeholdere, forskere og sikkerhedsleverandører om at forberede rettelser og beskyttelse inden offentliggørelsen.
18
Sagen peger på den store udfordring ved AI-assisteret sikkerhedsforskning: At finde en fejl er kun første skridt. Opdagelsen skal omsættes til en pålidelig rettelse, som de berørte kan få installeret.
Hvad fandt forskerne – og hvad bidrog AI med?
Sårbarhederne, CVE-2026-109618 og CVE-2026-109619, fik begge en CVSS-score på 9,2. Forskerne demonstrerede fjernkørsel af kode uden login på installationer af WordPress, Drupal og Joomla samt mulighed for at lække hukommelsesindhold.
3
4 Den rapporterede berørte versionsrække går fra PHP 5.4 til og med PHP 8.5.
1
Fejlene handlede om PHP’s håndtering af hukommelse. Den ene vedrørte håndtering af situationer, hvor programmet løber tør for hukommelse. Den anden involverede forældet tilstand mellem forespørgsler og såkaldt use-after-free-adfærd, ifølge rapporteringen om sårbarhederne.
3
9 Den praktiske betydning var, at problemet ikke blot lå i en bestemt hjemmeside eller app, men i PHP selv – det underliggende miljø, mange applikationer kører på.
3
4
OpenAI oplyste, at Calif fandt en kritisk fejl ved hjælp af GPT-5.6 Sol som led i initiativet Patch the Planet, og at Wiz uafhængigt opdagede og indrapporterede begge fejl.
18 Wiz’ egen omtale og anden dækning nævner også Wiz Atlas, Gemini 4 Argon og GPT-5.6 Sol som en del af Wiz’ værktøjskasse.
4
33 De tilgængelige beskrivelser skelner dog ikke tydeligt mellem de enkelte modellers opgaver. De fastslår derfor ikke præcist, hvilken model der bidrog til angrebstest eller kontrol af rettelserne.
En sekundær tidslinje, der henviser til PHP Foundation, angiver, at PHP modtog indberetninger fra Calif 11. august, Wiz 24. august og OpenAI 18. september.
6 Det er rapporterede indsendelsesdatoer – ikke nødvendigvis datoerne, hvor holdene først opdagede fejlene.
Hvorfor krævede offentliggørelsen et bredt samarbejde?
OpenAI oplyste, at arbejdet strakte sig over to måneder og samlede vedligeholdere, forskere og sikkerhedsleverandører om at forberede rettelser og beskyttelse før offentliggørelsen.
18 PHP’s vedligeholdere stod ifølge meddelelsen i spidsen for rettelserne og udgivelserne, mens forsknings- og sikkerhedspartnere bidrog med forskning, teknisk støtte og koordinering.
18
Rettelserne blev udgivet 21. oktober, en dag før den planlagte dato 22. oktober.
14 Medier rapporterede, at tidsplanen blev ændret efter lækager og tidlig tilgængelighed af rettede containeraftryk. PHP Foundation anklagede Chainguard for at have brudt embargoen. Det er en anklage, der er knyttet til fonden – ikke en tvist, som den tilgængelige rapportering endeligt har afgjort.
6
35
38
Forløbet viser dilemmaet ved koordineret offentliggørelse. Hvis tekniske detaljer holdes fortrolige, får udviklere og distributører tid til at forberede opdateringer. Men ventetiden kan efterlade brugere udsatte, hvis nogen allerede forsøger at udnytte fejlen. OpenAI’s foreslåede model beskrives i rapporteringen som en trinvis proces: Først bekræftes problemet og en rettelse udvikles; derefter får distributører tid til at forberede sig, myndighedspartnere inddrages, og informationen deles bredere, inden vejledning offentliggøres. Tidsplanen kan blive forkortet, hvis der opstår lækager eller tegn på udnyttelse.
37
41
Meldinger om angreb – og hvad de ikke beviser
Amazon oplyste, at deres MadPot-system registrerede et forsøg på at udnytte PHP2Shell 17. oktober, fire dage før den offentlige offentliggørelse. Medier beskrev også bredere forsøg på udnyttelse efter udgivelsen af rettelserne.
5 Et registreret forsøg er ikke det samme som en bekræftet overtagelse, og den tilgængelige rapportering fastslår hverken, hvordan en aktør fik kendskab til sårbarheden før offentliggørelsen, eller hvor mange servere der eventuelt blev kompromitteret.
Palo Alto Networks blev rapporteret at have identificeret mere end 22,6 millioner internetvendte installationer, som potentielt var sårbare over for PHP2Shell.
53 »Potentielt sårbare« er et estimat over eksponering – ikke en optælling af systemer, hvor fejlen med sikkerhed kan udnyttes, eller som er blevet kompromitteret.
Myndigheder opfordrede organisationer til hurtigt at håndtere fejlene. En medieomtale skrev, at myndigheder anbefalede at tage systemer offline, hvis de ikke hurtigt kunne sikres.
56 Cloudflare oplyste, at selskabet havde indført beskyttelse i sin webapplikationsfirewall før den offentlige offentliggørelse for kunder, der bruger tjenesten.
12 Sådanne tiltag kunne supplere opdateringerne, men ændrer ikke ved behovet for at kontrollere og opdatere berørte PHP-installationer.
De PHP-udgaver, der ifølge rapporteringen rettede fejlene, var 8.2.35, 8.3.36, 8.4.27 og 8.5.12.
8 Systemansvarlige bør kontrollere, hvilken PHP-distribution og version deres systemer bruger, da versionsnumre kan variere mellem udbydere.
8
Den bredere lære: Opdateringsarbejdet skal kunne følge med
OpenAI oplyste også, at virksomheden havde forpligtet sig til at stille Daybreak-adgang til en værdi af 1 mia. dollar til rådighed med tilskud for forsvarere, særligt organisationer med begrænsede sikkerhedsressourcer og ansvar for kritiske tjenester.
25 Det adresserer én del af udfordringen: at give forsvarere adgang til sikkerhedsværktøjer. PHP2Shell understreger den anden del – at få rettelser forberedt, kommunikeret og installeret på tværs af softwareøkosystemet.
AI-assisteret forskning kan hjælpe med at finde sårbarheder, men påstande om, hvad der blev fundet, hvilke værktøjer der bidrog, og om angreb lykkedes, kræver fortsat omhyggelig kildeangivelse. PHP2Shell giver grundlag for en nøgtern konklusion: En opdagelse kan give forsvarerne et værdifuldt forspring, men det forspring gør først en forskel, når vedligeholdere, leverandører og systemansvarlige kan bruge tiden på at levere og installere rettelser.