Het PHP-lek: wat controleer je nu en wat laat je testen?

TL;DR

• Op 21 oktober 2026 bracht het PHP-project spoedupdates uit voor twee kritieke lekken, CVE-2026-109618 en CVE-2026-109619. Beide laten code uitvoeren op afstand, zonder inloggen.
• Veilig zijn PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35. PHP 8.1 en ouder krijgen geen gewone updates meer.
• Het lek zit in PHP zelf, niet in een plugin of CMS. WordPress, Drupal, Magento en Laravel op een kwetsbare PHP-versie zijn dus ook geraakt.
• Tijdelijke maatregelen verkleinen het risico, maar maken een server niet veilig. Updaten en alle PHP-processen herstarten is de enige oplossing.
• Controleer daarna wat je vergeten bent: oude servers, systemen bij een externe partij en alles wat vanaf internet bereikbaar is.

Vorige week ging een deel van de Nederlandse en Vlaamse overheid uit voorzorg offline. Geen aanval, wel twee lekken in PHP, de taal waar een groot deel van het web op draait. De situatie evolueert nog en de details worden elke dag scherper. Wat al vaststaat: wie PHP draait en nog niet heeft bijgewerkt, heeft werk. Dit stuk gaat over wat je zelf nakijkt en wat je beter laat nakijken door iemand die kijkt zoals een aanvaller. Dat tweede is waar een pentest voor dient, en wie dat sneller of vaker wil, gebruikt RedSOC, pentesten op afroep.

Wat er gebeurd is

Op 20 oktober 2026 kondigde het securityteam van PHP een spoedrelease aan voor twee kritieke kwetsbaarheden. De updates kwamen op 21 oktober, een dag eerder dan oorspronkelijk gepland, nadat de details voortijdig waren uitgelekt. Het PHP-project geeft beide lekken een score van 9,2 op 10 (CVSS v4.0). Elders circuleerden hogere cijfers. De score verschilt dus per bron, de ernst niet.

De twee lekken, samen PHP2Shell genoemd, zitten diep in PHP zelf. CVE-2026-109618 komt uit de manier waarop PHP een tekort aan geheugen afhandelt: een verzoek dat halverwege stokt, laat halfklare data achter die PHP bij het opruimen als geldig behandelt. CVE-2026-109619 draait om interne status die na het vrijgeven van geheugen blijft hangen en door een volgend verzoek op dezelfde worker wordt hergebruikt, een use-after-free. Het gevolg is in beide gevallen hetzelfde: een aanvaller stuurt een verzoek zonder in te loggen en voert code uit op je server. Verder gaan we hier bewust niet in op de techniek.

Wie geraakt is

Elke PHP-installatie die webverzoeken afhandelt: PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed. Het PHP-project noemt mod_php het grootste risico, omdat daar een werkende aanval bestaat die loopt voor je applicatiecode aan de beurt komt.

Omdat het lek in de taal zit en niet in een plugin of CMS, maakt het niet uit wat erbovenop draait. WordPress, Drupal, Magento, Laravel of een maatwerkportaal van tien jaar oud: op een kwetsbare PHP-versie zijn ze allemaal geraakt. CERT-EU waarschuwt dat mogelijk alle versies vanaf PHP 5 kwetsbaar zijn.

De gepatchte versies zijn PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35. PHP 8.1 en ouder krijgen geen gewone updates meer. Het project publiceerde alleen minimale broncodepatches voor 7.4, 8.0 en 8.1 en verwijst verder naar je distributie of leverancier. Draai je zo'n versie, dan is dit het moment om te upgraden in plaats van te lappen.

Wat je nu zelf controleert

Begin met een inventaris van alle hosts waar PHP op draait, ook die buiten je eigen beheer. De marketingsite bij een extern bureau. Het intranet dat iemand in 2018 opzette. De testomgeving die per ongeluk publiek staat. De monitoringtool met een PHP-frontend. Bij een pentest vinden we zulke vergeten systemen vaker dan klanten verwachten, en ze draaien zelden de nieuwste versie.

Controleer per host de actieve versie, niet de geïnstalleerde. Een pakketupdate schrijft nieuwe bestanden op schijf, maar de lopende PHP-processen draaien door op de oude code tot je ze herstart. Het PHP-project zegt het letterlijk: herstart elke worker. De vraag is dus niet "is de update uitgevoerd" maar "welke versie meldt de draaiende FPM-pool of Apache-module nu".

