Tijdlijn: hoe kon het gebeuren dat sites offline moesten door de PHP-lekken?

Tijdlijn oehoe

Kritieke bugs in software zijn, helaas, niets nieuws. Maar het is wel zeldzaam dat allemaal websites, waaronder Tweakers, offline gaan tot er een patch is. Hoe kon het zo misgaan? Een tijdlijn van de gebeurtenissen die wij tot nu toe weten, met een dubieuze rol voor een beveiligingsbedrijf dat de patch onder embargo al had.

10 april 2025: er is een lek, maar …

De PHP Foundation bericht over de eerste externe audit in jaren. Wat er niet bij staat: iemand heeft melding gemaakt van een out-of-memorylek, een van de lekken die de afgelopen dagen zo'n grote rol speelde. Toch kon niemand toen een proof-of-concept maken van een exploit. Er was geen manier om misbruik te maken van het lek en een fix zou voor problemen zorgen met onder meer compatibiliteit en mogelijk nieuwe aanvallen. Het team besloot het daarom te laten liggen. De bug was sinds 2019 min of meer bekend.

30 juli 2026: Patch the Planet

Als onderdeel van een project om beveiliging bij PHP te professionaliseren beginnen diverse mensen bij de stichting te werken. PHP doet mee aan Patch The Planet van OpenAI. Dat is een project om onder meer AI-budget te krijgen voor het opsporen en patchen van kwetsbaarheden bij opensourceprojecten.

5 augustus 2026: het begin van vele meldingen, met dank aan AI

Ryan A van beveiligingsbedrijf Calif vindt de eerste van de twee kritieke kwetsbaarheden in PHP. Het verschil? Calif heeft een manier gevonden om op afstand code uit te voeren met de bug. Het bedrijf was op dat moment ook bezig met een exploit van WordPress. Calif gebruikt OpenAI Codex met GPT 5.6-Sol voor dat werk. Zonder AI had een exploit veel langer geduurd, claimt Calif en dat klopt natuurlijk. Het principe van het lek was immers al lang bekend.

d935be023a55b04681eccd1d2b8385b4b295e141a5df108e5e979d8d5d7124ac

— LCFR (@lcfr_hax) 5 augustus 2026

11 augustus 2026: een tweede melding

OpenAI rapporteert dezelfde bug bij de PHP Foundation. Het is onbekend hoe de bevindingen van het AI-bedrijf verschillen van die van Calif.

19 augustus 2026: een derde bedrijf vindt een exploit

Een ander beveiligingsbedrijf, Wiz, vindt het lek ook, met hulp van OpenAI GPT 5.6-Sol en Gemini 4 Argon van Google. De rapportage volgt, na verificatie van werkende exploits op onder meer WordPress en Drupal, vijf dagen later.

Alle betrokkenen doen aan responsible disclosure: een kwetsbaarheid melden, tijd geven om lekken te dichten en vervolgens op een afgesproken datum en tijd de informatie en de patch naar buiten brengen. Bij PHP zagen ontwikkelaars in hoe ernstig de bugs waren en naar eigen zeggen werkten ze vervolgens dag en nacht en in de weekenden door om de patch op tijd klaar te krijgen. De beveiligingsbedrijven maken zich op voor publicatie.

18 september 2026: een plan voor responsible disclosure

OpenAI meldt nog meer manieren om de lekken te misbruiken. Dat verandert niets fundamenteels aan het plan, maar het laat wel zien hoe ernstig de lekken waren. Er komt een plan voor publicatie. Omdat PHP de release wil coördineren met alle bedrijven die de patches ook moeten aanbieden, als onderdeel van bijvoorbeeld Linux-distro's, komt er een datum en tijd: donderdag 22 oktober, 16.00 uur Nederlandse tijd. Alle betrokkenen werken daarnaartoe.

Zoals elk groot lek moest ook PHP2Shell een mooi logo hebben.

20 oktober 2026, 15.00 uur: een lek zonder details

Op dinsdagmiddag rond vijf uur begonnen de twee CVE-codes (Common Vulnerabilities and Exposures) online te circuleren, specifiek via een post op Hacker News. Er waren weinig details bekend, maar de post vermeldde dat de kwetsbaarheden een CVSS-score kregen van 10/10. De kwetsbaarheden hebben in werkelijkheid een score van 9.2. Die score hangt af van de impact van een lek, hoe makkelijk het te exploiteren is en hoe groot de gevolgen van een exploit zijn.

