PHP-lekken CVE-2026-109618 en CVE-2026-109619 (21 oktober 2026): wie onder artikel 14 van de Cyberweerbaarheidsverordening moet melden en wat de Cyberbeveiligingswet van websitebeheerders vraagt

In april 2014 werd bekend dat OpenSSL, de bibliotheek die een groot deel van het versleutelde internetverkeer beveiligde, al twee jaar een lek bevatte waarmee iedereen geheugen van een server kon uitlezen. Heartbleed trof banken, overheden en webwinkels, terwijl het project zelf door een kleine groep vrijwilligers werd onderhouden. In Nederland had het NCSC een jaar eerder al een leidraad voor responsible disclosure gepubliceerd, later opgevolgd door een leidraad voor Coordinated Vulnerability Disclosure. Twaalf jaar later staat er een vergelijkbaar geval op tafel, nu met een wettelijk kader eromheen. Op 21 oktober 2026 bracht PHP noodpatches uit voor twee kritieke lekken, ontdekt met AI-tools, terwijl de meldplicht die de Cyberweerbaarheidsverordening sinds 11 september 2026 aan fabrikanten oplegt net zes weken gold.

Wat PHP op 21 oktober 2026 uitbracht en hoe Calif en Wiz de lekken met AI vonden

Het PHP-ontwikkelteam publiceerde op 21 oktober de versies 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Volgens de aankondiging op php.net verhelpen ze CVE-2026-109618 en CVE-2026-109619, twee lekken waarmee een aanvaller zonder inloggen code op de server kan uitvoeren. Er is volgens het team geen volledige tijdelijke maatregel: bijwerken is de enige veilige keuze. Op 23 oktober volgde een aanvullend advies om de instelling session.upload_progress.enabled uit te zetten tot de volgende reguliere release, tegen een onwaarschijnlijke extra aanvalsroute. PHP draait achter ongeveer zeventig procent van de websites, WordPress inbegrepen. De Amerikaanse NSA adviseerde om sites die niet direct konden bijwerken offline te halen, meldde The AI Insider op 22 oktober.

Beide lekken zijn met AI gevonden. Beveiligingsbedrijf Calif vond er een met GPT-5.6 Sol van OpenAI, binnen het programma Patch the Planet. Wiz vond meerdere kwetsbaarheden met de eigen beveiligingsagent Wiz Atlas, Gemini 4 Argon en GPT-5.6 Sol. Beide partijen volgden de route van gecoördineerde openbaarmaking en testten de fixes vooraf met onder meer AWS, Cloudflare, Microsoft en Automattic. Wiz waarschuwde wel dat taalmodellen een aanval nu snel aanpassen aan elke PHP-versie en configuratie. Na de bekendmaking haalden Japanse banken en spoorwegbedrijven en Europese ministeries websites tijdelijk offline, volgens Streamline. Volgens The AI Insider zaten de lekken sinds 2004 in elke PHP-versie; ze kwamen pas boven toen AI-tools de code systematisch doorzochten.

Wie sinds 11 september 2026 onder artikel 14 CRA moet melden, en binnen welke termijnen

De Cyberweerbaarheidsverordening (Verordening (EU) 2024/2847, de CRA) geldt grotendeels pas vanaf 11 december 2027. De meldplicht van artikel 14 geldt al sinds 11 september 2026, en volgens artikel 69, lid 3, ook voor producten die eerder op de markt kwamen. Bij de start van die meldplicht beschreven wij al dat een fabrikant dan binnen een etmaal moet weten welk product geraakt is. PHP2Shell maakt dat concreet. Een fabrikant die weet dat een kwetsbaarheid in zijn product actief wordt misbruikt, meldt dat tegelijk aan de CSIRT die als coördinator is aangewezen en aan ENISA, via het centrale meldplatform. De termijnen staan in artikel 14, lid 2: een vroegtijdige waarschuwing binnen 24 uur, een volledige melding binnen 72 uur en een eindverslag uiterlijk 14 dagen nadat een herstelmaatregel beschikbaar is.

