PHP2Shell: kritieke PHP-lekken CVE-2026-109618 en -109619 uitgelegd

Op woensdag 21 oktober 2026 gingen in Nederland en daarbuiten op grote schaal websites op zwart. Niet door een storing, maar uit voorzorg: twee kritieke kwetsbaarheden in PHP, geregistreerd als CVE-2026-109618 en CVE-2026-109619 en samen PHP2Shell genoemd, maken het mogelijk om zonder inloggegevens code uit te voeren op een webserver. Hostingpartijen hebben vandaag massaal PHP-diensten tijdelijk uitgeschakeld of klantwebsites offline gezet om te patchen. Ook onze eigen webshop was daardoor ongeveer anderhalf uur niet bereikbaar.

In dit artikel leggen wij uit wat er precies aan de hand is, welke PHP-versies en toepassingen kwetsbaar zijn, hoe ernstig de situatie is en wat u als IT-beheerder of inkoper nu concreet doet: patchen of laten patchen, inventariseren, logs nalopen en waar nodig verouderde servers of software vervangen.

Wat is er aan de hand?

Volgens BleepingComputer heeft het PHP-securityteam op 21 oktober noodpatches uitgebracht voor twee kritieke remote code execution-lekken die zijn ontdekt door onderzoekers van Calif, Wiz en OpenAI. Beide kwetsbaarheden komen voort uit hetzelfde onderliggende probleem: wanneer een HTTP-verzoek abnormaal eindigt, kan PHP zijn geheugen in een corrupte staat achterlaten. CVE-2026-109618 misbruikt een keten van zwakheden rond het bereiken van de geheugenlimiet (out-of-memory), CVE-2026-109619 is een zogeheten stale global state-fout die leidt tot een heap use-after-free, geheugenlekkage en uiteindelijk code-uitvoering met de rechten van de webworker (bron: BleepingComputer).

Heise Security beschrijft het mechanisme achter CVE-2026-109618 als volgt: als een script de ingestelde memory_limit bereikt, genereert PHP een fout en hoort het de resten van het mislukte script op te ruimen. Bij een door een aanvaller geprepareerd uploadformulier of bijzonder diep geneste arrays gaat dat opruimen mis, waardoor de aanvaller geheugen kan lezen, vrijgeven en eigen code kan uitvoeren in de context van de webserver-gebruiker (bron: heise).

Bijzonder aan deze zaak is de timing. De openbaarmaking stond gepland voor 22 oktober, maar volgens heise werd die een dag vervroegd omdat details voortijdig uitlekten. ICTMagazine meldt dat via een anonieme publicatie op Hacker News een werkende proof-of-concept naar buiten kwam, waardoor de PHP-maintainers hun releaseschema moesten loslaten (bron: ICTMagazine). Dat verklaart waarom zoveel organisaties, waaronder volgens Dutch IT Channel de Tweede Kamer, het NCSC en delen van het SURF-netwerk, hun sites uit voorzorg offline haalden in afwachting van de patch (bron: Dutch IT Channel).

Welke PHP-versies en toepassingen zijn kwetsbaar?

Vrijwel alle versies en alle webserver-koppelingen

Volgens heise stelt het PHP-team dat de fouten aanwezig zijn in elke PHP-versie sinds PHP 5. BleepingComputer meldt dat alle PHP-installaties die webverzoeken afhandelen zijn geraakt: PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed. Het PHP-securityteam beschouwt het risico bij mod_php als het hoogst, omdat daar een aanval mogelijk is nog voordat enige applicatiecode draait. Ook PHP-webservers op Windows zijn volgens heise kwetsbaar.

Gepatchte versies zijn volgens BleepingComputer PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35. PHP 8.1 en ouder krijgt geen reguliere updates meer van het PHP-project. Vanwege de ernst heeft het securityteam wel minimale source-backports voor PHP 7.4, 8.0 en 8.1 beschikbaar gesteld voor wie zelf compileert of geen LTS-leverancier heeft; voor distributiepakketten verwijst het project naar de eigen Linux-leverancier.