Vervolgens bevestigde Watchtowr de informatie. "Neem dit serieus", vermeldt de post nog. De PHP Foundation nam het bericht in elk geval héél serieus en ondernam actie. De post op HN van 'petecooper' had dus grote gevolgen, waarvoor degene achter het account al sorry heeft gezegd. Die zou niets geweten hebben van het embargo.

Hacker News: PHP-lekken incoming, 20 oktober 15.00 uur

20 oktober, 20.00 uur: alvast een waarschuwing

Door de berichten besluit de PHP Foundation twee dingen. Ten eerste doet de organisatie een vooraankondiging om te voorkomen dat er meer onjuiste informatie circuleert. Ten tweede vervroegt PHP Foundation de release van de patch met een dag. Dat gebeurt nu op 21 oktober om 16.00 uur Nederlandse tijd. Eerder kan niet vanwege de afstemming met allerlei partijen.

En dan gaat het mis: Calif, het bedrijf dat de exploit in augustus als eerste vond, zette na de vooraankondiging een video online over de lekken. Die video ging al snel weer offline, maar sommige mensen hadden hem al opgeslagen en hij begon de ronde te doen. De video bevat genoeg gegevens om te achterhalen waar de lekken ongeveer zitten, al ontbreken details nog steeds.

21 oktober, 9.41 uur

Het nieuws is naar buiten gekomen. Veel mensen blijken te proberen een exploit te maken op basis van de informatie. Beveiligingsbedrijf Chainguard, dat images maakt van PHP-releases, zet de patch ruim zes uur vóór het afgesproken embargo online.

Dat is een zegen voor klanten van Chainguard, die alvast kunnen patchen, en een ramp voor vrijwel alle andere mensen op het internet. De PHP Foundation is duidelijk 'not amused'. "Chainguard heeft eenzijdig het embargo geschonden en gecompileerde images gepubliceerd die de oplossing bevatten. Net als andere distributeurs had Chainguard de patch vooraf ontvangen, zodat hun gebruikers direct konden updaten zodra de kwetsbaarheden openbaar werden gemaakt. Een aanvaller kon de oplossing nu in binaire vorm bestuderen, terwijl alle andere PHP-gebruikers nog op de officiële release wachtten. Hiermee werden weken aan werk van vele partijen, gericht op een gecoördineerde openbaarmaking, volledig genegeerd."

Op fora zijn er in de tijd na het openbaar maken van de patch ineens veel meer gegevens over de lekken beschikbaar. Het is onduidelijk of er werkende exploits in het wild zijn, maar het is duidelijk dat veel sites grote risico's lopen totdat de patch uitkomt.

21 oktober, 12.00 uur

Bedrijven en organisaties kunnen kiezen: online blijven en risico lopen dat data de volgende dag op straat ligt, of uit voorzorg offline gaan. Steeds meer overheden, organisaties en bedrijven kiezen ervoor om uit voorzorg offline te gaan. Systeembeheerders kunnen configuraties wijzigen om de gevolgen van de lekken te beperken, maar er is veel onbekend. In Nederland gaat het onder meer om een groot aantal sites. Tweakers gaat offline om 12.22 uur.

21 oktober, 15.45 uur: de patch komt

De patch komt uit. Vanwege de coördinatie is het niet alleen een patch voor PHP, maar ook voor softwarepakketten en besturingssystemen met PHP erin. Tweakers is binnen een paar minuten weer live. Bij andere sites duurt het langer. De patch verhelpt het probleem voor sites en diensten die vrij recente PHP-versies gebruiken. Voor de talloze sites met PHP 8.1 en lager was er niet onmiddellijk een patch. Een backport is vermoedelijk wel mogelijk met de info die online staat over PHP 7.4, 8.0 en 8.1. Ook zijn er al backports gemaakt door derden.

PHP Patch is er, zegt Kees

22 oktober: de lekken ijlen na

Zoals altijd volgt op groot nieuws kleiner, afgeleid nieuws. Er is een derde bug gevonden, maar die is niet kritiek. QNAP moet gebruikers adviseren om een van buitenaf bereikbare nas offline te halen. Veel sites zijn op donderdag nog offline en komen vermoedelijk in de loop van de dag of vrijdag pas weer online. Wellicht dat het op sommige plekken nog langer gaat duren.

Nu: is dit de toekomst?

Met het verschijnen van de patch rijzen ook vragen. Dit is een van de eerste incidenten waarbij de komst van AI verschil maakt. Hoewel de responsible disclosure fout ging door menselijk toedoen, namelijk het te vroeg online zetten van een video en het publiceren van een patch die nog onder embargo stond, speelde AI een grote rol in de afwegingen van systeembeheerders.

