PHP2Shell: twee kritieke PHP-lekken, wat je nu moet doen

PHP heeft op 21 oktober 2026 noodpatches uitgebracht voor twee kritieke lekken waarmee een aanvaller zonder in te loggen code kan uitvoeren op je server. Update naar 8.5.12, 8.4.27, 8.3.36 of 8.2.35 en herstart daarna al je PHP-workers. Draai je PHP 8.1 of ouder, dan komt er geen officiële release en moet je upgraden.

De lekken, CVE-2026-109618 en CVE-2026-109619, kregen allebei een CVSS v4.0-score van 9.2. In de securitywereld heten ze inmiddels PHP2Shell. Details lekten een dag voor de geplande release uit, waardoor het venster tussen bekendmaking en eerste aanvallen naar verwachting kort is.

Wat er gebeurde

De lekken stonden onder embargo, zodat hosters en Linux-distributies tegelijk met de bekendmaking gepatchte pakketten konden uitbrengen. Dat embargo werd doorbroken door een post op Hacker News, waarna PHP de release naar voren haalde.

• 20 oktober: een "Tell HN"-post op Hacker News meldt twee aankomende PHP-RCE's; screenshots gaan rond op X en Mastodon.
• 20 oktober: watchTowr bevestigt dat het om echte RCE-lekken gaat; CERT-EU waarschuwt.
• 20 oktober, avond: PHP kondigt een kritieke security release aan voor de volgende dag (aankondiging).
• 21 oktober, 14:00 UTC: PHP brengt 8.5.12, 8.4.27, 8.3.36 en 8.2.35 uit, met een security advisory.

De twee lekken

Beide lekken zitten in hoe PHP een request opzet en weer opruimt. Dat gebeurt voordat jouw applicatiecode draait, dus middleware, loginchecks of een WAF-plugin in je app houden ze niet tegen.

• CVE-2026-109618: code-uitvoering via een out-of-memory-fout. Raakt PHP zonder geheugen terwijl de interne requestdata nog maar half is opgebouwd, dan kan de opruimcode die halve data als geldig behandelen.
• CVE-2026-109619: code-uitvoering via achtergebleven state. Interne request-state kan blijven bestaan nadat het geheugen al is vrijgegeven. Een volgende request op dezelfde worker kan die verouderde state dan gebruiken. De bevestigde routes lopen via session upload-progress en, op PHP 8.5, via fatal-error-backtraces.

Volgens PHP is het risico het grootst bij Apache met mod_php: daar kan één ongeauthenticeerd request de aanval uitvoeren voordat er applicatiecode draait.

Wie is getroffen

Iedereen die PHP via een webserver draait: PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed. De CLI noemt PHP niet als getroffen omgeving.

• PHP 8.5 (actieve support): update naar 8.5.12
• PHP 8.4 (actieve support): update naar 8.4.27
• PHP 8.3 (alleen security fixes): update naar 8.3.36
• PHP 8.2 (alleen security fixes, end of life op 31 december 2026): update naar 8.2.35
• PHP 8.1, 8.0 en 7.4 (end of life): geen release, alleen broncode-backports (8.1, 8.0, 7.4)
• PHP 7.3 en ouder (end of life): niets

Die backports zijn bedoeld voor wie PHP zelf compileert of geen LTS-leverancier heeft. Sommige distributies en LTS-leveranciers leveren eigen backports; vraag dat na bij je leverancier. Op de pagina PHP-versies zie je per versie tot wanneer hij ondersteund wordt.

Wat je nu moet doen

Updaten is volgens PHP de enige volledige oplossing. Zo pak je dat aan:

