OpenAI, Wiz en Calif werkten voor lek al maanden aan fix voor PHP-kwetsbaarheden

Cybersecuritybedrijven Wiz, Calif en ChatGPT-aanbieder OpenAI werkten al twee maanden aan een oplossing voor de recente PHP-kwetsbaarheden. Informatie over die kwetsbaarheden lekte onlangs uit, waardoor wereldwijd talloze sites uit voorzorg offline gingen. Inmiddels is er een beveiligingsupdate voor de kwetsbaarheid.

Wat is PHP?

PHP is een veelzijdige scriptingtaal die dynamische webpagina's kan aanmaken. Wereldwijd gebruikt 69,3 procent van alle websites PHP. PHP vormt de basis voor het veelgebruikte WordPress en wordt ook gebruikt in Joomla, Drupal, Magento en andere websoftware. Tweakers schreef een uitgebreid achtergrondverhaal over de kwetsbaarheid.

In een blogpost schrijft OpenAI dat Wiz en Calif onafhankelijk van elkaar de kwetsbaarheid ontdekten. Volgens Wiz werkten de partijen samen met de PHP-makers aan de verificatie van de ontdekking en de daaropvolgende oplossing. De kwetsbaarheden werden in augustus al ontdekt en de PHP-makers wisten er sinds 21 september van.

Het beveiligingsbedrijf gebruikte naar eigen zeggen GPT-5.6 Sol en stelt dat Gemini 4 Argon een 'bijdrage van onschatbare waarde' leverde. Ook Google Cloud, Cloudflare, AWS, Microsoft, Akamai en andere partijen hebben aan het project meegewerkt. OpenAI lijkt het project te hebben gecoördineerd onder het Patch the Planet-project.

Bron: Wiz

Vroegtijdig uitgelekt

Informatie over de kritieke kwetsbaarheden verscheen om nog onbekende redenen te vroeg online. Voor zover bekend ging het om een lek. Daardoor moesten de makers van PHP eerder dan gepland een beveiligingsupdate uitbrengen.

Omdat informatie over de kwetsbaarheid nog voor de release van de update online werd verspreid, konden kwaadwillenden die al uitbuiten. Daarom gingen websites massaal uit voorzorg offline. Ook Tweakers was daardoor enkele uren offline.

OpenAI komt binnenkort met een versiechecker voor PHP waarmee gebruikers de gebruikte PHP-versie kunnen controleren. Daar komt ook een Codex-variant uit die kan helpen bij het identificeren van de betreffende kwetsbaarheid in bestaande code. Het is niet duidelijk wanneer dat gebeurt. De makers van de PHP-programmeertaal raden gebruikers nadrukkelijk aan om direct de patch te installeren.

Reacties (50)

[pdidi]

Het lek kwam door Calif, aldus The PHP Foundation:
Calif, one of the security firms that had reported the issues mistakenly published a video. It showed their proof of concept working against a number of targets and revealed a few additional, though limited, details about the vulnerabilities. Copies of the deleted video started circulating on social media soon after. The video contributed to accelerated development of various PoCs (exploitation proof of concepts), which then increased circulation on October 21st.

[olafmol]

Wel bijzonder dat een gerommeerd(?) security bedrijf zo'n dodgy video maakt, met een dansend anime meisje erbij. Er hebben hier volgens mij wel een aantal partijen en mensen flinke steken laten vallen. Het einde van "responsible disclosure?

[xrf]

Als ik de blogpost lees was dat maar een deeltje van het geheel. Een grotere probleem was een ander bedrijf dat besloot om uren voor de afgesproken deadline images met de fix online te zetten:

On October 21st at 07:41 UTC, more than six hours before the coordinated release, Chainguard unilaterally broke the embargo and published built images containing the fix.

En de bron van de aanvankelijke geruchten is nog onbekend.

De hele sectie uit de blogpost:

Leak and disrupted disclosure

The coordinated disclosure of these vulnerabilities worked well until 2 days ahead of the targeted release date.

On Tuesday, October 20th, at around 15:00 UTC, the two CVE IDs began circulating on online forums and social media. They came with a wrong release time and a wrong CVSS score of 10.0 (the actual score is 9.2). No technical details leaked. In response, the PHP project brought its pre-announcement forward and published it at 19:30 UTC. It also moved the release from October 22nd, 14:00 UTC, to October 21st, 14:00 UTC. Distributors were still packaging the fix, so releasing immediately would have left many users without an easy way to update. Moving the release forward by one day was the best compromise between acting quickly, giving people time to prepare, and making sure everyone had a simple update path when the vulnerabilities were disclosed.