Om onze eigen systeembeheerder Kees Hoekzema te citeren: "Het grote probleem is dat er vroeger misschien tien mensen waren die binnen een paar uur een werkende exploit konden maken op basis van een patch. Tegenwoordig, met AI, zijn dat er veel meer. En zelfs met de relatief spaarzame informatie die naar buiten was gekomen konden diverse mensen de bug al reproduceren. Een paar jaar geleden was het niet bij mij opgekomen om offline te gaan voor een patch die een paar uur later beschikbaar zou zijn. De kans dat iemand in de tussentijd een werkende exploit zou maken en dat die persoon ons zou targetten was zo klein dat je het niet eens zou overwegen. Maar nu is dat risico veel groter geworden. Dan weet ik dat er in no time ineens mensen in onze servers zitten."

OpenAI lijkt te zeggen dat het de komende tijd meer lekken zal publiceren. "Hoe ernstig ook, deze fouten zijn slechts enkele van de aanzienlijke kwetsbaarheden die we al hebben gevonden en proberen te verhelpen. We verwachten de komende maanden een sterke toename van soortgelijke vondsten. Op basis van onze ervaringen tot nu toe stellen we een aanpak voor die past bij het AI-tijdperk, om te reageren op kritieke kwetsbaarheden in veelgebruikte software."

OpenAI heeft ook een commercieel belang daarbij. AI vindt allerlei kwetsbaarheden, hoe kun je je verdedigen? Met AI natuurlijk. Die AI kun je als abonnementen of via de api afnemen bij OpenAI. Dat neemt niet weg dat de kwetsbaarheden en exploits die met hulp van AI worden gevonden wel echt zijn.

Toch gaat het niet altijd zo fout als nu. Een video te vroeg online zetten kan iedereen overkomen. Welbewust een embargo breken en een patch alvast online zetten is wel een kwalijke praktijk en zal binnen de beveiligingswereld slecht zijn gevallen. Ernstige lekken met grote gevolgen zijn al erg genoeg. Het hoeft allemaal niet nóg spannender. Laten we vooral hopen dat alle sites, apps en diensten niet vaker bewust offline moeten gaan in afwachting van een patch.

Reacties (28)

[meowmofo]

Heeft er iemand nou al een werkende POC voor de exploit laten zien die niet bestaat uit vibe-coded onzin en 'trust me bro'-achtige blogs van allerlei security vendors? Zover ik tot nu kan opmaken is er nog niks reproduceerbaar online verschenen die de werking van de RCE demonstreren?

[-DarkShadow-]

Er is inderdaad geen werkende blackbox POC die in het wild veel schade aanricht. Zie ook deze blog van vanmorgen daarover: https://eliastaylor.com/noexploit/

In mijn ogen werden sysadmins bang gemaakt door vage berichten van PHP core ontwikkelaars. O.a. deze https://phpc.social/@Girgias/117476477429221001

The only thing I can say is that the only mitigation is patching / upgrading PHP. I sadly know too much.

"I sadly know too much", maar ze heeft nog steeds geen exploit gepubliceerd en die lijkt er ook niet te zijn.

Bij servers met een goede firewall met actuele regels en met de 2 gepubliceerde mitigaties ingesteld was het waarschijnlijk veilig genoeg voor veel websites. Een hacker had veel (AI) werk moeten verrichten om dan nog binnen te komen. In mijn ogen zeer onwaarschijnlijk dat het iemand zou lukken binnen een dag.

Er zijn natuurlijk altijd uitzonderingen. Wordpress met 30 plugins is uit zichzelf al niet zo veilig, leg die zeker even plat. Het belang van Digid hoeft niemand uit te leggen. Als het PHP team minder angsaanjagende Tweets de wereld in had gestuurd en ze wel realistisch waren geweest over de mitigaties, hadden veel websites een andere overweging gemaakt*.

Die PHP2shell video van Calif is heel spannend totdat je kijkt welke versies van platformen worden "gehacked". Dat zijn allemaal oude versies met bestaande en bekende vulnerabilities.

*-zin aangepast n.a.v. opmerking Kees

[Reactie gewijzigd door -DarkShadow- op 22 oktober 2026 15:52]

[Kees]

Maar dit is allemaal achteraf gepraat. Als ik mij bedenk wat we wisten op het moment dat we dat besluit moesten nemen, dan is dat:

- Een video die aantoont hoe ze met hun poc op talloze frameworks binnen komen in letterlijk seconden tijd
- Een tweet van die php developer met 'The only thing I can say is that the only mitigation is patching / upgrading PHP'
- Een POC met openbare code (overigens; nooit zomaar uitvoeren; voor hetzelfde geld was het malware). Maar omdat het wel veel gedeeld werd, leek het in elk geval legitiem

