Wat betekenen de kritieke PHP-kwetsbaarheden voor jouw website?

Laatst bijgewerkt: 23 oktober 2026, 11:50 uur. We hebben alle bronnen in dit artikel op 23 oktober tussen 11:44 en 11:46 uur (Nederlandse tijd) opnieuw gecontroleerd. Het NCSC onderzoekt sinds 22 oktober eerste signalen van succesvol misbruik en adviseert kwetsbare systemen offline te houden tot ze zijn bijgewerkt. Een nieuwere PHP-release dan die van 21 oktober is er niet. Wat er is gewijzigd, staat onderaan.

Wat is er aan de hand met PHP?

In PHP zelf zaten twee kritieke lekken, CVE-2026-109618 en CVE-2026-109619. Via die lekken kan iemand via internet code op je server laten uitvoeren, zonder in te loggen. Het lek zit niet in een plugin of thema, maar in de software op de server die je website laat werken. PHP bracht de reparatie op 21 oktober 2026 uit. De onderzoekers gaven hun onderzoek de bijnaam PHP2Shell.

Een PHP-ontwikkelaar zag de eerste tekenen van het geheugenprobleem achter het eerste lek al in 2024. In augustus 2026 meldden onderzoekers dat het lek te misbruiken was. Hoe het daarna liep, staat in de tijdlijn verderop.

Wat is PHP?

PHP is de programmeertaal op de server die de pagina's van je website opbouwt. Elke keer dat iemand een pagina opent, een formulier verstuurt of iets bestelt, verwerkt PHP dat verzoek. Ook WordPress draait op PHP. Volgens de meting van W3Techs naar het gebruik van PHP draait 69,3 procent van de websites waarvan de servertaal bekend is op PHP.

Om welke twee lekken gaat het?

Meer technische details geven we bewust niet, want die helpen aanvallers meer dan ondernemers. Wie zelf een server beheert, vindt alles in de advisories van PHP.

Hoe ernstig is het?

PHP geeft beide lekken een score van 9,2 op een schaal van 10 (CVSS versie 4.0). Volgens de CVSS-standaard heet alles vanaf 9,0 kritiek. Het NCSC schat in zijn beveiligingsadvies NCSC-2026-0443 de kans en de schade allebei hoog in. Het getal 10,0 dat op 20 oktober online rondging, klopt niet.

In de score van PHP staat dat een aanval specifieke omstandigheden nodig heeft en complex is. Volgens PHP kan drukte op de server het aantal benodigde pogingen verhogen, maar het probleem verdwijnt er niet door. De Amerikaanse kwetsbaarhedendatabase NVD gaf beide lekken op 21 oktober een eigen score van 9,8 op de oudere schaal CVSS 3.1, zonder een complexe aanval aan te nemen. Op 22 oktober verlaagde NVD de score van CVE-2026-109619 naar 8,1, omdat NVD die aanval nu als complex beoordeelt. Op die schaal is 8,1 hoog en niet kritiek. CVE-2026-109618 houdt bij NVD 9,8, en PHP noemt beide lekken nog steeds kritiek.

Wat betekent 'code uitvoeren op afstand' (RCE)?

RCE staat voor remote code execution. Iemand laat dan via internet eigen opdrachten op jouw server uitvoeren, bij deze lekken zonder account en zonder wachtwoord. De opdrachten draaien met de rechten van het account waaronder de webserver werkt.

Bij een WordPress-website kan dat account meestal bij alle websitebestanden, ook bij wp-config.php met de inloggegevens van de database. In die database staan bestellingen, klantgegevens en formulierinzendingen. Wie code kan uitvoeren, kan ook bestanden aanpassen, malware plaatsen of een achterdeur achterlaten.

Het tweede lek kan daarnaast geheugen van PHP laten uitlezen. Volgens de onderzoekers kunnen daar wachtwoorden, sleutels van koppelingen en certificaten in staan. Het NCSC noemt als mogelijke gevolgen dat servers worden overgenomen, websites onbereikbaar raken, gegevens uitlekken of inloggen niet meer werkt.

Welke versies zijn kwetsbaar en waar zit de reparatie in?