As a result of the leak and pre-announcement around 20:00 UTC, Calif, one of the security firms that had reported the issues mistakenly published a video. It showed their proof of concept working against a number of targets and revealed a few additional, though limited, details about the vulnerabilities. Copies of the deleted video started circulating on social media soon after. The video contributed to accelerated development of various PoCs (exploitation proof of concepts), which then increased circulation on October 21st.

Mitigation advice we started providing to a few critical infrastructure providers around Oct 20th 23:00 UTC, may have leaked as well. The PHP security team closely monitored and inspected appearing PoCs after the leak but did not identify any functional exploits at the time of release/public disclosure.

On October 21st at 07:41 UTC, more than six hours before the coordinated release, Chainguard unilaterally broke the embargo and published built images containing the fix. Like other distributors, Chainguard had received the patch in advance so its users could update the moment the vulnerabilities were disclosed. Any attacker could now study the fix in binary form while every other PHP user was still waiting for the release. This disregarded weeks of work by many parties toward a coordinated disclosure.

[Reactie gewijzigd door xrf op 21 oktober 2026 18:10]

[YannickSpinner]

Bedankt voor de toevoeging! Dit schrijf ik even in een nieuw bericht met jou als submitter

[Stetsed]

Wow.. ik denk dat ik will focussen op dit deel van de PHP announcement:

“On October 21st at 07:41 UTC, more than six hours before the coordinated release, Chainguard unilaterally broke the embargo and published built images containing the fix. Like other distributors, Chainguard had received the patch in advance so its users could update the moment the vulnerabilities were disclosed. Any attacker could now study the fix in binary form while every other PHP user was still waiting for the release. This disregarded weeks of work by many parties toward a coordinated disclosure.”

Ik denk dat ik nog nooit van een situatie zoals dit hebt gehoord, dat een respected security bedrijf zulke acties neemt. De wiz situatie was een fout en een begrijpelijke, maar in die situatie was het alleen de demo en is er dus blijkbaar geen POC gemaakt die echt werkte zoals de vulnerability. Maar chain guard koos dus gewoon om hem te publish en.

Voor de mensen die het niet weten, in dit soort situaties wordt er vaak een patch all gestuurd naar verschillende partijen zoals chainguard, maar ook maintainers van Debian etc zodat hij in een keer overall gefixt kan worden. Maar hier staat dan een embargo zodat iedereen tijd heeft. Maar hier heeft chainguard dus zelf gekozen om deze te negeren

[olafmol]

Exact, het proces van responsible disclosure is hier fout/kapot gegaan. Niet PHP of een CVE of een exploit, want de bug was zelfs al vanaf 2019 bekend: https://bugs.php.net/bug.php?id=78876

[Phosoup]

Betekent het dan ook dat men al 7 jaar gebruik heeft kunnen maken van deze bug?

[olafmol]

13 jaar, vanaf php 5.4. Vanaf 2019 was het publiek bekend.

[Reactie gewijzigd door olafmol op 21 oktober 2026 19:14]

[Nark0tiX]

Jaa waarschijnlijk wel, neem aan dat verschillende statelijke actoren hier graag gebruik van maakte. Die zullen niet blij zijn met deze patch

[Nark0tiX]

https://web.archive.org/web/20260316032239/https://bugs.php.net/bug.php?id=78876

Ze hebben die pagina snel offline gehaald, in het archief staat die nog.

[olafmol]

Jesus wat een clusterfuck dit.

[Ventieldopje]

Originele pagina is gewoon live hoor.

[Nark0tiX]

Klopt ze hebben hem weer online gezet

[rikster]

Eh, 'OpenAI komt binnenkort met een versiechecker voor PHP waarmee gebruikers de gebruikte PHP-versie kunnen controleren'. php -v wel eens gezien?

Of moet dit de 'remote' gebruiker laten zien welke php-versie een website gebruikt? Leuke tool voor een hacker...

[Cyb]

Of moet dit de 'remote' gebruiker laten zien welke php-versie een website gebruikt? Leuke tool voor een hacker...