Dus je hebt een bug die in secondes uit te buiten is; een opmerking dat patchen de enige remedie is en veel mensen die al aan hun eigen poc/exploit werken.

Dan moet je wel heel erg zeker van jezelf zijn als je dan zegt 'onze waf is genoeg, ik blokkeer wat dingen die ik in de poc zie, en dan zijn we veilig'.

Natuurlijk, als ik met de kennis van vandaag in die meeting had gezeten, dan hadden we wellicht de site readonly gemaakt, of andere maatregelen genomen. Maar die kennis over de bugs hadden we toen gewoon nog niet.

[-DarkShadow-]

Ik ben het met je eens en ik heb 1 zin in mijn bericht aangepast.

Als het PHP team "I sadly know too much" en "exploits will start appearing 15 minutes after the patch drops" publiceert, dan kun je niet veel anders als systeembeheerder.

[Patriot]

Persoonlijk denk ik dat dit een belangrijk detail is dat relatief onbelicht blijft. Er zijn voor mijn gevoel heel erg veel claims rondom deze lekken die de wereldwijde community behoorlijk hebben opgezweept. Ik snap dat overigens wel, de gelekte video is op zich natuurlijk best wel damning maar het zou natuurlijk tegelijkertijd compleet in scene gezet kunnen zijn.

In de praktijk heb ik wel wat dingen gezien die onze websites leken te scannen, maar ik kan ook niet goed controleren of die dan daadwerkelijk wat konden natuurlijk. Ik heb in ieder geval helemaal geen verhalen gehoord van sites die daadwerkelijk gekraakt zijn. De vraag is of dat laatste dan iets van betekenis is, want het kan ook gewoon zijn dat de mensen die gekraakt zijn het nog niet weten...

[King4589]

NCSC heeft nog geen werkende POC gezien anders dan de gene die door de eerste onderzoeker in de bovenstaande Youtube video te zien is.

Zie ook Update: PHP-kwetsbaarheden nog steeds reden om direct te patchen | NCSC

[Liveonline]

interessant https://blackoutmap.net/blog/php2shell

[The Zep Man]

Voor de talloze sites met PHP 8.1 en lager is het pech. Die krijgen geen ondersteuning meer en blijven kwetsbaar.

Dit is te kort door de bocht. Je kan niet alleen vertrouwen op dat een oudere versie gelijk is aan kwetsbaar zijn.

Het kan zijn dat de patches gebackport worden, bijvoorbeeld als onderdeel van betaalde ondersteuning. Hiervoor is benodigde informatie aangeleverd voor PHP 7.4, 8.0 en 8.1.

[Reactie gewijzigd door The Zep Man op 22 oktober 2026 15:16]

[arnoudwokke]

Thanks, ik voeg het even toe

[man-o-script]

Inderdaad, neem bijvoorbeeld Ubuntu Pro ESM: https://ubuntu.com/blog/php2shell-vulnerability-fixes-available, daarmee is PHP 7.0.33 eenvoudig te updaten binnen een Ubuntu uit 2016...

[LootersV]

Wat ik niet snap, als jullie gisteren offline moesten, waarom dan niet ook vandaag?

[Vaatdoek82]

Omdat de patch er nu is?

[JTwinkelz]

De patch was er gisteren, 21 oktober, om 16:00 Nederlandse tijd.

Edit: Data in het artikel zijn inmiddels aangepast.

[Reactie gewijzigd door JTwinkelz op 22 oktober 2026 15:12]

[CH4OS]

Omdat met de berichten van vandaag (de typfout met de datums die er eerst stond daargelaten) er weinig tot geen bevestigingen zijn. De derde bug die gevonden is, is daarnaast ook niet zo kritiek. Voor de kritieken dat de bugs van gisteren niet volledig gepatcht is, is geen bewijs aangeleverd, vindbaar of door betrouwbare partijen bevestigd. De berichten van vandaag zijn dus vooralsnog meer gerucht dan waarheid.

[Mr.Analog]

Oeps, jullie zitten er denk ik een dag naast 22 oktober, 12.00 uur moet 21 oktober, 12.00 uur zijn

[pvkekem]

check: Datums kloppen niet, patch is 21 oktober uitgekomen, niet 22 oktober

[JTwinkelz]

