Twee kritieke kwetsbaarheden in de kern van PHP, een gelekt embargo en miljoenen aanvalspogingen zonder bevestigde compromittering: wat PHP2Shell technisch is, wat overdreven is en waar je nu op let.
Listen to the episode →Op woensdag 21 oktober publiceerde de PHP Foundation een noodpatch voor twee kritieke kwetsbaarheden in de kern van PHP, de taal achter ruwweg zeventig procent van de websites met een bekende serverkant-taal. De bugs, samen PHP2Shell genoemd, laten een anonieme aanvaller code uitvoeren op de webserver. De week erna draaide het verhaal om drie vragen: hoe erg is het echt, waarom lekte een embargo dat weken was voorbereid, en wat leert het ons over een wereld waarin AI-modellen decennia oude geheugenfouten tot werkende exploits kunnen smeden?
De twee kwetsbaarheden zijn CVE-2026-109618 en CVE-2026-109619, beide met een CVSS-score van 9,2. Volgens de PHP Foundation kwam het probleem rond 2024 al voorzichtig in beeld, tijdens het oplossen van een bevinding uit een Quarkslab-audit. Destijds was misbruik theoretisch en bleven voorgestelde oplossingen steken in discussies over compatibiliteit en nieuwe denial-of-service-risico's. In augustus 2026 veranderde dat: volgens de Foundation meldde Calif op 11 augustus een onvoorwaardelijke remote code execution met dezelfde wortel, en meldde OpenAI diezelfde dag onafhankelijk dezelfde oorzaak. Wiz leverde extra aanvalsroutes aan. Let op: Wiz geeft zelf een iets andere tijdlijn, met ontdekking op 19 augustus en melding aan PHP op 24 augustus. De bronnen spreken elkaar hier dus niet helemaal na, mogelijk omdat het om verschillende deelbevindingen gaat.
Het geplande schema was een publicatie op 22 oktober. Dat liep mis. Op dinsdag 20 oktober rond 15:00 UTC doken de twee CVE-nummers op in fora en sociale media, met een verkeerde releasetijd en een verkeerde CVSS-score van 10,0. PHP trok zijn voorafgaande aankondiging naar 19:30 UTC en schoof de release een dag naar voren. Rond 20:00 UTC publiceerde Calif per ongeluk een video waarin hun exploits tegen meerdere doelen werkten; de video werd verwijderd, maar kopieën circuleerden. Op woensdag om 07:41 UTC, ruim zes uur voor de afgesproken release, publiceerde Chainguard gepatchte containerimages, wat de Foundation beschrijft als het eenzijdig breken van het embargo. Chainguard-CEO Dan Lorenc verdedigde dat met de stelling dat er al exploits in het wild waren.
Beide fouten zijn geheugenveiligheidsproblemen in de PHP-engine zelf, niet in een CMS of plugin. Daarom zijn ook WordPress-, Drupal- of Joomla-sites met schone applicatiecode kwetsbaar, aldus Sysdig.
CVE-2026-109618 is een corruptie na een out-of-memory-situatie. Wanneer PHP het geheugen opraakt, kan een longjmp() de verwerking van een request abrupt afbreken terwijl interne requestdata maar deels is geïnitialiseerd. De opruimcode werkt daarna op die ongeldige data, wat tot code-uitvoering kan leiden. Een aanvaller kan het geheugen laten overlopen met bijvoorbeeld zware multipart-requests. Bij Apache met mod_php, het hoogste risico volgens PHP, gebeurt de aanval voordat applicatiecode ook maar draait.
CVE-2026-109619 draait om verouderde globale toestand. Een PHP-worker verwerkt veel requests achter elkaar. Interne toestand van een eerder request kan blijven bestaan nadat het geheugen is vrijgegeven, en een later request gebruikt die toestand voordat de normale initialisatie hem reset. PHP bevestigt paden via session.upload_progress en, op PHP 8.5, de backtrace bij fatale fouten, en zegt expliciet dat dit niet de enige zijn.
Waarom is dit dan moeilijk uit te buiten? Door ASLR, de randomisatie van geheugenadressen. Een bruikbare exploit moet eerst een geheugenadres lekken. Het toolkit dat SOCRadar op een open aanvallersserver vond, bevat een script dat de PHP-worker recycleert, adressen via de sessiecookie lekt om ASLR te omzeilen en daarna de upload-progress-afhandeling misbruikt om een shellopdracht uit te voeren. VulnCheck meldde een eigen techniek die de twee kwetsbaarheden aan elkaar koppelt en op x86-64 met ASLR en de aanbevolen productieconfiguratie code-uitvoering haalt op PHP 8.4.26. Het bedrijf zegt geen ander publiek of commercieel exploit te kennen dat dat onder dezelfde voorwaarden doet, en deelde het alleen met klanten.
Wiz noemt de vondsten onder de zwaarste in PHP en vergelijkt de situatie met Log4Shell uit 2021. Volgens Wiz bestonden de fouten al decennia, maar was het uitbuiten ervan een zo complexe keten dat het aan de rand van het menselijk haalbare lag, en verlaagden frontier-AI-modellen die drempel sterk. Een Wiz-tijdlijn noemt Wiz Atlas en twee AI-modellen bij de ontdekking. Daar staat tegenover dat een andere analyse de AI-claim onbevestigd noemt; de officiële PHP-aankondiging bevestigt hem niet. Ik behandel het als bewering van de onderzoekers.
Wat wel vaststaat is de structurele kant. De PHP Foundation schrijft dat de vertraging "een structureel falen" was, veroorzaakt door het beslisproces en een gebrek aan middelen. Sinds 1 juli publiceerde PHP 15 CVE's en verwerkte het meer dan honderd ongeldige, dubbele of niet-reproduceerbare meldingen. AI helpt bevindingen valideren, maar mensen moeten nog steeds kiezen, implementeren en reviewen. De Foundation vraagt bedrijven, hosters en overheden om meer engine-engineers te financieren en stapt over naar meerderheidsbesluiten.
De blootstelling is enorm. Censys telde op 23 oktober 3,08 miljoen hosts en 56,6 miljoen webproperties met PHP, waarvan meer dan 34,4 miljoen PHP-diensten nog als kwetsbaar werden beoordeeld. VirusTotal schat dat slechts zo'n 272.000 hosts een ondersteunde tak (8.2 tot 8.5) draaien. Gepatcht zijn PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Voor 7.4, 8.0 en 8.1 publiceerde PHP alleen minimale broncode-backports, dus je hebt een distributiepakket, een eigen build of een upgrade nodig. Voor oudere takken, zoals 5.x, kondigde het project geen backport aan.
De operationele impact was al reëel, ondanks het gebrek aan bevestigde compromittering. Het Verenigd Koninkrijk bevestigde dat 32 digitale overheidsdiensten onbeschikbaar waren en vier gedeeltelijk, grotendeels door voorzorgsmaatregelen tijdens het patchen; het NCSC verstuurde ongeveer 50.000 waarschuwingen. Ook overheids-, school- en ziekenhuissites gingen uit voorzorg offline.
Voor een consultant: dit is een inventarisatieprobleem. Controleer wat elke site echt uitvoert, want een versiecontrole op een werkstation kan een gepatcht pakket tonen terwijl de PHP-FPM-pool in productie een andere binary draait. Denk aan hostingpanelen, appliances met ingebouwd PHP, Windows-software met php-cgi.exe en vergeten intranetten. Voor detectie raadt Picus aan te letten op werkercrashes, "Unknown on line 0"-geheugenfouten, enorme of diep geneste multipart-requests en vooral op wat PHP-processen starten: shells, curl, wget of reverse-shellpatronen vanuit php-fpm of Apache.
Er is veel lawaai. Cloudflare zag tienduizenden pogingen binnen 45 minuten na de aankondiging en miljoenen op 22 oktober. Amazon meldde een poging op 17 oktober, dagen vóór de publieke bekendmaking. Maar Sophos trok een melding van geslaagde exploitatie in en sprak van een klein aantal mislukte pogingen. Google's John Hultquist heeft geen bevestiging van grootschalige exploitatie. Mandiant-CTO Charles Carmakal zegt dat veel publieke proof-of-concepts "vibe-coded" zijn en geen code kunnen uitvoeren, maar dat sommige gevalideerde PoC's wel werken tegen standaard-mod_php, niet tegen PHP-FPM. De PHP Foundation zegt geen bewijs te hebben van geslaagd misbruik op gepatchte versies.
Het Mirai-verhaal is illustratief: Sophos en Arctic Wolf zagen pogingen om de botnetvariant Potassium te installeren, met een command-and-control-adres en DDoS-aanvallen op twee hosts in een Oekraïens netwerk als doel, maar zonder succes. Hunt.io telde 123 geteste servers, waarvan er tien het verzoek meteen weigerden en geen enkele werd geëxploiteerd. Marcus Hutchins ziet twee soorten "exploitatie" door elkaar lopen: gerichte, waarschijnlijk staatsgesteunde aanvallen en massale pogingen met PoC's die niet werken. Zijn waarschuwing is concreet: iemand heeft een scanner gebouwd, dus als er een gewapende exploit komt, hebben meerdere actoren waarschijnlijk al doellijsten klaar.
Onduidelijk blijft ook de derde bug. CVE-2026-115560 vergt volgens de PHP Foundation een "zeer onwaarschijnlijke combinatie" van configuratie en applicatiecode, namelijk het runtime omschakelen van session.serialize_handler naar php met session upload progress aan. Er komt geen noodpatch, alleen een informatief advies: zet session.upload_progress.enabled op 0. Let op: dat dekt volgens PHP niet alle varianten van CVE-2026-109619.
Eerste signaal: een publiek beschikbare, betrouwbare exploit voor ASLR-productieomgevingen. Zodra de VulnCheck-techniek of een kopie daarvan in botnet-playbooks belandt, krimpt de tijd om te patchen volgens Cobalt-CISO Andrew Obadiaru tot "dagen, geen weken". Tweede: de lange staart van niet-gepatchte 7.x- en 8.1-systemen en van embedded PHP in appliances. Derde: het volgende reguliere PHP-bugfix-release, dat de derde CVE moet dichten. Vierde: het bestuurlijke staartje, zowel de discussie over embargo's en vertrouwen in distributeurs als de vraag of bedrijven de PHP Foundation echt gaan financieren.
De hoofdles is ongemakkelijk: dat een exploit moeilijk te maken is, is geen bescherming tegen de kwetsbaarheid. Zoals McIntyre van VulnCheck het zei: technische moeilijkheid mag niet worden verward met beveiliging.