Daar heb je vaak geen tool voor nodig, vaak (72% in 2015) wordt het al in de "x-powered-by" HTTP header gestopt. Bijna elke browser heeft wel iets van een ingebouwde developer tool, waarmee je zelf in de HTTP response kan zien of x-powered-by header aanwezig is, en welke PHP versie het aangeeft.

Voor degenen die willen weten of een site waar je gegevens draait mogelijk op een oude PHP versie draait:

1. Bezoek de site
2. Druk op CTRL+SHIFT+i
3. Ga naar de "network" tab
4. Doe een page refresh
5. Klik op HTTP response van de bovenste request, of eentje met type "html" of iets dergelijks
6. Kijk of je in de HTTP response de "x-powered-by" header ziet. Deze moet minimaal PHP 8.5.12, 8.4.27, 8.3.36 of 8.2.35 zijn om gepatched te zijn.
7. Indien de site een oude PHP versie draait, neem contact op met de site en vertel ze dat deze vatbaar is voor PHP2Shell.

[Reactie gewijzigd door Cyb op 21 oktober 2026 17:43]

[BobV]

Het is vrij standaard om die header niet meer mee te sturen, juist om zo min mogelijk kenbaar te maken. Als je de header nog hebt, is het advies om die zo snel mogelijk uit te schakelen.

[Cyb]

"Vrij standaard" als het gaat om best practices. Maar niet "standaard" als instelling om het niet mee te sturen. In 2015 gebruikte zo'n 72% van de PHP sites gewoon wel de "x-powered-by" header.

[BobV]

2015 is meer dan 10 jaar geleden. Ondertussen is de default van `expose_php` gewoon `Off` (in ieder geval met de Sury packages).

[Reactie gewijzigd door BobV op 21 oktober 2026 17:46]

[Cyb]

Of het wel of niet default "off" staat hangt maar net af waar je het vandaan haalt.
Hier op de officiele PHP site staat het helemaal niet "off": https://www.php.net/manual/en/ini.core.php
Staat standaard gewoon aan.

[Reactie gewijzigd door Cyb op 21 oktober 2026 17:49]

[rikster]

Exact. Dus wat gaat OpenAI nou bieden? En is dat leuk voor hackers of niet? Want dat je die header niet meestuurt heeft uiteraard nou net die reden.

[Jester-NL]

Ik ben recent een hele tijd bezig geweest om die regel weg te krijgen... en uiteindelijk is dat niet door mij, maar door de systeembeheerder van mijn hoster opgelost, omdat dat redelijk hard vanuit Plesk werd meegestuurd

[rikster]

Nogmaals: wat gaat de nieuwe tool van OpenAI dan precies bieden wat je nu al niet hebt?

BTW Ik was uiteraard ironisch bezig met mijn php -v. Ik sleutel nog maar weinig aan web-sites (en mijd iets als WordPress dan liefst ook nog eens, niks mis met ultraplat html voor de dingen die ik er in doe ) maar zelfs ik weet dat je dit soort dingen kunt opvragen (omdat anders plug-in xyz niet werkt oid.).

[Cyb]

Nogmaals: wat gaat de nieuwe tool van OpenAI dan precies bieden wat je nu al niet hebt?

Dat is niet zo moeilijk om te bedenken. Kan bijvoorbeeld een browser extensie zijn om het automatisch te checken zodra een gebruiker op een site komt, of gewoon een web pagina waar je een url invoert en je terugkrijgt of de site mogelijk een oude versie draait. (Met nadruk op "mogelijk", want als de header ontbreekt is het niet duidelijk.)

[Rockster34]

Kijk of je in de HTTP response de "x-powered-by" header ziet. Deze moet minimaal PHP 8.5.12, 8.4.27, 8.3.36 of 8.2.35 zijn om gepatched te zijn.

Dit is ook niet echt bepaald waterdicht als jij alleen LTS volgt van bijvoorbeeld Ubuntu (nu op 26.04.1) dan krijg je een backported versie van 8.5.12 maar je X-powered-by zegt wel degelijkt 8.5.4 dus om dan contact op te nemen met een website is dan ook een beetje raar als het wel gaat om de 8.5.4-0ubuntu1.5 versie 😅