Webshops, CMS, intranet en maatwerk

Het probleem zit in de PHP-engine zelf, niet in een CMS of plug-in. Eye Security benadrukt via Dutch IT Channel dat u dit dus niet oplost door alleen WordPress of plug-ins bij te werken (bron: Dutch IT Channel). Computable noemt als voorbeelden installaties van WordPress, Drupal, Magento en Laravel (bron: Computable). Omdat de fout optreedt bij het verwerken van inkomende HTTP-verzoeken, vóórdat applicatiecode actief wordt, helpt beveiliging op applicatieniveau niet: een zwaar beveiligd maatwerksysteem is volgens ICTMagazine net zo kwetsbaar als een standaard WordPress-site.

Minder zichtbaar, maar even relevant, zijn interne toepassingen: intranetten, urenregistratie, oudere CRM-pakketten en zelfgebouwde portalen. Die lijken niet vanaf internet bereikbaar, maar blijken dat via routeringsfouten of koppelingen met leveranciers soms toch te zijn. Heise voegt daaraan toe dat verouderde interne PHP-installaties een aanvaller die al binnen is (bijvoorbeeld via Windows-malware) kunnen helpen om zich blijvend in het netwerk te nestelen.

Appliances, NAS-systemen en netwerkapparatuur

PHP draait niet alleen op webservers. Heise wijst erop dat diverse netwerkapparaten PHP gebruiken voor hun webbeheerinterface, en noemt security-appliances van Citrix, Palo Alto en Ivanti en BIG-IP-loadbalancers van F5. Zolang beheer- of webinterfaces aan internet hangen, moet u die apparaten als onderdeel van het aanvalsoppervlak zien, niet als onderdeel van de verdediging.

Hoe ernstig is het?

Beide lekken hebben van het PHP-securityteam een CVSS v4.0-score van 9,2 gekregen; vroege berichten van onderzoekers spraken zelfs van 10,0. Een aanvaller heeft geen inloggegevens nodig en er is geen gebruikersinteractie vereist. Volgens heise werkt een exploit niet bij de eerste poging, maar zijn enkele duizenden tot tienduizenden HTTP-verzoeken nodig, wat de lekken uitermate geschikt maakt voor geautomatiseerde aanvallen; de ontdekkers toonden in een video hoe zij na 38 seconden systeemcommando's uitvoerden op een Laravel-server.

Over actief misbruik lopen de signalen uiteen. Het NCSC meldde aanvankelijk geen actief misbruik te hebben waargenomen, maar Cloudflare-CTO Dane Knecht bevestigde volgens BleepingComputer dat zijn bedrijf al vroege aanvallen zag en dat de uitgerolde WAF-regels slechts een tijdelijke bescherming bieden. Volgens ICTMagazine registreerden SOC's binnen enkele uren na het lekken van de proof-of-concept massale scans door botnets. BleepingComputer haalt een schatting van VirusTotal aan van ruim 5,1 miljoen PHP-hosts die online bereikbaar zijn.

Wat betekent dit voor uw organisatie?

Website of webshop bij een hostingpartij. Dan is de hostingpartij verantwoordelijk voor de PHP-installatie, maar u blijft verantwoordelijk voor de controle. Heise adviseert om op de onderhoudspagina van uw provider na te gaan of en wanneer die de updates installeert. In onze eigen praktijk zagen wij vandaag hoe dat uitpakt: onze host voerde een patchronde uit waarbij de webshop ongeveer anderhalf uur offline was. Dat is vervelend, maar verreweg te verkiezen boven een overgenomen server. Vraag uw host na afloop om bevestiging van de geïnstalleerde PHP-versie.

Eigen servers, VPS of cloudinstanties. U patcht zelf. Let daarbij op een valkuil die ICTMagazine beschrijft: na een pakketupdate staan de nieuwe PHP-binaries op schijf, maar actieve processen blijven de oude code uitvoeren. Pas na een herstart van PHP-FPM of Apache draait de gepatchte versie. Controleer dus niet alleen het pakket, maar ook de versie die de webserver daadwerkelijk gebruikt.

