Op 21 oktober bracht PHP noodpatches uit voor twee kritieke kwetsbaarheden. Nog voordat beheerders die konden installeren, circuleerde informatie, waren gepatchte images vervroegd gepubliceerd en meldden verdedigers aanvallen. De volgende ochtend sprak de CEO van Cloudflare over miljoenen pogingen.
De relevante vragen zijn concreet: wanneer was het risico aangetoond, wat kwam vóór het einde van het embargo naar buiten, wat zagen verdedigers daadwerkelijk en welke pakketten verhelpen de fouten?
Gepubliceerd op 22 oktober 2026. Alle tijden in de tijdlijn zijn UTC; tel voor Nederland en België op deze datums twee uur op. Dit artikel maakt onderscheid tussen waargenomen pogingen en aantoonbaar succesvolle compromittering.
Wat PHP2Shell raakt
PHP2Shell omvat
CVE-2026-109618, met geheugencorruptie bij out-of-memory-fouten, en
CVE-2026-109619, met achtergebleven interne toestand tussen verzoeken. Beide kunnen leiden tot remote code execution zonder authenticatie. Vooral Apache met
mod_php loopt risico: een aangetoond aanvalspad werkt vóór de applicatiecode. Andere handlers vragen ook aandacht, maar de bereikbare paden verschillen. Zie de
OOM-advisory en
advisory over achtergebleven toestand.
Een CMS- of frameworkupdate vervangt de patch voor PHP zelf niet. Behandel de runtime als een afzonderlijk onderdeel van je inventaris, inclusief kopieën in containers, hostingpanelen en appliances.
De tijdlijn: ontdekking, disclosure en release
Samengesteld op basis van de PHP Foundation, Calif, AWS en Cloudflare. De AWS-waarneming van 17 oktober is achteraf vastgesteld, geen openbare waarschuwing van die dag.
Calif beschrijft dat op 14 augustus een werkende RCE-proof-of-concept is gedeeld en op 15 augustus door PHP is bevestigd. Het onderzoek was daarmee voorbij een theoretisch risico.
Lees het verslag van de onderzoekers. Vervolgens moest een oplossing worden geleverd voor de ondersteunde branches, zonder applicaties en extensies te breken.
De Foundation beschrijft meerdere momenten waarop informatie voortijdig naar buiten kwam. Het eerste lek van CVE-nummers en de onbedoeld gepubliceerde video van Calif gingen vooraf aan Chainguards publicatie. Eén persoon aanwijzen als de oorzaak van het hele lek doet die volgorde geen recht.
Chainguards vervroegde release: wat Lorenc bevestigt
Dan Lorenc erkent dat hij besloot eerder te publiceren. Hij verwijst naar exploitatiemeldingen en zegt dat de gepatchte builds openbaar waren, ook voor niet-klanten. In dezelfde LinkedIn-discussie betwist Nils Adermann van de Foundation de claim van bevestigde exploitatie: hij onderscheidt pogingen van succesvolle aanvallen.
Lees Lorencs verklaring en Adermanns reactie.
Dat verschil is relevant. Een gepubliceerde patch helpt verdedigers die direct kunnen updaten, maar geeft aanvallers ook een concrete wijziging om te analyseren terwijl andere distributeurs nog niet klaar zijn. Ons standpunt: bespreek een noodbesluit expliciet met de coördinatiegroep. Eenzijdig publiceren heeft gevolgen voor iedereen die nog op een bruikbaar pakket wacht.
AWS zag pogingen vóór de disclosure
Amazon Threat Intelligence meldt een exploitpoging tegen een MadPot-honeypot op
17 oktober, plus verdere pogingen tussen
02:00 en 08:00 UTC op 21 oktober. Of die vroege pogingen op echte systemen zouden slagen, was niet vastgesteld. Later beschrijft het rapport brede exploitatie na de release.
Het oorspronkelijke AWS-rapport laat open hoe aanvallers vooraf aan hun informatie kwamen.
Voor incidentonderzoek is de publicatiedatum dus een slechte begingrens. Bewaar ook bewijs van de dagen daarvoor. Bepaal de werkelijke blootstelling aan de hand van bereikbare PHP-handlers, runtimeversies, de levensduur van workers en het moment waarop de gepatchte code daadwerkelijk actief werd.
Cloudflare: van duizenden naar miljoenen
Matthew Prince
meldde duizenden pogingen in de tien uur vóór de aankondiging, tienduizenden binnen 45 minuten erna, honderdduizenden binnen twee uur en miljoenen bij zijn bericht van
22 oktober om 01:25 UTC. Dit zijn door Cloudflare gemelde aantallen pogingen, geen aantallen gecompromitteerde servers.
Cloudflare
beschrijft ook aanvalsverkeer en veranderende payloads. De WAF-bescherming voegt een verdedigingslaag toe; het bedrijf adviseert nog steeds PHP te patchen. Een WAF-alert is bruikbaar voor onderzoek. Op zichzelf bewijst zo'n melding niet dat de achterliggende server code heeft uitgevoerd.
Verhelpt PHP 8.5.12 het probleem echt?
PHP noemt 8.5.12 als gefixt voor beide PHP2Shell-CVE's. Dat geldt ook voor de onderstaande releases van de ondersteunde branches.
De officiële advisory is het uitgangspunt voor herstel.
| Branch | Eerste gefixte upstreamrelease |
|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Bij de claim “still works on 8.5.12” hoort de correctie. Onderzoeker Elise
verduidelijkte het oorspronkelijke bericht: het ging om een afzonderlijke bevinding, niet om de kwetsbaarheden die die dag waren gepatcht. Dat bericht toont geen omzeiling van de PHP2Shell-patches aan. Ook toont het niet aan dat het andere probleem onder dezelfde omstandigheden op afstand te misbruiken is. In de geraadpleegde primaire bronnen vonden we geen bevestigde omzeiling van deze twee fixes.
Oudere PHP-versies: controleer de backport
PHP leverde bij uitzondering minimale broncodebackports voor 7.4, 8.0 en 8.1. Daarmee keert de reguliere ondersteuning niet terug en is niet elke verouderde versie afgedekt. Oudere installaties hebben een aantoonbaar gefixt leverancierspakket of een upgrade naar een ondersteunde versie nodig. Alleen configuratiewijzigingen zijn onvoldoende.
Controleer de PHP-richtlijnen.
Distributiepakketten kunnen een ouder upstreamnummer behouden. Ubuntu noemt bijvoorbeeld
8.3.6-0ubuntu0.24.04.13 als gefixt PHP 8.3-pakket voor Ubuntu 24.04. Vergelijk de volledige pakketrevisie met de leveranciersmelding; concludeer niet dat de patch ontbreekt omdat
php -v nog met 8.3.6 begint.
Ubuntu USN-8948-1
Patch de runtime. Onderzoek de blootstelling.
Inventariseer elke runtime. Installeer de gefixte pakketten, herstart de betrokken workers of vervang containers en controleer de versie die daadwerkelijk webverzoeken afhandelt. Een succesvolle CLI-controle vertelt je niet welke runtime een andere FPM-pool of container gebruikt.
Correleer daarna webverzoeken met PHP-fouten, gestarte processen, bestandswijzigingen en persistentie. Een shell die door een webworker wordt gestart verdient aandacht; een losse HTTP 500 of bestandsnaam vraagt om context. Draai tijdens een toch al onrustige respons geen willekeurige “PHP2Shell-checkers” op productiesystemen.
Een patch sluit het kwetsbare pad. Als een aanvaller eerder binnenkwam, kan diens toegang blijven bestaan. Je incidentonderzoek moet die tweede vraag beantwoorden.