Het beste is om sowieso je X-powered-by uit te zetten en dat word ook aangeraden om het "Low-hanging fruit" verwijderd voornamelijk voor automation tools.

[Cyb]

dus om dan contact op te nemen met een website is dan ook een beetje raar als het wel gaat om de 8.5.4-0ubuntu1.5 versie

Beter uit voorzorg wel contact opnemen, dan dat je te maken hebt met een site waar je klantgegevens staan terwijl die site mogelijk zo lek is als een mandje. De eigenaar kan dan altijd nog x-powered-by/expose_php uitschakelen, zodat deze niet nog meer vragen krijgt.

[Splashy]

De "x-powered-by" header is inmiddels verouderde informatie, dat stuurt tegenwoordig vrijwel geen enkele server nog mee.

[Cyb]

Er zijn aardig wat sites die dat wel degelijk meesturen. En zoals ik eerder aangaf, "x-powered-by" is standaard gewoon aan volgens de officiele PHP site. Wel leveren veel derde bronnen het standaard uitgeschakeld. Maar dat neemt niet weg dat "verouderde informatie" gewoon niet klopt.

[downtime]

php -v vereist toch dat je kunt inloggen en een prompt hebt? Dat zal in managed hosting niet altijd het geval zijn. Toen ik nog een verenigingswebsite beheerde was me ook niet altijd duidelijk welke PHP versie de hoster nu eigenlijk draaide.

[rikster]

Maar de patch zal toch ook door een authorised user geplaatst moeten worden. Dus...

Ok, je kunt dan de root (of wat dan ook) inlichten, maar een beheerder die dit niet bijhoudt leest vermoedelijk ook de goedbedoelde mails van gebruikers niet (regelmatig).

Kortom: een beetje beheerder houdt dit bij.

[Pixelmagic]

Daar heb je dan phpinfo() voor

[rikster]

Dat is niet iets voor (de meeste) eindgebruikers. Dus, welke gebruikers wil OpenAI nu eigenlijk gaan bedienen? En waarom met een nieuwe tool?

[burne]

Even een bestandje uploaden met dit erin:

<?php
phpinfo();
?>

En je weet gelijk alles wat je als eindgebruiker weten wilt. Afhankelijk van je hoster moet dit wel de juiste eigenaar, extensie en/of permissies hebben.

[rikster]

Maar dat is niet iets voor een doorsnee eindgebruiker toch? En de caveats die je zelf al aangeeft maakt dit nog weer eens allesbehalve bullet-proof. Zie mijn vorige vraag: wat wil OpenAI bereiken?

[burne]

Maar wel iets voor een website-beheerder met vragen..

Ik reageer specifiek op het wel of niet kunnen zien van php -v . phpinfo() is het equivalent daarvan.

[Skit3000]

Ik denk dat elke hacker vandaag een dag vrij heeft genomen om hier nu al misbruik van te maken. Waar het in Nederland en de rest van Europa (en Azië en Afrika) groot nieuws is en websites offline werden gehaald, wordt er bij grote Amerikaanse nieuwsmedia (CNN, NBC, Fox) met nog geen woord over gesproken terwijl daar óók genoeg websites op PHP draaien. Dat kan er voor zorgen dat er niet alleen een gevoel van urgentie om te update ontbreekt zoals in de rest van de wereld, maar ook dat hackers door het tijdsverschil langer de tijd hebben om aanvallen uit te voeren.

[Alex3]

Ze zitten daar later aan de koffie door het tijdverschil.

[GrooV]

Tja is twee maanden ook niet wat lang gezien het aantal betrokkenen?

Daarnaast is het wel echt pijnlijk dat deze bug al zo lang in PHP zit omdat de maintainers dachten dat het niet exploitable was

[kaas-schaaf]

2019 was de eerste hint blijkbaar: https://bugs.php.net/bug.php?id=78876

edit: hint -> dit zorgt uiteindelijk voor eenzelfde bug maar heeft andere artifacten (temp files). Deze bug is gefixed, maar niet het onderliggende probleem.

Maar goed, "niet dezelfde code dus fout" is makkelijker.

[Reactie gewijzigd door kaas-schaaf op 21 oktober 2026 18:23]

[kipkornkoning]

Bizar dat ze het zo hebben laten liggen. Helemaal met de kennis en kunde van nu.

[BobV]