Staan er versies tussen zonder patch, plan dan een upgrade. Tijdelijke maatregelen zoals session.upload_progress.enabled op 0 en een lagere maximale requestgrootte verkleinen het aanvalsoppervlak, maar het PHP-project is er duidelijk over: ze maken een installatie niet veilig.

Kijk daarna naar wat vanaf internet bereikbaar is. Alles met een publiek IP-adres of een hostnaam in DNS komt eerst. En trek je logs na op verdachte verzoeken van voor de update, want de details lekten uit voor de patch er was. Een server die intussen is misbruikt, wordt niet schoon door hem te patchen.

Wat een pentest toevoegt

Een versiecontrole toont wat jij ziet. Een pentest toont wat een aanvaller ziet. Bij dit lek is dat verschil groot.

Eerst het externe aanvalsoppervlak. Bij een pentest brengen we in kaart welke systemen van jouw organisatie vanaf internet bereikbaar zijn, ook degene die niet in je inventaris staan. Precies daar zitten de vergeten PHP-hosts.

Dan de validatie na de patch. Dat een pakketbeheerder "up to date" meldt, bewijst niet dat de kwetsbare code weg is. Wij testen van buitenaf of het echt dicht is. Bij elke pentest van Sectricity zit een retest inbegrepen, zodat je na het oplossen van de bevindingen bevestigd krijgt dat de fix standhoudt.

En dan de snelheid. Een volledige pentest plan je niet op een woensdagmiddag. RedSOC is pentesten op afroep: je zet credits in wanneer je ze nodig hebt, bijvoorbeeld voor een gerichte controle van je PHP-hosts, zonder een volledig traject op te starten. Hoe dat werkt, lees je in onze uitleg over RedSOC.

Veelgestelde vragen

Welke PHP-versies zijn gepatcht?

PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35. PHP 8.1 en ouder krijgen geen gewone updates meer; daarvoor bestaan alleen minimale broncodepatches en eventuele backports van je distributie. Een upgrade is daar de echte oplossing.

Is een site op WordPress, Drupal, Magento of Laravel ook geraakt?

Ja, als de PHP-versie eronder kwetsbaar is. Het lek zit in PHP zelf, niet in het CMS of framework. Een update van WordPress of Laravel lost het dus niet op; de PHP-versie op de server moet omhoog.

Volstaan de tijdelijke maatregelen?

Nee. Instellingen zoals session.upload_progress.enabled op 0 en een lagere maximale requestgrootte verkleinen het risico, maar volgens het PHP-project maken ze een installatie niet veilig. Ze overbruggen de tijd tot je kunt updaten, meer niet.

Waarom moet je PHP herstarten na de update?

Omdat de lopende processen de oude code in het geheugen houden. Een pakketupdate schrijft nieuwe bestanden op schijf, maar PHP-FPM-workers of een Apache-module met mod_php draaien door op wat ze bij de start laadden. Pas na een herstart meldt de actieve versie het nieuwe nummer.

Wat doet een pentest dat een versiecontrole niet doet?

Een versiecontrole kijkt naar de systemen die je kent, van binnenuit. Een pentest kijkt van buiten, vindt ook de hosts die niet op je lijst staan en test of de kwetsbaarheid echt niet meer te misbruiken is. Na het oplossen van de bevindingen volgt een retest.

Wordt het lek al misbruikt?

De berichten lopen uiteen. Het PHP-project meldt een werkende aanval op mod_php en sommige partijen zagen pogingen op het web, terwijl andere instanties op het moment van publicatie nog geen actief misbruik zagen. De situatie evolueert. Ga ervan uit dat elke PHP-host die vanaf internet bereikbaar is en nog niet is bijgewerkt, een doelwit is.

Gerelateerde diensten en bronnen

Wil je zeker weten dat dit lek bij jou dicht is, dan start je met een pentest, met een retest inbegrepen zodra je de bevindingen hebt opgelost. Wil je sneller schakelen, dan is RedSOC pentesten op afroep. Achtergrond lees je in wat een pentest precies is en in onze posts over waarom een retest altijd inbegrepen zit en RedSOC uitgelegd. Bouw je zelf producten op PHP, dan hoort ook productbeveiliging onder de CRA op je lijst.