PHP2Shell: wat het PHP-lek is en hoe je het patcht

Het PHP-lek PHP2Shell bestaat uit twee kritieke kwetsbaarheden in PHP zelf, bekend als CVE-2026-109618 en CVE-2026-109619. Een aanvaller die niet is ingelogd kan er code mee uitvoeren op elke server die PHP-pagina's serveert. De oplossing is een PHP-update: 8.5.12, 8.4.27, 8.3.36 of 8.2.35, of het gepatchte pakket van je distributie, gevolgd door een herstart van elke PHP-worker.

De details lekten op 20 oktober uit, twee dagen voor de geplande bekendmaking. Het PHP-project bracht de fixes daarop een dag eerder uit dan gepland, op 21 oktober. Draait er bij jou iets op PHP (WordPress, WooCommerce, Drupal, Magento, Laravel, een controlepaneel), controleer dan vandaag nog je versie.

Wat is het PHP-lek PHP2Shell?

PHP2Shell is de naam die onderzoekers gaven aan twee bugs in de PHP-runtime die remote code execution mogelijk maken. Onderzoekers van Calif, Wiz, OpenAI en Quarkslab meldden ze. PHP geeft beide een 9.2 op CVSS v4.0.

De bugs zitten in de manier waarop PHP een binnenkomend request parseert, nog voordat je applicatiecode start. WordPress, een plugin of je framework updaten helpt hier dus niet. De PHP-binary zelf moet worden vervangen.

De advisory van PHP noemt elke setup die webrequests afhandelt: PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed. Het grootste risico ligt volgens PHP bij Apache met mod_php. Daar is een exploit gedemonstreerd waarbij één request zonder inlog de aanval start voordat er ook maar een regel applicatiecode draait. De advisory beschrijft daarnaast RCE via de functie session upload progress op PHP-FPM, als de applicatie aan bepaalde voorwaarden voldoet.

Welke PHP-versies zijn kwetsbaar?

Alles vóór de vier gepatchte releases. Dit staat in de advisory van PHP en in de securityreleases van 21 oktober:

Cloudflare en Imperva zeggen dat de bugs teruggaan tot PHP 5.4. De advisory van PHP noemt alle versies onder de gepatchte releases kwetsbaar, maar geeft geen eerste getroffen versie.

Je versienummer kan oud lijken en toch gepatcht zijn. Linux-distributies backporten fixes en houden het oude upstream-nummer aan. Ubuntu 24.04 levert de fix als 8.3.6-0ubuntu0.24.04.13, dat nog altijd 8.3.6 meldt. Debian 12 heeft 8.2.35-1~deb12u1 (DLA-4848-1) en Debian 13 heeft 8.4.27-1~deb13u1 (DSA-6574-1). Vergelijk het volledige pakketversienummer met de security tracker van je distributie, niet alleen de eerste drie cijfers.

Wordt het PHP-lek al misbruikt?

De berichten spreken elkaar tegen en veranderen per uur. Wat de bronnen meldden, op volgorde:

• 17 oktober: Amazon Threat Intelligence zag een exploitpoging voor PHP2Shell op zijn MadPot-honeypots, vier dagen voor de patches. Het request kwam van een IP-adres dat hoort bij een commerciële anonimiseringsdienst.
• 20 oktober: de details lekten online uit. watchTowr bevestigde dat de bugs echt waren. Huntress zei geen misbruik te hebben gezien en geen publieke exploitcode te kennen.
• 21 oktober, 03:02 UTC: Cloudflare zette WAF-regels voor PHP2Shell aan. Later schreef het bedrijf aanvalsverkeer richting zijn klanten te zien, waarbij aanvallers de payload aanpasten om de regels te omzeilen.
• 21 oktober, 14:00 UTC: PHP bracht de fixes uit. watchTowr meldde dezelfde dag misbruik van beide bugs op zijn honeypotnetwerk.
• 21 oktober, middag (VS): de directeur van de PHP Foundation vertelde CNBC dat er geen bewijs was voor werkende exploits, alleen "onvolledige, misplaatste en niet-werkende gegenereerde" exemplaren. Imperva zag tijdens zijn eigen monitoring vóór de bekendmaking geen bijpassend verkeer.
• 23 oktober: geen van beide CVE's staat al in de Known Exploited Vulnerabilities-catalogus van CISA (die werd voor het laatst bijgewerkt op 21 oktober).