PHP noemt de reeksen 8.2 tot en met 8.5 vóór 8.2.35, 8.3.36, 8.4.27 en 8.5.12 als getroffen. Voor 7.4, 8.0 en 8.1 publiceerde PHP minimale reparaties in de broncode. Andere bronnen rekenen ook oudere versies tot de getroffen versies. De onderzoekers gaan terug tot PHP 5.4, het Franse CERT noemt alle versies vanaf PHP 5 en NVD alle versies vóór 8.2.35. Op 23 oktober om 11:44 uur was er geen nieuwere PHP-release dan deze vier.

De data komen uit het overzicht van ondersteunde PHP-versies en de lijst van PHP-versies die niet meer worden ondersteund.

Test je al met PHP 8.6 (nog niet voor gebruik op een live website)? Gebruik dan minimaal 8.6.0 RC4. Volgens php.net zit daar de reparatie in.

Mijn website draait op PHP 8.1 of ouder

Daar brengt PHP geen gewone update meer voor uit. De minimale reparaties zijn bedoeld voor wie PHP zelf compileert. Sommige Linux-distributies en leveranciers met langdurige ondersteuning verwerken zo'n reparatie in hun eigen pakketten. Vraag je hostingpartij of dat bij jou zo is, en plan hoe dan ook een upgrade. Beheer je de server zelf, dan adviseert het NCSC hem offline te halen tot je hebt geüpgraded.

Oude plugins en thema's werken soms niet met een nieuwe PHP-versie, dus test de overstap eerst op een testomgeving. WordPress.org raadt PHP 8.3 of hoger aan, en volgens de compatibiliteitstabel van WordPress werkt PHP 8.5 pas vanaf WordPress 6.9. Is je website te oud voor een ondersteunde PHP-versie, kijk dan of je een nieuwe website op basis van je huidige laat maken.

Mijn website draait op PHP 8.2

Werk bij naar 8.2.35 of een gerepareerd pakket. PHP 8.2 krijgt na 31 december 2026 geen beveiligingsupdates meer, dus plan de stap naar 8.3 of hoger nu al in.

Welke websites lopen risico?

Elke website of webapplicatie die op PHP draait en webverzoeken verwerkt, zolang de server deze reparatie nog niet heeft. PHP en het NCSC noemen alle PHP-installaties die webverzoeken verwerken als getroffen. Dat geldt ook voor WordPress, WooCommerce en Laravel.

WordPress en WooCommerce

Volgens WordPress.org en WooCommerce is het lek niet specifiek voor WordPress en is er geen update van WordPress of WooCommerce nodig of gepland. De onderzoekers schrijven dat hun aanval werkte op de containerimages van WordPress, Drupal en Joomla die op het moment van testen het nieuwst waren. Voor een webshop weegt het lek zwaarder, want op de server staan klantgegevens, bestellingen en meestal ook de sleutels voor je betaalprovider. WooCommerce raadt PHP 8.3 of nieuwer aan.

Andere software met PHP

Ook webmail, monitoringsoftware en beheerschermen van netwerkapparatuur kunnen PHP bevatten. Het NCSC houdt een overzicht bij van software waarin PHP zit, zonder garantie dat het volledig is. Vraag ook die leveranciers naar een update. Volgens het NCSC kan zo'n update later komen, omdat leveranciers de reparatie eerst in hun eigen product moeten testen.

Voor ontwikkelaars en serverbeheerders

Een update van Laravel of van je pakketten via Composer lost dit niet op, want het lek zit in PHP zelf. Volgens het ondersteuningsbeleid van Laravel kun je met Laravel 12 en 13 binnen je eigen PHP-reeks bijwerken. PHP noemt alle gangbare opzetten als risico, zoals PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed, met het hoogste risico bij mod_php. Installeer de gerepareerde pakketten of bouw vanaf de broncode, bouw containerimages opnieuw en herstart Apache, PHP-FPM en langlopende processen zoals Laravel Octane en queue-workers. Het Britse NCSC raadt aan eerst de systemen bij te werken die vanaf internet bereikbaar zijn, en daarna de interne systemen. De tijdelijke maatregelen in de beveiligingsadvisory van PHP sluiten alleen bekende aanvalspaden af en kunnen volgens het NCSC bij misbruikpogingen tot verstoringen leiden. De update voegt een tweede, hogere geheugengrens toe waarbij het PHP-proces direct stopt, dus houd daarna je foutlogboeken in de gaten.

Waarom is een actuele WordPress niet genoeg?