De plicht ligt bij de fabrikant van het product met digitale elementen, niet bij de beheerder van een website. Denk aan de leverancier van een netwerkopslagapparaat of router met een beheerinterface in PHP, of de maker van commerciële software die PHP meelevert. De meldplicht hangt bovendien aan actief misbruik. OpenAI meldde bij de bekendmaking dat er geen misbruik bekend was; de organisaties die hun sites offline haalden, deden dat uit voorzorg. Uit voorzorg offline gaan is iets anders dan vastgesteld misbruik. Voor een fabrikant betekent dat een dagelijkse afweging. Hij moet niet alleen weten of zijn product PHP bevat, maar ook vanaf welk moment hij weet dat het lek in zijn product wordt misbruikt. Artikel 13, lid 6, dat vanaf 11 december 2027 geldt, vraagt daarnaast dat een fabrikant die een kwetsbaarheid in een component vindt, ook een open-sourcecomponent, dat meldt aan wie dat component onderhoudt.

Wanneer de organisatie achter PHP als open-source-steward onder artikel 24 CRA valt, en waarom stewards geen boete riskeren

De CRA maakte een bewuste keuze voor projecten als PHP. Vrije en open-sourcesoftware die buiten een commerciële activiteit wordt ontwikkeld, valt buiten de fabrikantenplichten. Voor organisaties die zulke software duurzaam ondersteunen, zoals stichtingen, introduceert de verordening de figuur van de open-source-steward. Steward is volgens artikel 3, punt 14, een rechtspersoon die stelselmatig en duurzaam de ontwikkeling ondersteunt van open-sourcesoftware die bestemd is voor commerciële activiteiten. Of een organisatie als de PHP Foundation, die volgens The AI Insider de patches uitbracht, daaronder valt, hangt van die voorwaarden af. Volgens artikel 24 moet een steward een cyberbeveiligingsbeleid hebben, het vrijwillig melden van kwetsbaarheden stimuleren en samenwerken met markttoezichthouders. Voor zover de steward bij de ontwikkeling betrokken is, geldt de meldplicht van artikel 14, lid 1, ook voor hem, maar pas vanaf 11 december 2027. Bij PHP2Shell gold die plicht voor stewards dus nog niet. Artikel 64, lid 10, sluit administratieve boetes voor stewards uit.

Die keuze sluit aan bij de les van Heartbleed. Een vrijwilligersproject dat de halve wereld draait, wordt niet veiliger als het boetes boven het hoofd hangen. Het wordt veiliger wanneer de bedrijven die het gebruiken meebetalen en meehelpen. De kosten van PHP2Shell vallen daarom vooral bij de fabrikanten en gebruikers verderop in de keten: zij moeten testen, uitrollen en melden. De ontdekking met AI verandert die rekensom. Als ontdekken goedkoop wordt, groeit het aantal meldingen dat een klein team moet verwerken, terwijl het tempo van bijwerken bij de gebruikers blijft liggen.

Wat de Cyberbeveiligingswet vraagt van een gemeente of ziekenhuis dat zijn PHP-site offline haalt

Voor de organisatie die de website draait, geldt een ander regime. Valt zij onder de Cyberbeveiligingswet, die sinds 15 augustus 2026 de NIS2-richtlijn in Nederland uitvoert, dan heeft zij een zorgplicht om haar systemen te beveiligen, waaronder het tijdig bijwerken van software. Een significant incident meldt zij binnen 24 uur met een vroegtijdige waarschuwing en binnen 72 uur met een incidentmelding; de verhouding tot het datalek onder de AVG staat in onze bespreking van de termijnen van 24 en 72 uur. Een website die uit voorzorg offline gaat, is niet vanzelf een significant incident, maar een gemeentelijk loket dat dagen onbereikbaar blijft, kan het wel worden.

Een burger die een vergunning wil aanvragen of een ziekenhuisafspraak wil verzetten, merkt een kwetsbaarheid in een programmeertaal als een dichte deur. NIS2 gaf in artikel 12 de CSIRT's ook een rol als coördinator bij gecoördineerde openbaarmaking, en ENISA beheert sindsdien een Europese kwetsbaarhedendatabank.

Hoe de productaansprakelijkheidsrichtlijn vanaf 9 december 2026 het uitblijven van updates beoordeelt