De onderzoekers bouwden werkende exploits, en andere teams zeggen de bugs te hebben nagebootst. Ga ervan uit dat aanvallers dat ook kunnen. Behandel elke ongepatchte PHP-server die aan het internet hangt als blootgesteld.

Zo controleer je je PHP-versie

Controleer de PHP die webrequests afhandelt. Op veel servers is de PHP op de commandline een andere build dan die achter de website.

Op de server:

php -v                     # command line PHP
php-fpm8.3 -v              # the FPM build (the name varies: php-fpm, php-fpm8.4)
apachectl -M | grep php    # a php_module line means Apache runs PHP as mod_php
dpkg -l | grep php         # Debian/Ubuntu: the full package versions
rpm -qa | grep php         # RHEL, Rocky, Alma, Fedora

Vanuit de browser: zet een bestand info.php met de inhoud <?php phpinfo(); in je webroot, open het en lees bovenaan de versie en de regel Server API (die vertelt of het FPM, Apache 2.0 Handler of CGI is). Verwijder het bestand direct daarna, want het toont je complete configuratie.

In WordPress: ga naar Gereedschap > Site gezondheid > Info (in het Engels: Tools > Site Health > Info) en open Server. De regel met de PHP-versie is de versie waarop je site draait.

In een hostingpaneel: cPanel toont de versie onder MultiPHP Manager of Select PHP Version, Plesk en DirectAdmin bij de PHP-instellingen van het domein, en de meeste managed hosts op de overzichtspagina van de site.

In Docker: docker exec <container> php -v meldt de PHP in de draaiende container, en dat is degene die telt.

Wil je van buitenaf testen? Volgens Help Net Security heeft Searchlight Cyber een opensource-checker gepubliceerd, php2shell-scanner. Gebruik die alleen op hosts die van jou zijn.

Zo patch je PHP2Shell

De volgorde die voor elke stack geldt: eerst de servers die aan het internet hangen, daarna elk PHP-proces herstarten. Een gepatchte binary op schijf doet niets zolang oude workers nog requests afhandelen.

Debian en Ubuntu

sudo apt update && sudo apt upgrade
sudo systemctl restart php8.3-fpm   # match your version
sudo systemctl restart apache2      # if you use mod_php

Controleer daarna de pakketversies met dpkg -l | grep php tegen de security tracker van Debian of Ubuntu. Op Ubuntu 20.04 en ouder komen de gepatchte 7.x-pakketten via Ubuntu Pro. Externe repositories updaten in hun eigen tempo: volgens Help Net Security had rpms.remirepo.net op de releasedag nog geen update. Check dus of die van jou al is bijgewerkt voordat je erop vertrouwt.

RHEL, Rocky, AlmaLinux en Fedora

Draai sudo dnf upgrade 'php*' en herstart daarna php-fpm en httpd. Zoek in de advisory van je leverancier het gepatchte pakketversienummer op, want dat komt niet overeen met het upstream-nummer.

Docker-images

De officiële php-images op Docker Hub kregen op 21 oktober de tags 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Pin er één, bouw opnieuw en deploy:

FROM php:8.4.27-fpm

docker compose build --pull && docker compose up -d

Een draaiende container houdt zijn oude PHP tot je hem vervangt. Images die op php voortbouwen (ook wordpress) hebben eveneens een verse pull en een nieuwe deploy nodig.

Shared hosting met cPanel, DirectAdmin of Plesk