Oudere PHP-versies (8.1, 8.0, 7.x of ouder). Hier is het risico het grootst en de oplossing het lastigst. ICTMagazine adviseert om sites op PHP 8.1 of ouder direct over te zetten naar een ondersteunde versie of ze tijdelijk af te schermen. Vaak draait zo'n oude PHP op een even oud besturingssysteem op een afgeschreven server. Dan is dit het moment om de migratie naar een actuele PHP-versie te koppelen aan vernieuwing van het platform, bijvoorbeeld een moderne server uit onze categorie servers met een ondersteund OS en voldoende capaciteit voor een gescheiden test- en productieomgeving.

Appliances en NAS. Controleer bij de fabrikant of er firmware-updates zijn en haal beheerinterfaces van het publieke internet. Een hardwarematige firewall met strikte toegangsregels voor beheerpoorten beperkt het aanvalsoppervlak structureel, los van dit specifieke lek.

Wat u nu concreet doet

1. Inventariseer. CERT-EU adviseert alle PHP-gebaseerde toepassingen in kaart te brengen (bron: Dutch IT Channel). Denk aan de website, webshop, klantportaal, API's, intranet, monitoringtools, ticketsystemen, wiki's en de webinterfaces van NAS-systemen, printers en netwerkappliances. Vergeet containers en ontwikkel- of acceptatieomgevingen niet.
2. Patch of laat patchen. Installeer PHP 8.5.12, 8.4.27, 8.3.36 of 8.2.35, of de gepatchte distributiepakketten van uw Linux-leverancier, en herstart alle PHP-workers. Bij gehoste omgevingen: bevestiging opvragen bij de host.
3. Kunt u niet direct patchen? Isoleer. CERT-EU en Eye Security adviseren om publiek bereikbare PHP-toepassingen tijdelijk offline te halen of af te schermen. Het PHP-team publiceerde tijdelijke mitigaties, zoals memory_limit=-1 via php_admin_value, een lage post_max_size, session.upload_progress.enabled=0 en op PHP 8.5 fatal_error_backtraces=0, maar noemt die uitdrukkelijk een tijdelijke noodoplossing. PHP-kernontwikkelaar Gina Peter Banyard stelt volgens BleepingComputer zelfs dat alleen de officiële patch afdoende is. WAF-regels van bijvoorbeeld Cloudflare verkleinen het risico, maar vervangen patchen niet.
4. Loop logs na. Omdat de informatie al uren circuleerde voordat patches beschikbaar waren, kunnen aanvallers eerder hebben geprobeerd binnen te komen. Zoek in webserver- en PHP-FPM-logs naar ongebruikelijk grote aantallen POST-verzoeken met multipart/form-data van dezelfde bron, pieken in geheugenfouten (out of memory, segfaults van workers) en onbekende bestanden in webroots of tijdelijke mappen. Eye Security adviseert bovendien om na de update te controleren of de site daadwerkelijk de nieuwe versie gebruikt en of er niet al misbruik is gemaakt.
5. Stel back-ups veilig. ICTMagazine wijst erop dat een gegarandeerd schone herstelomgeving minstens zo belangrijk is als de update zelf (bron: ICTMagazine). Zorg dat er een back-up van vóór 21 oktober beschikbaar is en bewaar die buiten de getroffen omgeving, bijvoorbeeld op een aparte opslagserver die niet vanaf de webserver schrijfbaar is.
6. Vernieuw waar nodig. Draait PHP 7 of 8.1 op een server die ook qua hardware en OS aan het eind van zijn levensduur is, plan dan een migratie in plaats van een losse backport. Een ondersteunde PHP-versie op een ondersteund platform is de enige manier om bij een volgende noodpatch binnen uren in plaats van dagen klaar te zijn.

Veelgestelde vragen over PHP2Shell