1. Inventariseer. Zoek elke server, container en appliance waarop PHP draait, ook staging en vergeten subdomeinen. Op Debian of Ubuntu laat ls /etc/php zien welke branches er staan.
2. Weet waar je PHP vandaan komt. Distributie, de PPA van Ondřej Surý, een Docker-image of een hostingpaneel: elk heeft een eigen moment waarop de gepatchte build verschijnt. Distributies backporten vaak zonder het versienummer te verhogen, dus controleer de changelog van het pakket.
3. Update alle branches op een server, ook die je niet gebruikt. Een draaiende PHP-FPM-pool zonder sites is nog steeds een aanvalsoppervlak. Gebruik je een branch niet, zet zijn FPM-dienst dan uit.
4. Herstart alles wat PHP draait. Na apt upgrade draaien bestaande processen nog de oude code. Herstart PHP-FPM per branch, en daarna queue workers, Horizon, Reverb, Octane en de scheduler. Oude processen vind je met ls -l /proc/*/exe | grep -i 'php.*deleted'.
5. Docker: bouw je images opnieuw op een gepatchte basisimage. Gedeelde hosting: vraag je provider om bevestiging.

Let op bij Ubuntu 20.04. De PPA van Ondřej Surý bouwt daar geen PHP-pakketten meer voor. Staat een server nog op 20.04, dan krijgt hij deze patch waarschijnlijk niet. Verhuis je sites dan naar een server met 22.04 of 24.04.

Kun je nog niet updaten?

PHP noemt een paar maatregelen die het risico verkleinen, maar benadrukt dat geen ervan een installatie veilig maakt. Zie ze als overbrugging tot de update.

• session.upload_progress.enabled=0 in php.ini of de FPM-pool, daarna alle workers herstarten. Helpt tegen de bevestigde sessieroutes van CVE-2026-109619, maar niet tegen alle varianten. Niet via .user.ini of ini_set(): die worden te laat toegepast.
• fatal_error_backtraces=0, alleen op PHP 8.5, daarna workers herstarten. Blokkeert alleen de backtrace-route van CVE-2026-109619.
• memory_limit=-1 via php_admin_value in de pool, tegen CVE-2026-109618. Een allocatiefout kan het pad nog bereiken, en zonder limiet per worker kan één request de server vol laten lopen.
• Een lage post_max_size (8M zonder uploads, 32M met), plus limieten op request-grootte in je webserver of proxy, tegen CVE-2026-109618. Verkleint het risico, sluit het niet af.

Twee dingen die wél eens worden genoemd, maar niet beschermen: Laravel maintenance mode en security-plugins in je applicatie. Die draaien pas nadat PHP de request al heeft verwerkt. Gebruik ook geen RLIMIT_AS of RLIMIT_DATA: die kunnen de kwetsbare allocatiefout juist uitlokken.

Wordt het al misbruikt?

Tot de release is er geen misbruik in het wild bevestigd. watchTowr meldde op 21 oktober geen gerapporteerde exploitatie, en de lekken stonden toen niet in de KEV-catalogus van CISA. Huntress zag tot 20 oktober niets in de omgevingen van zijn klanten.

Dat kan snel veranderen. Op GitHub staan al repositories die zich als proof of concept presenteren; die zijn niet onafhankelijk geverifieerd. Sansec verwachtte massa-exploitatie binnen ongeveer 15 minuten na de release (SecurityWeek), omdat de patch laat zien waar het lek zit.

Waar je op let als je logs doorzoekt:

• PHP-FPM-, php-cgi- of Apache-processen die een shell, curl, wget of een andere interpreter starten
• ongebruikelijke multipart/form-data-POSTs en crashende PHP-FPM-workers
• nieuwe of gewijzigde bestanden in webroots en uploadmappen, nieuwe cronjobs, SSH-sleutels of accounts

Bewaar je web- en PHP-logs vanaf 20 oktober voordat ze roteren. Zie je aanwijzingen voor een inbraak, isoleer de server dan, bouw hem opnieuw op en vervang alle secrets die de PHP-gebruiker kon lezen, zoals .env, databasewachtwoorden en API-sleutels.

Checklist

• Alle servers en containers met PHP geïnventariseerd
• Per server bekend waar PHP vandaan komt (distributie, PPA, Docker, hoster)
• Updates geïnstalleerd: 8.5.12, 8.4.27, 8.3.36 of 8.2.35, of de backport van je leverancier
• PHP-FPM herstart, plus queue workers, Horizon, Reverb, Octane en scheduler
• Ongebruikte PHP-branches uitgezet
• Servers op PHP 8.1 of ouder, of op Ubuntu 20.04, ingepland voor upgrade of verhuizing
• Logs vanaf 20 oktober veiliggesteld en nagelopen

Bronnen: php.net: security advisory, 21 oktober 2026, php.net: aankondiging van de security release, GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp, watchTowr, Huntress, Beazley Security Labs, Vincent Schmalbach, SecurityWeek, Cyber Security News.