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 (33)

[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?

[frackleboom]

Er zijn altijd onderzoekers die een grote finding maar moeilijk voor zich kunnen houden. Dan wordt er toch even gepocht tegen vrienden op een besloten server: “Kijk eens wat ik gevonden heb.” En voor je het weet kopieert iemand die video en deelt ’m weer door, waardoor dit zich razendsnel kan verspreiden. Vroegâh kwamen zulke types op IRC ook even pronken met een rhost op van nameserver of andere webserver. Sommige dingen veranderen blijkbaar nooit

[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?

[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.

[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.)

[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.

[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.

[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

[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.

[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.

[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?

[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?