Kritieke PHP-lekken van 21 oktober 2026: update PHP nu

Vandaag was Nederland even ontwricht, niet door een aanval maar door voorzorg. MijnOverheid, DigiD, de site van de Tweede Kamer en talloze andere sites, in Nederland en in de rest van de wereld, gingen uit de lucht in afwachting van een patch, meldde de NOS. Een patch is een soort pleister voor software: een update die een fout in het programma dicht. Hier ging het om twee kritieke fouten in PHP, de software waarop veel websites draaien. Een aanvaller kan daarmee zonder in te loggen zijn eigen code uitvoeren op de server. Op 21 oktober 2026 kwam de patch. Het advies van PHP zelf is kort: nu updaten.

In deze blogpost lees je welke lekken het zijn, welke versies ze oplossen, wie het meeste risico loopt, wat je kunt doen als je nog niet kunt updaten en hoe de release uit de hand liep.

Wat is er aan de hand?

Het PHP-project kondigde de release op 20 oktober aan en publiceerde op 21 oktober de security advisory met twee lekken. Beide hebben een CVSS v4.0-score van 9.2 en de beoordeling Critical:

Volgens de advisories leidt het eerste lek tot code-uitvoering op afstand zonder authenticatie, onder het account van de webworker. Bij het tweede noemen ze daarnaast het lekken van geheugeninhoud.

De advisory noemt geen misbruik in het wild. De aankondiging van 20 oktober hield de mogelijkheid open om eerder te publiceren als details uitlekten of misbruik opdook. Omdat de CVE-nummers al rondgingen, zonder technische details, verschoof PHP de release in diezelfde aankondiging van 22 naar 21 oktober.

Hoe de release uit de hand liep

De PHP Foundation beschrijft hoe de geplande release van 22 oktober een dag naar voren werd gehaald:

• 20 oktober, rond 15:00 UTC: de twee CVE-nummers gingen rond op forums en social media, met een verkeerde releasetijd en een verkeerde CVSS-score van 10.0. Technische details lekten niet.
• 20 oktober, 19:30 UTC: PHP publiceerde de vooraankondiging eerder dan gepland en verschoof de release van 22 oktober naar 21 oktober, 14:00 UTC.
• 20 oktober, rond 20:00 UTC: Calif, een van de onderzoeksteams, publiceerde per ongeluk een video waarin hun proof of concept tegen een aantal doelen werkte, met een paar extra details. Volgens de Foundation versnelde dat de ontwikkeling van andere proof-of-concepts.
• 20 oktober, rond 23:00 UTC: advies aan een paar kritieke infrastructuurpartijen is mogelijk ook uitgelekt.
• 21 oktober, 07:41 UTC: Chainguard brak eenzijdig het embargo en publiceerde images met de fix, ruim zes uur voor de gecoördineerde release.

Het PHP-securityteam vond op het moment van de release geen werkende exploits tussen de proof-of-concepts die opdoken. Toch was de onzekerheid groot genoeg om in Nederland sites als MijnOverheid en DigiD uit voorzorg offline te halen tot de patch er was.

Al sinds 2024 in beeld

Het geheugenprobleem achter CVE-2026-109618 kwam volgens de Foundation al in 2024 boven, tijdens het oplossen van een bevinding uit een externe audit door Quarkslab. Een concrete aanval was toen niet bekend, en de fix bleef maandenlang hangen omdat elke oplossing nadelen had. De Foundation noemt die vertraging zelf “a structural failure”.

Dat veranderde deze zomer. Binnen het programma Patch the Planet, dat OpenAI leidt, begon Calif op 30 juli met een audit van PHP. Op 11 augustus meldden Ryan A van Calif en, los daarvan, OpenAI dezelfde oorzaak als code-uitvoering op afstand. Wiz, dat de lekken PHP2Shell noemt, vond ze op 19 augustus met hulp van Wiz Atlas, Gemini 4 Argon en GPT-5.6 Sol, bevestigde aanvallen tegen Drupal en WordPress en meldde ze op 24 augustus bij PHP. OpenAI meldde op 18 september nog extra aanvalspaden. Volgens OpenAI vond Calif het lek met GPT-5.6 Sol, en vonden AI-modellen de lekken voor zover bekend eerder dan aanvallers. OpenAI noemt het “one of the most impactful security issues in recent memory” en waarschuwt dat dezelfde AI-capaciteiten aanvallers kunnen helpen om snel exploits te bouwen.

De Foundation schrijft dat het securityteam zijn werkwijze aanpast: besluiten kunnen voortaan bij meerderheid vallen en de leiding grijpt eerder in als een fix vastloopt.

OpenAI heeft een checker gepubliceerd waarmee je in Codex de PHP-versie van een website of server controleert, zonder aanvalsverzoeken te sturen. De checker vergelijkt alleen het versienummer dat de server toont; hij bevestigt niet dat de fix er echt in zit.