Omdat het lek onder WordPress zit, in de PHP-software op de server. Je website kan dus helemaal bijgewerkt zijn en toch kwetsbaar.

Een website bestaat uit lagen. Bovenop staan je thema en je plugins, daaronder WordPress, daaronder PHP en helemaal onderin de server. De automatische updates van WordPress werken alleen WordPress, thema's en plugins bij. PHP en de server worden bijgewerkt door wie de hosting beheert.

Wat is het verschil met de WordPress-lekken van juli en september?

Die lekken zaten in WordPress zelf, en een WordPress-update loste ze op. Het lek van oktober zit een laag lager, in PHP. Daar komt geen WordPress-update voor.

In juli 2026 dichtte WordPress 7.0.2 een kritiek en een ernstig lek in WordPress zelf. CISA, de Amerikaanse overheidsdienst voor cyberveiligheid, zette beide lekken op 21 juli op zijn lijst van lekken die aantoonbaar worden misbruikt. In september dichtte WordPress 7.1.2 opnieuw een kritiek lek in WordPress zelf, dat CISA op 25 september op die lijst zette. Welke andere risico's rond een WordPress-website vaak blijven liggen, lees je in de twaalf risico's die je bij je WordPress-website zelf kunt nalopen.

Helpt een firewall, beveiligingsplugin of onderhoudsmodus?

Een firewall helpt tegen bekende aanvalspogingen, maar vervangt de update niet. Cloudflare zette op 21 oktober vanaf 05:02 uur extra firewallregels aan en raadt toch aan om PHP bij te werken. Een beveiligingsplugin is zelf PHP-code en draait pas als PHP het verzoek al verwerkt. Bij de aanval die PHP op mod_php bevestigde, gebeurt het misbruik volgens PHP al voordat er code van je website draait. Om dezelfde reden helpt de onderhoudsmodus van WordPress niet. Lees ook wat een firewall wel en niet doet.

Wordt het lek al misbruikt?

Het NCSC onderzoekt sinds 22 oktober eerste signalen van succesvol misbruik. Bij de laatste controle, op 23 oktober om 11:46 uur, had geen van de bronnen hieronder bevestigd dat er aanvallen zijn gelukt. Wel zijn er pogingen. Cloudflare zag aanvalsverkeer en schrijft dat het misbruik al vóór de bekendmaking begon. Volgens de beslisboom van het NCSC ervaren kwetsbare PHP-versies op dit moment pogingen tot misbruik. Daarnaast circuleren er proofs of concept. De bronnen zijn het niet over alles eens, daarom staat hieronder per bron wat die zegt en wanneer.

Een proof of concept laat zien dat een lek bestaat, maar is niet per se een werkende aanval op jouw website. Ook de reparatie is openbaar en aanvallers kunnen die bestuderen. Wacht daarom niet met bijwerken tot bevestigd is dat aanvallen zijn gelukt. Het NCSC verwacht dat de situatie langdurig aandacht vraagt, omdat PHP in veel soorten software zit. Volgens het NCSC is het waarschijnlijk dat aanvallers deze lekken lang blijven misbruiken, zoals eerder bij het lek Log4Shell in de software Log4j.

Wat is het verschil tussen kwetsbaar, aangevallen en besmet?

Kwetsbaar betekent dat het lek op je server zit, omdat PHP nog niet is bijgewerkt. Aangevallen betekent dat iemand het lek probeert te misbruiken. Besmet betekent dat het is gelukt en dat er iets op je server is achtergebleven, zoals malware of een extra beheerder. Een firewall die aanvallen tegenhoudt, maakt je server niet minder kwetsbaar.

Hoe controleer ik mijn PHP-versie?

In WordPress ga je naar Tools > Sitediagnose > Informatie en open je het onderdeel Server. Bij de regel PHP versie staat de versie waarmee je website nu draait. Daarvoor heb je beheerdersrechten nodig. Veel hostingpartijen tonen de PHP-versie ook in hun beheerpaneel.

Wat zegt het versienummer wel en niet?

Sitediagnose toont de PHP-versie die op dat moment je pagina's verwerkt. Het beheerpaneel van je hosting toont soms alleen de ingestelde versie. Na een update moeten de PHP-processen opnieuw starten, anders blijft de oude versie draaien.

