PHP heeft op 21 oktober twee kritieke lekken gedicht, CVE-2026-109618 en CVE-2026-109619, waarmee een aanvaller zonder inloggegevens code op je webserver kan laten draaien. De fixes zitten in PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Draait jouw site op een oudere versie of weet je niet welke versie het is, dan heb je vandaag werk.
Het NCSC waarschuwde op 21 oktober dat een eenvoudig POST-verzoek genoeg is om een kwetsbare server over te nemen en dat er een publieke proof of concept bestond. Het eigen advies NCSC-2026-0443 staat op kans hoog en schade hoog. Het gaat om het onderdeel dat de webverzoeken afhandelt, dus een WordPress-update of een nieuw thema lost niets op.
Wat er mis is
Volgens het NCSC-advies gaat het om twee fouten in de PHP-engine zelf. De eerste ontstaat als PHP geen geheugen meer heeft en een verzoek met half ingevulde gegevens doorverwerkt. De tweede laat interne toestand van een eerder verzoek achter in het geheugen, waarna een volgend verzoek op dezelfde worker die toestand opnieuw gebruikt. In beide gevallen kan een aanvaller code uitvoeren.
Het advies stelt dat alle PHP-installaties die webverzoeken verwerken zijn getroffen. CISA noemt PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed. Bij mod_php is het risico het grootst. Volgens Help Net Security zou een werkende exploit al afgaan voordat jouw eigen code draait.
Het NCSC zag op 21 oktober nog geen misbruik, maar dat veranderde. Amazons honeypot MadPot registreerde volgens Help Net Security op 17 oktober al een aanvalspoging, vier dagen voor de openbaarmaking. CISA zette beide lekken op 26 oktober op de lijst met bekende misbruikte kwetsbaarheden. Behandel je site dus als doelwit.
Stap 1: weet welke PHP-versie je draait
- WordPress: ga in het beheer naar Gereedschap, Sitegezondheid en open het tabblad Info. Onder Server staat de PHP-versie.
- Webshopsystemen en andere CMS'en: de versie staat meestal in de systeemstatus of in het beheerpaneel van je hoster.
- Eigen server of VPS: draai php -v. Gebruik je PHP-FPM naast een CLI, controleer dan ook de versie van de FPM-service, want die kan verschillen.
Vergelijk het resultaat met de gepatchte versies:
| Tak | Gepatcht in | Ondersteuning van PHP tot |
|---|---|---|
| 8.5 | 8.5.12 | 31 december 2029 (beveiliging) |
| 8.4 | 8.4.27 | 31 december 2028 (beveiliging) |
| 8.3 | 8.3.36 | 31 december 2027 (beveiliging) |
| 8.2 | 8.2.35 | 31 december 2026 (beveiliging) |
De data komen van de pagina met ondersteunde versies op php.net. PHP 8.2 loopt dus nog maar twee maanden mee, ook na deze fix. Zit je op 8.2, plan dan meteen de overstap naar 8.4 of 8.5.
Stap 2: vraag het je hoster of regel het zelf
Bij gedeelde hosting en managed hosting patcht de hoster de servers. Rootnet meldde op de dag zelf dat alle managed servers waren bijgewerkt, ook de oudere versies vanaf 5.6. Dat laatste heeft PHP zelf niet bevestigd, dus vraag bij een hoster die dit zegt naar welke build je site precies draait. Daarna controleer je zelf de versie zoals hierboven.
Bij een VPS, een dedicated server of een eigen container ligt het patchen bij jou. Automatische beveiligingsupdates pakken PHP niet altijd mee. Update via de pakketbron van je distributie, herstart PHP-FPM of Apache en controleer daarna opnieuw de versie. Bij een Docker-image bouw je opnieuw met een gepatchte basisimage; een image die maanden oud is, bevat nog de kwetsbare versie. Gebruik je het Remi-repository voor RPM-pakketten, dan had dat op de dag van de openbaarmaking nog geen update, dus wissel naar pakketten van je distributie of bouw uit de broncode.
Stap 3: draai je PHP 8.1 of ouder
PHP 8.1 en eerder krijgen geen officiële fix meer. PHP bracht voor 7.4, 8.0 en 8.1 wel minimale backports van de broncode uit, bedoeld voor wie zelf compileert en geen betaalde langetermijnondersteuning heeft. Sommige distributies en LTS-leveranciers hebben eigen gepatchte pakketten. Voor een webshop met klantgegevens is dat een noodoplossing. Het NCSC raadt aan end-of-life-versies op te waarderen, en dat geldt hier met extra nadruk.
Kun je niet snel patchen of upgraden, haal de site dan tijdelijk offline. Het NCSC adviseert bij systemen die niet direct te verhelpen zijn om de risico's af te wegen en zo nodig uit te schakelen. Een tijdelijke webfirewall helpt een beetje: Cloudflare heeft volgens Help Net Security regels voor bekende aanvalsroutes uitgerold voor alle klanten, ook de gratis. Dat is een extra laag en geen vervanging voor de update. Het uitzetten van session.upload_progress.enabled staat bij sommige hosters op de lijst van maatregelen, maar dat is een verzachting en geen oplossing.
Stap 4: kijk of je al geraakt bent
Omdat er voor de openbaarmaking al een aanval is gezien, is patchen niet voldoende. CISA raadt aan te letten op PHP-workers die een shell starten of tools downloaden. Concreet kun je:
- De webserverlogs vanaf 17 oktober doorzoeken op ongewone POST-verzoeken, vooral naar bestanden waar je normaal nooit naar post.
- Op de server nagaan of er recent bestanden in je webroot zijn toegevoegd of gewijzigd die je niet herkent.
- Processen controleren: een PHP-proces dat een shell of een downloadprogramma start, hoort daar niet.
- Na het patchen alle PHP-processen herstarten, zodat er geen oud proces met de kwetsbare code in het geheugen blijft.
Searchlight Cyber heeft de open-source php2shell-scanner uitgebracht om te testen of een host kwetsbaar is. Draai die alleen op servers van jezelf.
Begin met de controle van je PHP-versie en vergelijk die met de tabel. Staat er een lager patchnummer dan de gepatchte versie of een tak die al langer geen updates meer krijgt, vraag dan vandaag je hoster om een gepatchte versie of verhuis de site.