Waarom kloppen de data niet in dit bericht? Volgens mij moet er 21 oktober staan, waar 22 oktober staat. Gisteren ging Tweakers namelijk offline en niet vandaag. En 23 oktober is morgen pas. Of leef ik in een andere dimensie? Waarom kloppen de data niet in dit bericht? Volgens mij moet er 21 oktober staan, waar 22 oktober staat. Gisteren ging Tweakers namelijk offline en niet vandaag. En 23 oktober is morgen pas. Of leef ik in een andere dimensie?


Edit: Data in het artikel zijn aangepast en kloppen nu wel.

[Reactie gewijzigd door JTwinkelz op 22 oktober 2026 15:11]

[Asitis]

Ik denk om dezelfde reden dat jij twee keer dezelfde reactie in 1 reactie hebt geschreven? Mensen maken wel eens fouten.

[JTwinkelz]

Helemaal mee eens, dan weet jij ook gelijk dat ik geen AI bot ben

[eric.1]

Hebben we nu al een exploit gezien welke werkt op een serieuze omgeving (en niet een met opzet lek-gemaakte PHP installatie in een dev-omgeving)?

De PoCs die ik voorbij heb zien komen leunen op achterlijke configuraties die je, eigenlijk, niet tegen zou moeten komen.

edit:
zoals NCSC zegt:

Online verschijnen verschillende proof-of-concepts (PoC's): voorbeelden van code waarmee onderzoekers of aanvallers een kwetsbaarheid kunnen testen of misbruiken. Uit eigen onderzoek blijkt dat de PoC's die we hebben onderzocht, nog niet succesvol zijn. Dat sluit toekomstig misbruik niet uit. Eén werkende variant kan voldoende zijn om aanvallen op grotere schaal mogelijk te maken.

[Reactie gewijzigd door eric.1 op 22 oktober 2026 15:24]

[Stetsed]

Er is all een discussie geweest rondom het topic van wat Chainguard heeft gedaan en hoe het vroeg is uitgelekt. Toevoeging daarop is dat de CEO van Chainguard op LinkedIn is doorgegaan en het is nu duidelijk dat ze precies wisten wat ze deden en dat het een bewuste keuze was om gewoon te gaan.

Hier ben ik het echt met de PHP foundation eens en denk ik dat zeggen "Not amused" een onderschatting is. Het wordt nu nog de vraag wat er met chainguard zal worden gedaan. En of ze in de toekomst dus gewoon net zoals iedereen voor de publieke patch zullen moeten wachten. Wat een absolute drama.

En ook even, er is zover ik weet nog geen publieke, betrouwbare POC voor complete RCE op dit punt. En ik ben het met de PHP foundation eens dat hoe het hier geregeld was niet echt goed was. Ook met heel veel bang maken etc.

Maar dit komt natuurlijk ook omdat zo veel mensen zeiden dat ze het hadden, en veel redelijk betrouwbare bronnen toen door gingen dat zij het konden fixen door X en Y aan te zetten. En je ziet dat sommige van deze inderdaad in de foundation's eigen advies staat. Maar dat dit primair niet echt fixes waren. Zoals het uizetten van multi part bedoelt was als een manier om een OOM te voorkomen waar de echte RCE zat.

[Reactie gewijzigd door Stetsed op 22 oktober 2026 15:27]

[3raser]

Omdat PHP de release wil coördineren met alle bedrijven die de patches ook moeten aanbieden, als onderdeel van bijvoorbeeld Linux-distro's...

Ik vraag me af hoe groot die kring is met wie de patch wordt gedeeld. Ik had nog nooit van Chainguard gehoord maar blijkbaar zijn ze invloedrijk genoeg om tot die "inner circle" te horen. Systemen als CloudLinux, Plesk en DirectAdmin blijkbaar niet. Die moeten afwachten totdat PHP met de officiële release kwam. En bij CloudLinux duurde dat bijvoorbeeld best lang.

[Reactie gewijzigd door 3raser op 22 oktober 2026 15:30]

[PtrO]

Ik vrees dat los van het lek (dat er al een jaar of 10 in zat) dit ook onderdeel is om AI meer op de commerciële kaart te zetten. Je dus als verantwoordelijk professional, wel een (hoe duur?) krachtig AI instrument moet gaan inzetten om zaken te beheren en monitoren.

Los daarvan is er met de exploit-race, een zeker risico dat tussen bekend -en patch, er (slapende) backdoors zijn gecreëerd.

Ik laat in het midden of dingen zijn bedacht of een logisch gevolg zijn van een ontwikkeling om die te kunnen benutten. Naast dat het totale ECO systeem zo een flinke boost krijg om zg. oude meuk (te moeten) uitfaseren, wie kan - of wil - er nog zonder AI ?