Hier kun je PHP niet zelf patchen. De host werkt de PHP-builds bij die het paneel aanbiedt (op de meeste cPanel-servers ea-php van EasyApache of alt-php van CloudLinux). Bij hosts als TransIP, Hostnet of Vimexx kies je de PHP-versie in het controlepaneel, en de host patcht PHP zelf. Kijk op de statuspagina van je host of vraag de support of hun PHP-builds de fixes voor CVE-2026-109618 en CVE-2026-109619 bevatten. Draait je site nog op 7.4 of 8.1, zet hem dan op 8.3 of nieuwer via MultiPHP Manager of Select PHP Version in cPanel, of via de PHP-instellingen van het domein in DirectAdmin en Plesk. Test dat bij voorkeur eerst op een stagingkopie, als je die hebt.

Managed WordPress-hosting

Je host patcht PHP voor je. Voor deze PHP-kwetsbaarheid is volgens WordPress.org geen WordPress-update nodig, en er staat er ook geen gepland. Controleer of de host de fix heeft uitgerold en kijk daarna in Site gezondheid > Info > Server. Staat de site op PHP 8.1 of ouder, zet hem dan hoger, want die takken krijgen alleen nog backports van leveranciers.

Windows en zelf gecompileerde builds

Gepatchte broncode en Windows-binaries staan op de downloadpagina van php.net. Voor 7.4, 8.0 en 8.1 publiceerde PHP minimale source-backports voor wie PHP zelf bouwt.

Als je vandaag niet kunt patchen

PHP is daar duidelijk over: alleen een update is een volledige fix. De advisory noemt instellingen die bepaalde aanvalspaden blokkeren zonder een server veilig te maken:

• Zet session.upload_progress.enabled=0 in php.ini, de FPM-pool of de serverconfig (niet via ini_set() of .user.ini) en herstart elke worker. Dat blokkeert de bevestigde paden via sessies.
• Zet op PHP 8.5 fatal_error_backtraces=0 en herstart elke worker.
• Zet memory_limit=-1 op een manier die applicaties niet kunnen overschrijven, zoals php_admin_value. Combineer dat met een lage post_max_size (8M zonder uploads, 32M met) en een geheugenlimiet voor de container of cgroup. Gebruik geen RLIMIT_AS of RLIMIT_DATA, want die kunnen de bug juist triggeren.
• Begrens op de webserver of proxy de requestgrootte, het aantal velden, het aantal multipart-delen en de nestdiepte, en blokkeer multipart-requests als de site nooit uploads ontvangt.

Test elke wijziging voordat je hem uitrolt, want sommige breken uploads. Kan een server niet op tijd worden gepatcht of afgeschermd, dan zeggen het Britse NCSC en WordPress.org allebei: overweeg hem offline te halen, of zet hem achter een VPN of een allowlist zodat alleen bekende adressen erbij kunnen.

Beperk de blootstelling terwijl je patcht

Niets hiervan houdt een scanner tegen die requests stuurt. Massaal misbruik van een verse bug is geautomatiseerd: scripts speuren het internet af naar PHP-servers en vuren de exploit op elke server af. Die scanners draaien meestal op gehuurde servers in hosting- en datacenternetwerken, of lopen via VPN's, proxy's en Tor. Amazons eerste waarneming kwam van een anonimiseringsdienst. Echte bezoekers browsen zelden vanuit een datacenter.

Dat geeft je een tweede laag voor de dagen die het kost om alles te patchen: weiger requests uit die netwerken voordat ze PHP bereiken. IPScanner detecteert PHP2Shell niet en repareert PHP niet. Het controleert wie er verbinding maakt, deelt elke bezoeker in een klasse in (mens, geverifieerde crawler, kwaadaardige automatisering, hosting, Tor, VPN, proxy en nog een paar) en blokkeert de klassen die jij kiest.

De check moet vóór PHP draaien. PHP2Shell gaat af terwijl PHP het request parseert, dus alles wat binnen PHP draait, begint te laat.

De WordPress-plugin en de WooCommerce-checks houden nepaanmeldingen, spam en card testing bij je formulieren tegen. Voor PHP2Shell zitten ze op de verkeerde laag. Heb je een WordPress-site op één Apache-server zonder iets ervoor, dan krijg je de snelste gate door Cloudflare met de Worker ervoor te zetten.