Het derde kader is civielrechtelijk. De nieuwe productaansprakelijkheidsrichtlijn (Richtlijn (EU) 2024/2853) moet uiterlijk 9 december 2026 zijn omgezet en merkt software uitdrukkelijk aan als product. Het nieuwe regime geldt voor producten die na 9 december 2026 in de handel worden gebracht of in gebruik worden genomen; de bestaande PHP-installaties uit dit incident vallen er dus niet automatisch onder. Een fabrikant die het product onder zijn controle houdt, kan zich niet beroepen op het verweer dat het gebrek pas na het in het verkeer brengen ontstond, wanneer dat gebrek voortkomt uit een ontbrekende software-update die voor de veiligheid nodig was. Open-sourcesoftware die buiten een commerciële activiteit wordt geleverd, valt buiten de richtlijn. Wie na die datum PHP in een commercieel product verwerkt en het product onder zijn controle houdt, loopt daardoor aansprakelijkheidsrisico bij een uitgestelde veiligheidsupdate, mits de gewone voorwaarden van gebrek, schade en causaal verband vervuld zijn. De richtlijn dekt daarbij alleen bepaalde schade: dood en letselschade, schade aan zaken die niet uitsluitend professioneel worden gebruikt, en verlies of beschadiging van gegevens die niet voor professionele doeleinden worden gebruikt. Zuivere bedrijfsschade doordat een dienst stil ligt, valt er niet onder. In ons stuk over het Californische AB 316 en artikel 6:77 BW lieten we zien hoe die aansprakelijkheid zich verhoudt tot de AI Act.

Ook de AI Act speelt mee, aan de kant van de modellen die de lekken vonden. Aanbieders van AI-modellen voor algemene doeleinden met een systeemrisico moeten onder artikel 55 hun modellen evalueren, ook met adversarial tests, en systeemrisico's beperken. Offensieve cybercapaciteit is zo'n risico. Dezelfde capaciteit die Calif en Wiz voor verdediging inzetten, kan een aanvaller gebruiken om een exploit te schrijven. Artikel 55 richt zich op de aanbieder van het model; voor het bedrijf dat met zo'n model naar lekken zoekt, blijven de regels over gecoördineerde openbaarmaking het kader.

Welke afspraken over meldingen en updates in een leverancierscontract horen

De wet verdeelt de plichten, maar het contract bepaalt hoe snel een organisatie in de praktijk beschermd is. Bij de inkoop van software of apparatuur met een webinterface helpt deze checklist voor leverancierscontracten:

• Een termijn waarbinnen de leverancier u informeert over een actief misbruikte kwetsbaarheid, afgestemd op de 24 uur van artikel 14 CRA, zodat uw eigen meldtermijn onder de Cyberbeveiligingswet niet verloopt terwijl u wacht.
• Een maximale termijn voor beveiligingsupdates na een publieke patch van een gebruikt open-sourcecomponent, met een tijdelijke maatregel als de update later komt.
• Een opgave van de gebruikte componenten en versies, zodat u bij een nieuw lek binnen een uur weet of u geraakt bent.
• Een supportperiode voor updates die past bij de verwachte gebruiksduur van het product.
• Een regeling voor wie de kosten draagt als u een dienst uit voorzorg offline moet halen.

Twijfelt u of de voorwaarden van uw softwareleverancier deze punten afdekken? Laat ze dan nalopen met de AIRecht contractscan. U ziet dan wat de leverancier toezegt over updates en meldingen, en waar uw organisatie zelf het risico draagt.

Bronnen (geraadpleegd op 25 oktober 2026): PHP, beveiligingsreleases 8.5.12, 8.4.27, 8.3.36 en 8.2.35 (21 oktober 2026); The AI Insider, AI Tools Uncover Two-Decade-Old PHP Flaws as NSA Urges Urgent Patching (22 oktober 2026); Streamline, Critical PHP Vulnerabilities Force Websites Offline Across Japan and Europe (22 oktober 2026); Verordening (EU) 2024/2847 (Cyberweerbaarheidsverordening), artikelen 3, 13, 14, 24, 64, 69 en 71; Richtlijn (EU) 2022/2555 (NIS2), artikelen 12 en 23; Richtlijn (EU) 2024/2853 (productaansprakelijkheid), artikelen 2, 11 en 21; Verordening (EU) 2024/1689 (AI Act), artikel 55; PHP, Informational advisory: Session upload progress (23 oktober 2026); ENISA, Vulnerability disclosure; The Heartbleed Bug (2014).