Een lager nummer betekent niet altijd dat je kwetsbaar bent. Sommige Linux-distributies zetten de reparatie in een pakket dat het oude versienummer houdt, ook bij de reeksen 8.2 tot en met 8.5. Je ziet dan bijvoorbeeld 8.3.6, terwijl de reparatie er toch in zit. Vraag je hostingpartij dan om een schriftelijke bevestiging voor CVE-2026-109618 en CVE-2026-109619.

Laat geen phpinfo-bestand openbaar staan

Sommige handleidingen raden aan een bestand als info.php met de functie phpinfo() op je website te zetten. Volgens de PHP-handleiding toont zo'n bestand onder meer je PHP-versie, serverinformatie, instellingen en HTTP-headers. Met die gegevens kan iemand gericht zoeken naar servers met een bekend lek. Verwijder zo'n bestand direct na gebruik.

Is er bij jou actie nodig?

Ja, als je website op PHP draait en de server de reparatie nog niet heeft, of als je dat niet zeker weet. Zoek je situatie op in de tabel en begin bovenaan.

Wat moet ik nu doen?

Vraag je hostingpartij of de reparatie op de server staat en of de PHP-processen daarna opnieuw zijn gestart. Staat de reparatie er nog niet, houd je website dan offline tot het zover is. Controleer daarna je website.

1. Controleer je PHP-versie in Sitediagnose of in het beheerpaneel van je hosting.
2. Vraag je hostingpartij per mail om een bevestiging dat PHP is bijgewerkt en dat alle PHP-processen opnieuw zijn gestart.
3. Draai je op 8.2 of ouder, plan dan een upgrade. Maak eerst een back-up van je WordPress-website en test een nieuwe PHP-versie eerst op een testomgeving.
4. Gebruik geen losse 'fix'-plugins of geplakte instellingen. Volgens PHP is alleen de update een volledige oplossing.
5. Let op nepmails. Klik niet op een link om in te loggen in een mail over een dringende PHP-update. Lees hoe je nepmails herkent.
6. Controleer je website na de update. Hoe, lees je hieronder bij de kwetsbare periode.

Weet je niet wie de PHP-laag van jouw website bijhoudt? Lees dan verderop wie dit regelt.

Zo vraag je het aan je hostingpartij

Je kunt dit bericht overnemen en je eigen domeinnaam invullen.

Hallo, naar aanleiding van de PHP-beveiligingsupdates van 21 oktober 2026 (CVE-2026-109618 en CVE-2026-109619) heb ik drie vragen over mijn website jouwdomein.nl. Op welke PHP-versie draait de website nu? Is die bijgewerkt naar 8.2.35, 8.3.36, 8.4.27 of 8.5.12, of naar een pakket waarin deze reparaties zijn verwerkt? En zijn de PHP-processen na de update opnieuw gestart? Graag een bevestiging per mail.

Ben je klant van ViVortis?

Staat je website bij ViVortis, dan hoort PHP-versiebeheer bij het onderhoud. Je website draait op de nieuwste PHP-versie die WordPress en je plugins ondersteunen, en de hostingomgeving richten wij in en houden wij bij. Wil je weten op welke PHP-versie jouw website nu draait, vraag het dan via de helpdesk. Gaat het om een storing of een vermoeden van malware, lees dan wat je doet bij een dringend probleem.

Moet ik mijn website offline halen?

Ja, zolang je website nog kwetsbaar is. Het NCSC adviseert sinds 22 oktober om systemen die nog niet zijn bijgewerkt uit voorzorg offline te houden tot de updates erop staan. Draait de reparatie al en zijn de PHP-processen opnieuw gestart, dan hoeft het niet.

In zijn beslisboom (een handreiking van 22 oktober, gelinkt op de alertpagina over de PHP-lekken) maakt het NCSC onderscheid naar wie PHP beheert. Beheer je PHP zelf en draai je 8.2 of hoger, installeer de update dan zo snel mogelijk. Draai je in eigen beheer een versie lager dan 8.2, haal het systeem dan offline tot je hebt geüpgraded. Beheert een andere partij PHP voor je, zoals bij gedeelde hosting, neem dan contact op met die partij. CERT-EU noemt afschermen als bijwerken niet direct lukt. Het Britse NCSC noemt eerst de tijdelijke maatregelen van PHP en daarna offline halen. WordPress.org en WooCommerce raden het aan bij PHP ouder dan 8.2 op eigen hosting.