Draai eerst in monitor-modus en blokkeer pas daarna. In monitor-modus wordt elk oordeel vastgelegd en wordt niets geblokkeerd, zodat je ziet wie je PHP-endpoints bestookt voordat je iets verandert. Zet na een paar uur hosting, Tor en kwaadaardige automatisering op blokkeren. VPN en proxy zijn een afweging: blokkeer ze op een beheerpaneel, denk twee keer na bij een publieke webshop. Geverifieerde zoekmachines en AI-crawlers uit de crawlerdirectory komen altijd door.

Blokkeren kan vanaf het Starter-abonnement. Op Free draait een site alleen in monitor-modus. Nieuwe accounts krijgen zeven dagen de functies van Starter, zonder creditcard, en dat dekt een patchperiode. Zie prijzen.

Wees eerlijk over de grenzen:

• Een aanvaller op een thuisverbinding of een residential proxy die de checks missen, bereikt PHP nog steeds.
• De gates falen open. Is de IPScanner-API traag of onbereikbaar, dan gaan requests door, zodat de site in de lucht blijft.
• Een gate helpt alleen als het verkeer erdoorheen gaat. Antwoordt je origin op zijn publieke IP, dan slaat een scanner Cloudflare gewoon over. Laat de origin dus alleen verbindingen accepteren uit de IP-ranges van Cloudflare.

Zit je site achter Cloudflare, laat dan ook de managed WAF-regels aanstaan. Volgens Cloudflare draaien de PHP2Shell-regels sinds 21 oktober standaard op elk abonnement. Die regels kijken naar het request zelf; IPScanner kijkt naar wie het stuurde. Geen van beide vervangt de patch.

Controleer of iemand is binnengekomen

Stond een server sinds half oktober ongepatcht en bereikbaar, kijk dan goed voordat je verdergaat. De advisories en incident responders wijzen op dezelfde signalen:

• grote of diep geneste multipart-POST-requests naar .php-paden, vaak met PHP_SESSION_UPLOAD_PROGRESS in de body
• foutmeldingen "Allowed memory size exhausted" en golven gecrashte of herstarte PHP-workers in de errorlogs
• nieuwe of gewijzigde bestanden in de webroot, nieuwe cronjobs of gebruikersaccounts
• PHP- of webserverprocessen die shells starten of uitgaande verbindingen maken die je niet herkent

Vermoed je een inbraak, isoleer de server dan en bewaar de logs voordat je iets herstart. Vervang daarna elk geheim dat PHP kon lezen: databasewachtwoorden, API-sleutels, sessiesleutels.

Checklist: het PHP-lek dichten

1. Inventariseer elke PHP-installatie die je draait, die aan het internet eerst, inclusief controlepanelen, appliances en containers.
2. Zoek de versie die webrequests afhandelt (phpinfo, Site gezondheid, php-fpm -v), niet alleen php -v.
3. Installeer 8.5.12, 8.4.27, 8.3.36, 8.2.35 of het gepatchte pakket van je distributie.
4. Herstart elke PHP-FPM-pool en elke Apache- en LiteSpeed-worker; bouw containers opnieuw en deploy ze.
5. Zit je op 8.1 of ouder, regel dan een backport van een leverancier of upgrade; lukt geen van beide, haal de site offline of zet hem achter een allowlist.
6. Kun je nog niet patchen? Pas de tijdelijke instellingen van PHP toe en beperk de toegang.
7. Zet een gate vóór PHP (Cloudflare, Traefik, Caddy, nginx), begin in monitor-modus en blokkeer daarna hosting, Tor en kwaadaardige automatisering.
8. Laat je origin alleen verkeer accepteren van de proxy die ervoor staat.
9. Doorzoek je logs vanaf 17 oktober op de signalen hierboven.
10. Vervang de geheimen op elke server die ongepatcht en bereikbaar was.

Bronnen: PHP-securityadvisory, GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp, WordPress.org, Cloudflare, watchTowr FAQ, watchTowr, Help Net Security, SecurityWeek, The Hacker News, CNBC, Imperva, Qualys, Armis, Ubuntu, Debian.