OpenAI publiceerde op 21 oktober 2026, tijdens de afhandeling van twee kritieke PHP-kwetsbaarheden, een voorstel voor een gecoördineerde aanpak in vijf fasen. PHP is een programmeertaal die op webservers draait en websites en webapps kan aansturen. OpenAI’s voorstel beschrijft hoe onderzoekers, beheerders, beveiligingsbedrijven en overheden volgens OpenAI samen aan een oplossing kunnen werken.

Het praktisch belangrijke punt: het voorstel beperkt wie welke informatie krijgt en wanneer een kwetsbaarheid openbaar wordt. PHP heeft voor de twee fouten inmiddels vaste versies uitgebracht. De voorgestelde aanpak is geen aangenomen industriestandaard.

De vijf fasen van OpenAI’s voorstel

OpenAI stelt een volgorde voor van het controleren en repareren van een fout tot het publiceren van richtlijnen zodra een patch beschikbaar is. De vijf fasen zijn:

  1. De fout valideren en herstellen. Beheerders, onderzoekers en technische partners bevestigen de impact, ontwikkelen een oplossing en testen die. OpenAI noemt ook tests met geavanceerde AI-modellen om te zoeken naar manieren waarop een oplossing kan worden omzeild en naar verwante fouten.
  2. Getroffen organisaties tijd geven om zich voor te bereiden. Beheerders bepalen wie vroeg wordt ingelicht. Distributeurs kunnen oplossingen aanpassen voor oudere versies, hostingproviders kunnen maatregelen testen en beveiligingsbedrijven kunnen detectie of bescherming voorbereiden, bijvoorbeeld met regels voor een web application firewall (WAF).
  3. Overheden betrekken. Overheidsinstanties kunnen helpen de reactie af te stemmen en richtlijnen door te geven aan organisaties die kritieke infrastructuur en essentiële diensten beheren.
  4. Updates voor verwante producten voorbereiden. Als oplossingen en plannen voor openbaarmaking duidelijker zijn, kunnen distributeurs, dienstverleners, incidentteams en beheerders updates voorbereiden en nagaan waar nog gaten zitten.
  5. Richtlijnen publiceren zodra een patch bestaat. Die moeten beheerders helpen vaststellen of hun systemen risico lopen, een update of tijdelijke maatregel vinden en controleren of een oplossing actief is.

OpenAI beschreef deze aanpak in het kader van de PHP-kwetsbaarheden. Volgens OpenAI vond Calif één fout met hulp van GPT-5.6 Sol; Wiz ontdekte beide fouten onafhankelijk. De PHP-ontwikkelaars leidden het herstel. OpenAI’s voorstel vraagt om reacties van beheerders, onderzoekers en andere betrokkenen.

Wanneer kan de openbaarmakingstermijn veranderen?

OpenAI stelt voor informatie alleen te delen met deelnemers die die nodig hebben voor beschermend werk. Daarbij moet volgens het voorstel worden afgewogen welk risico het delen van informatie oplevert en welke bescherming het mogelijk maakt.

De planning kan opnieuw worden beoordeeld als er actief wordt misbruik gemaakt van een kwetsbaarheid, als informatie uitlekt, als een openbare patch de fout zichtbaar maakt of als uitgesteld herstel het risico voor gebruikers vergroot. OpenAI vraagt ook om feedback over de lengte van openbaarmakingstermijnen, gefaseerde meldingen, backports voor oudere versies en waarborgen voor noodpatches. Het voorstel noemt daarbij systemen die een beheerder bezit of waarvoor die bevoegd is om updates uit te voeren. Scannen op kwetsbaarheden op internetschaal en noodpatches voor systemen van anderen zijn vragen voor verdere bespreking, geen vastgelegde onderdelen van de aanpak.

De twee PHP-fouten en de vaste versies

OpenAI stelt vijf fasen voor bij PHP-kwetsbaarheden

PHP omschrijft CVE-2026-109618 als uitvoering van code op afstand door corruptie bij geheugentekort. Bij CVE-2026-109619 gaat het om uitvoering van code op afstand door verouderde globale status. Globale status is informatie die tussen onderdelen van PHP kan worden gedeeld. Beide fouten kunnen een aanvaller volgens PHP in staat stellen code uit te voeren zonder eerst in te loggen. PHP gaf beide kwetsbaarheden een score van 9,2 volgens CVSS v4.0.

PHP publiceerde op 21 oktober 2026 deze gecorrigeerde releases:

PHP-branchGecorrigeerde release
PHP 8.58.5.12
PHP 8.48.4.27
PHP 8.38.3.36
PHP 8.28.2.35

De juiste release hangt af van de branch die een server gebruikt. Eerder legde NeoTeo de PHP-releases met oplossingen voor de twee kwetsbaarheden uit; OpenAI’s nieuwe voorstel gaat over de coördinatie rond zulke reparaties.

PHP 8.1 en oudere branches krijgen geen updates meer van het PHP-project. PHP publiceerde wel minimale broncodebackports voor PHP 7.4, 8.0 en 8.1. Sommige Linux-distributies en leveranciers van langdurig ondersteunde software bieden ook bijgewerkte pakketten. De pakketstatus hangt dus af van de leverancier; een oud versienummer zegt op zichzelf niet of een backport is geïnstalleerd.

Tijdelijke maatregelen zijn geen volledige oplossing

PHP noemt maatregelen die blootstelling aan specifieke aanvalspaden kunnen verminderen. Voor CVE-2026-109618 noemt PHP memory_limit=-1, beperkingen op POST- en andere verzoekgroottes en container- of cgroup-limieten als grens voor de beschikbaarheid van systeembronnen. Voor CVE-2026-109619 noemt PHP het uitschakelen van session.upload_progress.enabled vóór het verwerken van verzoeken en het herstarten van alle workers. Op PHP 8.5 kan fatal_error_backtraces=0 het bevestigde aanvalspad via fatale fouttraces blokkeren.

Deze maatregelen pakken afzonderlijke paden aan. PHP zegt dat ze een installatie niet veilig maken en dat bijwerken naar een gecorrigeerde release de volledige oplossing is. PHP’s beveiligingsbericht noemt de vaste versies en de beperkingen van de tijdelijke maatregelen.