Wat is PHP2Shell?
PHP2Shell is de verzamelnaam voor twee kwetsbaarheden in de PHP-interpreter zelf, niet in een framework of plug-in. De fouten zitten in de manier waarop PHP intern geheugen beheert tussen webrequests. Daardoor raken alle manieren waarop PHP webverkeer afhandelt: PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed.
Een aanvaller kan met één enkel, niet-geauthenticeerd HTTP-request de fout triggeren voordat jouw eigen applicatiecode überhaupt draait. Het maakt dus niet uit hoe veilig WordPress, Laravel, Magento of je maatwerk-app is: het lek zit eronder.
Geheugen op het verkeerde moment op
Als PHP tijdens het verwerken van een request zonder geheugen komt te zitten terwijl interne datastructuren nog maar half zijn opgebouwd, behandelt de opruimroutine die halve data als geldig. Een aanvaller kan dit afdwingen en zo code laten uitvoeren.
Oude toestand die blijft hangen
Interne toestand van een request kan blijven bestaan nadat het geheugen is vrijgegeven (een use-after-free). Een volgend request dat door dezelfde PHP-worker wordt afgehandeld, kan die verouderde toestand gebruiken. Ook geheugenlekkage is bevestigd als impact.
Hoe het aan het licht kwam
De fouten werden in augustus 2026 onafhankelijk ontdekt door beveiligingsbedrijf Calif (binnen OpenAI's "Patch the Planet"-programma) en door Wiz. Beide partijen gaven aan dat ze AI-modellen gebruikten bij het onderzoek. De kwetsbare code dateert al van PHP 5.4; een PHP-ontwikkelaar had de geheugenfout in 2024 al gesignaleerd, maar het team kwam toen niet tot een oplossing.
Op 20 oktober 2026 lekten de CVE-nummers en een demonstratievideo voortijdig uit. Het PHP-team haalde daarop de geplande release naar voren en publiceerde de patches op 21 oktober om 14:00 UTC.
Hoe groot is het risico?
Zeer hoog. Ongeauthenticeerde remote code execution op de webserver, in vrijwel elke PHP-installatie van de afgelopen 14 jaar, met publiek circulerende exploitcode en gemelde aanvalspogingen. Dit is de categorie "vanavond patchen, niet volgende week".
- Geen login nodig. Elke PHP-pagina die vanaf internet bereikbaar is, is een aanvalsoppervlak.
- Applicatie-onafhankelijk. De fout wordt getriggerd voordat je eigen code draait. Een goed beveiligde applicatie beschermt niet.
- Volledige overname. Succesvolle exploitatie geeft een aanvaller de rechten van het PHP-proces: toegang tot databasewachtwoorden, configuratie, uploads en vaak een opstap naar de rest van het netwerk.
- Mod_php het meest kwetsbaar. PHP zelf beoordeelt Apache met mod_php als de configuratie met het hoogste risico.
- Actieve aanvallen. Cloudflare en watchTowr melden exploitatiepogingen sinds 21 oktober. CISA had op dezelfde dag nog geen bevestigde inbraken gezien. Schattingen gaan uit van 1,3 tot 1,9 miljoen kwetsbare hosts die direct aan internet hangen.
- Overheden adviseren offline halen. Het Britse NCSC, CERT-EU en de NSA raden aan systemen die niet direct gepatcht kunnen worden, van internet af te halen tot de update is doorgevoerd.
Let op bij exploitcode van internet. De PHP Foundation waarschuwt dat veel circulerende "proof of concepts" niet werken of malware bevatten. Test niet met onbekende scripts op productiesystemen.
Welke versies moet je updaten?
Alle PHP-versies vanaf 5.4 tot en met de releases vóór de patch zijn kwetsbaar. Controleer je versie met php -v op de server, of via phpinfo(). Vergeet niet dat een server meerdere PHP-versies naast elkaar kan draaien (bijvoorbeeld per website in Plesk, DirectAdmin of cPanel).
| PHP-reeks | Kwetsbaar | Gepatchte versie | Status |
|---|---|---|---|
| 8.5.x | alles vóór 8.5.12 | 8.5.12 | Update beschikbaar |
| 8.4.x | alles vóór 8.4.27 | 8.4.27 | Update beschikbaar |
| 8.3.x | alles vóór 8.3.36 | 8.3.36 | Update beschikbaar |
| 8.2.x | alles vóór 8.2.35 | 8.2.35 | Update beschikbaar |
| 8.1.x, 8.0.x, 7.4.x | alle versies | Geen officiële release; alleen minimale source-patches | End-of-life, vendor-patch nodig |
| 7.3.x en ouder (t/m 5.4) | alle versies | Geen fix van het PHP-project | Migreren of offline halen |
Draai je een Linux-distributie?
Distributies en LTS-leveranciers (Debian, Ubuntu, Red Hat, AlmaLinux, Rocky, SUSE) kregen de patches onder embargo en brengen eigen pakketten uit. Die pakketten houden vaak het oude versienummer maar bevatten wél de fix (backport). Kijk dus niet alleen naar php -v, maar controleer de changelog van het pakket of het security-advisory van je distributie.
Gebruik je de populaire Remi-repository (rpms.remirepo.net)? Die werd op 21 oktober nog niet bijgewerkt. Schakel in dat geval over op de distributiepakketten of bouw vanuit source.
Stappenplan
- Inventariseer. Welke servers, containers en hostingpakketten draaien PHP, en welke versie? Vergeet interne tools, oude webshops, monitoring-dashboards en staging-omgevingen niet.
- Update naar een gepatchte versie. Minimaal 8.2.35, 8.3.36, 8.4.27 of 8.5.12, of het gepatchte pakket van je distributie. Herstart daarna alle PHP-workers (php-fpm, Apache, LiteSpeed).
- Kun je niet direct updaten? Pas tijdelijke mitigaties toe. Zie hieronder. Deze verkleinen het risico, maar maken de installatie niet veilig.
- Overweeg offline halen bij systemen op PHP 7.3 of ouder, of waar updaten dagen gaat duren. Beperk toegang tot een VPN of een IP-allowlist.
- Zet een WAF in als tussenlaag. Cloudflare heeft regels uitgerold voor de bekende aanvalsvectoren, ook op het gratis plan. Dit is een noodverband, geen oplossing: het dekt alleen verkeer dat via Cloudflare loopt.
- Controleer op compromittering. Kijk in webserverlogs naar afwijkende requests rond 20–21 oktober, onverwachte PHP-bestanden in upload-mappen, nieuwe cronjobs en onbekende processen onder de webserver-gebruiker.
Tijdelijke mitigaties (alleen als updaten echt niet lukt)
Pas deze instellingen toe in php.ini op een manier die applicaties niet kunnen overschrijven, en herstart daarna alle PHP-workers.
; Tegen CVE-2026-109618 (OOM-corruptie)
memory_limit = -1
; Tegen CVE-2026-109619 (stale global state)
session.upload_progress.enabled = 0
; Alleen op PHP 8.5, aanvullend
fatal_error_backtraces = 0
memory_limit = -1 haalt de geheugenbegrenzing van PHP weg. Zet daarom een harde limiet op proces- of containerniveau (cgroup, systemd MemoryMax) en dwing request-groottelimieten af in de webserver of reverse proxy. Het uitschakelen van session.upload_progress blokkeert de bevestigde aanvalspaden, maar niet noodzakelijk alle varianten.
Samengevat: update vandaag naar 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 of het gepatchte distributiepakket, herstart alle PHP-workers, en plan een migratie weg van PHP 8.1 en ouder.
Bronnen
- Help Net Security: PHP2Shell, critical PHP vulnerabilities patched
- Tenable: php2shell FAQ (CVE-2026-109618, CVE-2026-109619)
- The Hacker News: PHP issues emergency patches for two critical RCE flaws
- AlmaLinux: patched PHP packages available
- SecurityWeek: mass exploitation looms for leaked critical PHP flaws
- Wikipedia: PHP2Shell
De situatie ontwikkelt zich snel. Controleer de officiële PHP-advisories voor de meest actuele informatie.