Die gelinkte bug is in 2020 gewoon gepatched.

[kaas-schaaf]

- verwijderd omdat code checken en analyseren voor mensen te moeilijk is-

[Reactie gewijzigd door kaas-schaaf op 21 oktober 2026 18:20]

[svenslootweg]

Het is opvallend hoe groot en complex de changeset van de patch voor deze problemen is; er zijn blijkbaar zo'n 5000 nieuwe regels bijgekomen als je de nieuwe tests niet mee rekent.

Dat suggereert dat er inderdaad gretig gebruik gemaakt is van LLMs om de patch te schrijven (want die hebben al snel de neiging om alles op te lossen met meer code), en roept ook de vraag op of dit niet een hele lading nieuwe lekken geintroduceerd heeft door de grote hoeveelheid nieuwe code, als je het vergelijkt met een 'ouderwetse' structurele fix die doorgaans bestaande code verbetert.

[PWSteal]

Ik ben vaak betrokken bij het oplossen van productie incidenten bij het software pakket van de werkgever. Als ik op een bug een changeset van 5000 regels terugkrijg dan stuur ik dat direct terug naar de tekentafel. Je neemt een enorm risico om een vrij concreet probleem op te lossen.

Ongetwijfeld is dit ook niet fatsoenlijk gereviewed, want geen enkel mens kan fatsoenlijk 5000 regels reviewen.

[hqql]

"Het beveiligingsbedrijf gebruikte naar eigen zeggen GPT-5.6 Sol en stelt dat Gemini 4 Argon een 'bijdrage van onschatbare waarde' leverde."

Enerzijds nice, anderzijds beginnen we natuurlijk op het punt te komen dat bepaalde 'kwetsbaarheden' zeer onwaarschijnlijk gevonden zullen worden zonder AI, dus in hoeverre was het dan echt een kwetsbaarheid?

[max3D]

Ryan Austin (Calif) zei dit over de rol van LLM's in zijn disclosure
How did we find this?

No special harness, or access to models that weren't generally available to everyone were used in the initial bug discovery. I focused on something I had a background in, knew its vulnerability history well, and held a theory that specific bugs lurk within the codebase. This shows that "know your target" is still as applicable as ever, even in the LLM dominated VR age. No model is simply capable of unearthing "all bugs" with simple prompts. At least for now.

There are some practical research implications here. LLMs may have ingested public historical vuln data, but in their default variant analysis tends to move from the newest and most prominent bugs toward nearby older code. They do not reliably begin with obscure twenty-year-old exploitation primitives. Keeping your own mental catalog of a target's vulnerability history lets you prompt that direction explicitly.

[Malarky]

Wat is het verschil tussen een kwetsbaarheid die waarschijnlijk alleen gevonden kan worden de top3 slimste en beste security onderzoekers ter wereld versus de top3 slimste AI modellen?

Dat doet er toch niet toe?

[svenslootweg]

Mwa, dat valt alleszins tegen. De complexiteit van met AI gevonden lekken is doorgaans vergelijkbaar met die van door mensen gevonden lekken, en dat is niet heel verbazingwekkend aangezien het natuurlijk op mensenwerk getraind is, en eigenlijk gewoon kunstjes nadoet.

Dus het maakt het niet minder een kwetsbaarheid, en het verschil zit hem vooral in de hoeveelheid werk die er tegenaan gegooid kan worden, niet anders dan hoe het altijd al met security scanners gewerkt heeft. Die ook altijd al precies hetzelfde probleem met false positives gehad hebben.

Dat er "AI" bij betrokken is maakt netto dus waarschijnlijk op alle vlakken heel weinig uit.

[cane]

Omdat mensen nu AI hebben en als die safeguards hebben China ook AI heeft zonder die safeguards.

[Crew One]

Als er gewoon exploits voor zijn die werken, hoe complex dan ook, dan is het toch een kwetsbaarheid?

[hqql]

Dat vraag ik me dus inderdaad af. Als er exploits zijn die nooit worden gevonden, ben je dan kwetsbaarder daardoor?

Het is verder niet een discussie die iets verandert aan de situatie, AI is er nu eenmaal, maar mij lijkt dat er wel een punt komt waarop AI met 'kwetsbaarheden' gaat komen waar een groot hackerscollectief niet eens achter zou zijn gekomen (zonder hulp van).