Het NCSC haalde op 21 oktober zijn eigen website ncsc.nl uit voorzorg tijdelijk offline, net als meerdere andere organisaties, waaronder overheidsinstanties. Die avond was ncsc.nl weer bereikbaar. Een onbereikbare website van een bekende organisatie kan dus voorzorg zijn.

Wat controleer je als je website in de kwetsbare periode online was?

Laat na de update controleren of er onbekende bestanden, beheerders, plugins of geplande taken zijn bijgekomen, en vernieuw de belangrijkste wachtwoorden en sleutels. De update verwijdert geen bestanden of accounts die iemand eventueel al heeft toegevoegd. Ook het NCSC raadt aan om na het bijwerken zo nodig onderzoek te doen naar mogelijk misbruik.

Wat is de kwetsbare periode?

Daar is geen officiële datum voor. Het probleem zat volgens de onderzoekers al jaren in PHP. Op 20 oktober gingen rond 17:00 uur de CVE-nummers rond, zonder technische details. Die avond verscheen per ongeluk een video van een proof of concept. Volgens de PHP Foundation versnelde die video de ontwikkeling van proofs of concept. Op 21 oktober in de ochtend was de reparatie al vóór de officiële release te bestuderen. De periode eindigt pas als jouw server de reparatie draait en de PHP-processen opnieuw zijn gestart.

Wat laat je controleren?

• Beheerders. Kijk onder Gebruikers > Alle gebruikers of er beheerders bij staan die je niet kent.
• Plugins, bestanden en geplande taken. Let op plugins die je niet hebt geïnstalleerd, nieuwe of gewijzigde bestanden en nieuwe cronjobs. Je hostingpartij of webbouwer kan dat vergelijken met een eerdere back-up.
• Wachtwoorden en sleutels. Vernieuw de wachtwoorden van beheerders, de database en je hostingaccount, en de API-sleutels van koppelingen. Het tweede lek kan geheugen laten uitlezen, en daar kunnen zulke gegevens in staan.
• Serverlogboeken. De onderzoekers noemen als signalen onder meer onverklaarde crashes of herstarts van PHP-processen en herhaalde serverfouten (HTTP 500). Dat is werk voor je hostingpartij.

Vind je niets, dan bewijst dat niet dat er niets is gebeurd. PHP en de onderzoekers zeggen allebei dat ontbrekende foutmeldingen geen bewijs van veiligheid zijn. Het Britse NCSC adviseert wie niet direct kon bijwerken om het systeem na te lopen op achterdeurtjes, en zo nodig een gespecialiseerde partij in te schakelen.

Heb je een webshop?

Doe na de update een testbestelling en controleer of formulieren, betalingen en koppelingen nog werken. Was je server mogelijk geraakt, vernieuw dan ook de API-sleutels van je betaalprovider en van koppelingen met bijvoorbeeld je boekhouding of verzending.

Zie je signalen van een besmette website?

Denk aan een waarschuwing van Google of je browser, onbekende pagina's of links, doorverwijzingen naar vreemde websites of beheerders die je niet kent. Lees dan wat je doet als je WordPress-website besmet is met malware, of laat je website herstellen en beveiligen. Zijn er mogelijk persoonsgegevens van klanten uitgelekt, dan moet je dat in veel gevallen binnen 72 uur melden bij de Autoriteit Persoonsgegevens.

Wie regelt dit: jij, je hostingpartij of je webbouwer?

Dat hangt af van je afspraken. De automatische updates van WordPress regelen de PHP-laag niet. Die wordt bijgewerkt door wie de hosting beheert, en dat moet dan wel zo zijn afgesproken.

Stel je hostingpartij of webbouwer daarom drie vragen. Wie installeert de beveiligingsupdates van PHP? Hoe snel gebeurt dat bij een kritiek lek? En wie herstart daarna de PHP-processen en kijkt of de website nog werkt? Vraag de antwoorden per mail, zodat je ze bij een volgend lek terugvindt. Welke vragen je verder stelt en wat zelf onderhouden aan tijd en risico vraagt, lees je in ons artikel over je website zelf onderhouden of uitbesteden.

Vandaag is het PHP. Morgen kan een andere kwetsbaarheid worden ontdekt. Met professioneel websiteonderhoud hoef je dit niet iedere keer zelf uit te zoeken.

