Dinsdag kondigde PHP aan dat er woensdag om 14:00 UTC een kritieke securityrelease komt. Twee kwetsbaarheden, allebei CVSS 9.2. Details, getroffen versies en gefixte versies volgen bij de release.
Die nacht verscheen er een proof of concept. Een heap use-after-free in session.upload_progress, met de status "weaponized (lab)" en één regel waar iedereen met PHP in productie van zou schrikken: "Stock configuration is enough."
Woensdagochtend had de auteur hem gecorrigeerd: die keten was "DEAD", met "no RCE, CVSS 0.0". Wat overbleef, was een bug van gemiddelde ernst, "NOT code execution". Een paar uur later bevestigde de advisory van PHP zelf toch remote code execution via upload progress, langs een eigen route.
Een vooraankondiging hoort jou een voorsprong te geven. Deze week begon de race zodra de aankondiging online stond, voordat iemand een patch had gezien.
Woensdag om 13:34 UTC stonden de advisories online: CVE-2026-109618 en CVE-2026-109619, allebei kritiek, gefixt in PHP 8.2.35, 8.3.36, 8.4.27 en 8.5.12. Elke oudere release in die branches is getroffen. De tweede dekt de route via session.upload_progress waar de PoC op mikte.
De patch wijst de weg
Patch-diffing is niets nieuws. Je legt de gefixte versie naast de kwetsbare, en de wijziging wijst precies aan waar de bug zit. Van die diff iets maken dat ook echt werkt, kostte een ervaren onderzoeker dagen tot weken.
In juni mat Anthropic wat dat kost met een recent model. Ze zeggen het zonder omwegen: "the patch itself provides a roadmap to the bug." Op basis van securitypatches van Firefox bouwde het model helemaal zelfstandig acht werkende exploits voor code execution ("built 8 working code-execution exploits autonomously"). Op Windows: "Mythos Preview's first PoC arrived in 31 minutes and all 18 arrived within six hours."
Dat is een leverancier die zijn eigen model meet, en daar ben ik eerder al sceptisch over geweest. Maar voor de conclusie hoef je de leverancier niet op zijn woord te geloven. Hun eigen samenvatting is dat "N-hour is closer to the reality we now operate in", en de mensen die de software onderhouden zijn het daarmee eens: ze hebben deze week hun beleid erop aangepast.
Twee projecten, twee tegengestelde antwoorden
Dinsdagnacht schreef Tom Ritter namens het securityteam aan de Firefox-developers: "As AI keeps improving, our security policies are changing in response." Fixes voor sec-high- en sec-moderate-bugs worden voortaan zonder hun tests gemerged. De test, de preciezste beschrijving van de bug die er bestaat, volgt pas minstens een week nadat de gefixte Firefox uit is.
Dezelfde dag kondigde Daniel Stenberg het omgekeerde aan voor curl. Vanaf 26 oktober gaat elke kwetsbaarheid met ernstniveau LOW of MEDIUM naar een openbaar issue op GitHub. Alleen HIGH en CRITICAL blijven privé. Zijn reden: "This policy change is entirely triggered by the current avalanche of vulnerability reports that keep pouring in", en veel daarvan zijn "figured out by AI models". De afgelopen jaren bleek ruim 90% van de meldingen onder HIGH te zitten, en curl heeft niet "the bandwidth, manpower or even will" om die allemaal onder embargo af te handelen.
Verbergen tegenover openbaar maken lijkt een meningsverschil. Beide projecten verdedigen zich tegen dezelfde verschuiving, en elk beschermt wat bij hem het schaarst is:
| Project | Schaars | Wat AI goedkoop maakte | Antwoord |
|---|---|---|---|
| Firefox | tijd tussen fix en misbruik | van een patch een aanval maken | test een week achterhouden |
| curl | aandacht van de maintainers | een melding produceren | kleine bugs niet langer geheimhouden |
Firefox kan zich een week geheimhouding veroorloven, want het rolt uit via een vaste releasetrein met automatische updates, dus de meeste gebruikers hebben de fix al voordat de test verschijnt. curl kan het embargoritueel niet volhouden voor een stroom meldingen die grotendeels weinig voorstelt. Beide keuzes zijn verstandig. Jij hebt aan geen van beide iets.
Wat de paniek overslaat
Goedkope exploits betekenen nog geen massaal misbruik, en dat staat gewoon in de cijfers.
VulnCheck telt in zijn rapport over de eerste helft van 2026 1.061 kwetsbaarheden die aan AI-ondersteund onderzoek worden toegeschreven, en daarvan "only 14, or 1.3%, have been confirmed as exploited in the wild." Volgens VulnCheck komt dat ongeveer overeen met het percentage voor alle kwetsbaarheden. Een bug die een model vindt, wordt dus even vaak misbruikt als elke andere bug, en dat is zelden. De lawine waar curl onder bedolven raakt, bestaat uit meldingen, en de PHP-PoC is daar een klein voorbeeld van: een stellig "weaponized", binnen een paar uur door de eigen auteur ingetrokken.
In hetzelfde rapport staat ook het andere getal: "23.43% of KEVs showed evidence of exploitation on or before the day the CVE was published." In 2025 was dat nog 28,93%, dus het wordt niet alleen maar erger. Toch wordt bijna een kwart van de kwetsbaarheden die wél misbruikt worden, al aangevallen op of vóór de dag van publicatie. Voor die groep is "patchen binnen dertig dagen" een ritueel dat niets beschermt.
Het risico is dus niet gelijkmatig gestegen. De meeste bugs blijven stil. De paar die ertoe doen, een remote bug in de standaardconfiguratie van software waar een groot deel van het web op draait, gaan nu binnen uren van aankondiging naar werkende exploit. In die categorie valt de PHP-release: de eerste exploitpoging kwam binnen een paar uur na de aankondiging, voordat er een patch was om te lezen, en nu liggen de patches openbaar.
Bij de inbraak die Sysdig in mei ontdekte, zat er niemand achter het stuur, en de agent kwam binnen via een CVE waar al een patch voor was. Juist die tijd tussen patch en inbraak wordt korter.
Wat ik daar zelf mee doe
De projecten passen hun disclosure aan. Wat overblijft, is van jou: de tijd tussen een openbare fix en het moment dat die op je server draait.
- Meet je eigen tijd van patch naar productie. Pak de laatste drie securityupdates die je uitrolde en kijk wanneer de fix publiek werd en wanneer hij live stond. Zit daar een week tussen, dan is die week nu van iemand anders.
- Houd een noodroute die de sprint overslaat. Een securityfix hoort niet in de rij te staan achter een feature branch, een releasetrein of een reviewslot. Spreek vooraf af wie zo'n fix op een woensdagmiddag kan uitrollen, en hoe. Je pipeline remt features al af, en hier doet hij precies hetzelfde.
- Behandel een vooraankondiging als het begin van het incident. PHP gaf zo'n zeventien uur van tevoren bericht. Gebruik die tijd om elke PHP-host te vinden, na te gaan welke versie erop draait en uit welke pakketbron die komt, en de update klaar te zetten. Als de release er is, hoef je alleen nog uit te rollen.
- Ken de mitigatie die zonder patch werkt, en waar die ophoudt. De bevestigde sessieroute loopt via upload progress, en dat staat in PHP standaard aan. De advisory zegt dat
session.upload_progress.enabled=0de aangetoonde route blokkeert ("prevents the demonstrated early session producing and consuming operations"), maar ook dat het "does not mitigate the other lifecycle paths". Een volledige mitigatie via configuratie bestaat volgens PHP niet: "no complete generic configuration mitigation". Met een instelling koop je een paar uur. Pas de update maakt het gat dicht. - Weet op wie je wacht. Komt je PHP uit je distributie, dan bereikt de fix je pas als de distributie hem verpakt heeft. Die vertraging telt gewoon mee, en het loont om vóór een dag als vandaag te weten hoe lang die meestal is.
Niets hiervan is nieuw advies. Snel patchen, je inventaris kennen, een snelle route hebben. Wat veranderde, is wat het kost om het te laten liggen. Een week patchvertraging was een klein risico. Nu heeft een aanvaller met een model aan een fractie van die week genoeg om de diff te lezen.
De PHP-release kwam woensdagmiddag. De eerste exploitclaim was er eerder, al klopte hij deze keer niet. Het enige getal in dit verhaal dat jij in de hand hebt, is hoe lang je server daarna nog de oude versie draait.