Wie loopt risico?

PHP noemt “all PHP installations serving web requests”: PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed. Het risico is volgens PHP het grootst bij mod_php. Daar is een werkende aanval aangetoond waarbij een verzoek zonder inloggen het lek raakt voordat er ook maar één regel code van de applicatie draait. Ook PHP-FPM is geraakt. Volgens de PHP Foundation is code-uitvoering bij het eerste lek ook op PHP-FPM bevestigd, via paden in de applicatiecode; de technische advisory noemt voor FPM nog geen volledige aanval. Volgens de advisory van het tweede lek is code-uitvoering via sessies aangetoond tegen zowel mod_php als PHP-FPM.

Kwetsbaar zijn de versies vóór 8.2.35, 8.3.36, 8.4.27 en 8.5.12. Volgens Wiz is elke PHP-versie van het afgelopen decennium, terug tot 5.4, door minstens één van de twee lekken geraakt. Pakketten van je distributie of LTS-leverancier kunnen de fix bevatten met een ouder versienummer; controleer dat in de beveiligingsmeldingen van je leverancier. Over PHP 8.1 en ouder zegt de advisory dat het PHP-project die niet meer bijwerkt. Wel heeft het securityteam minimale broncode-patches voor PHP 7.4, 8.0 en 8.1 gepubliceerd, voor wie zelf compileert.

Update PHP

De enige volledige oplossing is updaten naar een van deze versies:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

Waar je de update vandaan haalt, hangt af van hoe PHP is geïnstalleerd:

• Linux met pakketten van je distributie: Linux-distributies en LTS-leveranciers kregen de patches van tevoren. Kijk bij je leverancier of de bijgewerkte pakketten er al zijn.
• rpms.remirepo.net: deze door vrijwilligers onderhouden repository had op 21 oktober nog geen updates. PHP raadt aan over te stappen op pakketten van je distributie of zelf te compileren.
• Windows: de broncode en binaries voor Windows staan op de downloadpagina van php.net.
• PHP 8.1 of ouder: vraag je leverancier naar een gepatchte versie, of stap over op een ondersteunde versie.

💡 Let op: PHP 8.2 krijgt na 31 december 2026 geen beveiligingsupdates meer. PHP vraagt je daarom nu al een upgrade naar een ondersteunde versie te plannen.

Als je nog niet direct kunt updaten

PHP noemt een aantal maatregelen die bepaalde aanvalspaden afsluiten. Ze maken een installatie uitdrukkelijk niet veilig: “only an update is a complete solution”. Hieronder staat een selectie; de advisory noemt er meer.

Tegen CVE-2026-109618:

• Zet memory_limit=-1, bij voorkeur op een manier die een applicatie niet kan overschrijven, zoals php_admin_value in de FPM-pool of de Apache-configuratie. Controleer dat geen pool, map of applicatie weer een limiet instelt. Een geheugentekort dieper in het systeem kan het lek volgens PHP nog steeds raken.
• Zet post_max_size laag: 8M voor applicaties zonder uploads, 32M als uploads nodig zijn. Houd upload_max_filesize lager dan post_max_size.
• Gebruik een container- of cgroup-limiet als grens voor de beschikbaarheid, bij voorkeur zo dat alleen de getroffen worker stopt. Gebruik daarvoor niet RLIMIT_AS of RLIMIT_DATA: die kunnen juist het kwetsbare pad activeren.

Tegen CVE-2026-109619:

• Zet session.upload_progress.enabled=0 en herstart elke worker. Doe dat in php.ini, een FPM-pool of serverconfiguratie die geldt voordat het verzoek wordt verwerkt. Vertrouw niet op ini_set() of een FPM .user.ini. Dit sluit de bevestigde paden via sessies af, maar geen andere varianten.
• Op PHP 8.5: zet fatal_error_backtraces=0 en herstart elke worker. Dit sluit alleen het bevestigde pad via fatal backtraces af.
• Verwijder ongeldige of verouderde instellingen die per verzoek worden toegepast en een melding geven voordat het verzoek is opgestart. Ze verbergen met error_reporting, display_errors of @ helpt niet.

De advisory zegt niets over gedeelde webhosting, waar de hostingpartij de PHP-configuratie beheert. Dat lijkt een vraag voor die partij.

Tot slot

De PHP-lekken van 21 oktober 2026 zijn kritiek en raken elke niet-bijgewerkte PHP-installatie die webverzoeken afhandelt, met mod_php als grootste risico. Update naar 8.2.35, 8.3.36, 8.4.27 of 8.5.12, en gebruik de tijdelijke maatregelen alleen als overbrugging. Weet je niet zeker waar PHP draait, loop dan je webservers, intranetten en beheertools na.