Bij ViVortis hoort PHP-versiebeheer bij WordPress onderhoud, samen met hosting, zakelijke e-mail, dagelijkse back-ups en kleine wijzigingen via de Nederlandstalige helpdesk. We voeren updates gecontroleerd uit, met een back-up vooraf en een controle achteraf. Een update is pas klaar als je website daarna nog werkt. Het onderhoud kost €69 per maand excl. btw. Staat je website nu ergens anders, dan verhuizen we hem eerst naar onze hosting, voor eenmalig €397 excl. btw. Vraag een gratis websitecheck aan.

Tijdlijn

Nederlandse tijd. De punten over de melding, het uitlekken en de vroege publicatie van de reparatie komen van de PHP Foundation. De punten over NVD komen uit de wijzigingsgeschiedenis van NVD, die van 21 oktober 20:40 uur en 22 oktober 16:00 uur van het NCSC.

• 2024. Een PHP-ontwikkelaar ziet de eerste tekenen van het geheugenprobleem, nog zonder concreet aanvalspad.
• 11 augustus 2026. Het beveiligingsbedrijf Calif meldt dat het lek te misbruiken is. Los daarvan meldt OpenAI dezelfde oorzaak, de PHP Foundation noemt daar geen datum bij. Wiz (24 augustus) en OpenAI (18 september) melden extra aanvalspaden.
• 20 oktober, rond 17:00 uur. De CVE-nummers gaan rond, zonder technische details.
• 20 oktober, avond. Volgens de PHP Foundation kondigt PHP om 21:30 uur aan dat de release een dag eerder komt. Daarna verschijnt per ongeluk een video van een proof of concept.
• 21 oktober, 05:02 uur. De extra firewallregels van Cloudflare staan standaard aan.
• 21 oktober, 09:41 uur. Een distributeur publiceert vóór de afgesproken release al images met de reparatie.
• 21 oktober, 11:03 uur. Het NCSC meldt publieke proof-of-conceptcode, nog geen actief misbruik.
• 21 oktober, middag. PHP brengt 8.5.12, 8.4.27, 8.3.36 en 8.2.35 uit. Daarna volgen WordPress.org (15:44 uur), het NCSC-advies (16:01 uur) en WooCommerce (17:04 uur).
• 21 oktober, 19:01 uur. NVD publiceert een eigen analyse, met een score van 9,8 voor beide lekken.
• 21 oktober, 20:40 uur. ncsc.nl is weer bereikbaar, met een eerste beslisboom bij de PHP-lekken.
• 22 oktober, 16:00 uur. Het NCSC meldt dat het eerste signalen van succesvol misbruik onderzoekt, en adviseert kwetsbare systemen offline te houden tot ze zijn bijgewerkt. In de beslisboom van die dag staat dat kwetsbare PHP-versies pogingen tot misbruik ervaren.
• 22 oktober, 22:45 uur. NVD verlaagt zijn eigen score voor CVE-2026-109619 naar 8,1.

Wat we blijven volgen

Dit artikel blijft op dezelfde plek staan. We letten op meldingen van misbruik, vervolgreleases van PHP, gerepareerde pakketten bij Linux-distributies en wijzigingen in de adviezen. Elke inhoudelijke wijziging zetten we met datum en tijd onder Wijzigingen in dit artikel.

Veelgestelde vragen

Wijzigingen in dit artikel

• 23 oktober 2026, 11:50 uur. Eerste publicatie. Geschreven op 21 oktober en daarna tegen alle bronnen gecontroleerd, op 22 oktober en op 23 oktober, het laatst tussen 11:44 en 11:46 uur. Toegevoegd zijn het NCSC-bericht van 22 oktober over signalen van misbruik en offline houden, de beslisboom van het NCSC en de melding van het Franse CERT. Ook toegevoegd zijn de verlaagde NVD-score voor CVE-2026-109619 en het advies van het Britse NCSC om systemen die vanaf internet bereikbaar zijn eerst bij te werken. Bij de misbruiktabel staan nu ook de pogingen tot misbruik die Cloudflare en de beslisboom van het NCSC noemen. Gecorrigeerd is dat OpenAI de oorzaak los van Calif meldde, zonder datum bij de PHP Foundation. Ook het tijdstip van de eerste NVD-analyse is gecorrigeerd, van 19:18 naar 19:01 uur.