PHP

PHP2Shell: kritieke lekken in PHP zelf

Twee kwetsbaarheden in PHP maken code-uitvoering op afstand mogelijk, zonder account en voordat de code van uw website draait. De patch kwam op 21 oktober, maar de eerste aanvalspoging is al van 17 oktober. Wat u moet controleren, ook als uw WordPress-plugins bij zijn.

Door Sander 22 oktober 2026 5 min leestijd

Een vergeten website kan een hele server meenemen, zoals we beschreven in Vier dagen te laat met één update. Deze keer zit het lek niet in een plugin, maar in PHP zelf.

In het kort

Twee kwetsbaarheden in PHP, samen PHP2Shell genoemd, laten een aanvaller zonder account code uitvoeren op de server.
Elke PHP-installatie die webverzoeken afhandelt is getroffen, van PHP 5.4 tot 8.5. Het maakt niet uit hoe goed uw WordPress, Drupal of Joomla is bijgewerkt.
De patch verscheen op 21 oktober. Amazon zag de eerste aanvalspoging al op 17 oktober.
Na het updaten moet u alle PHP-processen herstarten, anders draait de oude, kwetsbare versie gewoon door.

Wat is er aan de hand?

Op 21 oktober 2026 bracht het PHP-project PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35 uit. Die versies dichten twee kwetsbaarheden die volgens PHP code-uitvoering op afstand mogelijk maken zonder dat de aanvaller hoeft in te loggen. Beide hebben een CVSS-score van 9.2.

CVE-2026-109618. Als PHP zonder geheugen komt terwijl het een verzoek nog aan het opbouwen is, blijven interne gegevens half ingevuld achter. De opruimcode behandelt die gegevens daarna toch als geldig.
CVE-2026-109619. Interne gegevens van één verzoek blijven bestaan nadat het geheugen erachter al is vrijgegeven. Een volgend verzoek op hetzelfde PHP-proces kan die achtergebleven gegevens gebruiken.

Volgens PHP zijn alle installaties die webverzoeken afhandelen getroffen: PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed. Het risico is het grootst bij mod_php. Daar is aangetoond dat een verzoek zonder inlog de aanval al uitvoert voordat er ook maar één regel van de website zelf draait.

Dat laatste is het belangrijkste verschil met de meeste lekken in websites. Bij een kwetsbare plugin helpt het om die plugin bij te werken of uit te zetten. Hier zit het lek in de laag eronder. Een volledig bijgewerkte WordPress-site op een kwetsbare PHP-versie is gewoon kwetsbaar.

Wat is er bekend over aanvallen?

De berichten verschillen, dus hier precies wie wat zegt.

Amazon zag op 17 oktober een aanvalspoging op zijn honeypotnetwerk, vier dagen voor de bekendmaking, vanaf een anoniem netwerk. Op 21 oktober zag Amazon vanaf 02:00 UTC meerdere proof-of-concepts, met wisselende code die op meerdere aanvallers wijst. Volgens Amazon wordt PHP2Shell inmiddels breed misbruikt. Of de pogingen op echte servers ook zouden slagen, is volgens Amazon nog onduidelijk.
watchTowr heeft beide kwetsbaarheden nagebootst en ziet sinds 21 oktober aanvalspogingen op zijn honeypots.
Cloudflare meldde op 21 oktober dat de eerste aanvallen opdoken.
Het PHP-beveiligingsteam had bij de release nog geen werkende exploits gevonden. Er circuleert publieke aanvalscode, maar die is niet geverifieerd.
CISA had de kwetsbaarheden op 22 oktober nog niet op zijn lijst van actief misbruikte kwetsbaarheden gezet.

Samengevat: er wordt volop geprobeerd, en geslaagde inbraken zijn nog niet publiek bevestigd. Behandel dit als actief misbruikt. Het noodspoor uit ons patchproces is hiervoor bedoeld.

Er is ook iets misgegaan bij de bekendmaking. De details lekten op 20 oktober uit, twee dagen voor de geplande datum. PHP zette de release daarom een dag naar voren, naar 21 oktober om 14:00 UTC. De vroegste poging die Amazon zag, ligt nog eerder; hoe die aanvaller aan de informatie kwam, weet Amazon niet.

De kwetsbaarheden werden gevonden door onderzoekers van onder meer Calif en Wiz. Beide gebruikten volgens Tenable AI-modellen bij hun onderzoek, en de PHP Foundation noemt ook OpenAI bij de credits. Dat past in het patroon dat we vorige week beschreven in AI versnelt de aanval op bekende software.

Welke versie heeft u nodig?

Tak	Status	Wat te doen
8.5	Opgelost in 8.5.12	Updaten en herstarten
8.4	Opgelost in 8.4.27	Updaten en herstarten
8.3	Opgelost in 8.3.36	Updaten en herstarten
8.2	Opgelost in 8.2.35	Updaten; 8.2 stopt op 31 december 2026
7.4 tot en met 8.1	Geen officiële release	Pakket van uw distributie of leverancier, of overstappen
5.4 tot en met 7.3	Geen oplossing	Overstappen, tot dan afschermen

Linuxdistributies en leveranciers van langdurige ondersteuning kregen de patches vooraf, dus kijk eerst of uw distributie al een bijgewerkt pakket heeft. Voor 7.4, 8.0 en 8.1 heeft het PHP-team kleine aanpassingen in de broncode gepubliceerd voor wie zelf bouwt.

Let op als u de populaire externe pakketbron van Remi gebruikt: die had op de dag van de release nog geen updates. PHP raadt aan dan over te stappen op de pakketten van de distributie of zelf te bouwen.

Waarom herstarten zo belangrijk is

PHP-FPM en Apache houden PHP-processen in het geheugen om verzoeken snel af te handelen. Wie het pakket bijwerkt zonder die processen te herstarten, heeft het nieuwe bestand op schijf staan terwijl de oude, kwetsbare code in het geheugen doorwerkt. watchTowr noemt het herstarten van alle PHP-processen daarom als vaste stap na de update, en PHP doet dat ook bij de tijdelijke maatregelen hieronder.

Controleer dus niet alleen welk pakket er is geïnstalleerd, maar ook welke versie de webserver echt draait. Kijk daarvoor naar de starttijd van de PHP-processen: die moet na de update liggen. Een tijdelijk bestand met phpinfo() laat de draaiende versie zien, maar zet dat alleen op een afgeschermd adres en verwijder het direct daarna.

Als u niet direct kunt updaten

PHP is duidelijk: alleen een update lost het op. De volgende maatregelen verkleinen het risico, maar maken een installatie niet veilig.

Tegen CVE-2026-109618: zet memory_limit=-1, op een plek die de applicatie niet kan overschrijven, zoals php_admin_value in de FPM-pool. Houd post_max_size laag: 8M zonder bestandsuploads, 32M met uploads.
Tegen CVE-2026-109619: zet session.upload_progress.enabled=0 in php.ini of de FPM-pool, niet via ini_set() of .user.ini. Op PHP 8.5 ook fatal_error_backtraces=0.
Herstart daarna alle PHP-processen.
Blokkeer multipart-uploads waar de site die niet nodig heeft, zoals Amazon adviseert. Test dat eerst.
Een WAF kan helpen als tijdelijke laag. Cloudflare heeft regels uitgerold, ook voor het gratis abonnement, maar noemt dat zelf een noodmaatregel die alleen verkeer via Cloudflare beschermt.
Scherm af wat u niet kunt patchen. CERT-EU adviseert internetgerichte toepassingen te isoleren tot de oplossing is geïnstalleerd en gecontroleerd.

Wat u nu kunt doen

Maak een lijst van alles waar PHP op draait. Denk verder dan de hoofdwebsite: oude campagnesites, een intranet, een webwinkel, een ticketsysteem, een test- of stagingomgeving, en sites bij een hostingpartij.
Vraag uw hostingpartij of webbureau om bevestiging. Bij gedeelde hosting patcht de aanbieder PHP, niet u. Vraag welke PHP-versie uw site nu echt draait en of de processen zijn herstart.
Update naar de versie uit de tabel en herstart alle PHP-processen. Controleer daarna de versie die de webserver draait, niet alleen het pakket.
Kijk terug vanaf 17 oktober, niet vanaf 21 oktober. Zoek in de logbestanden van de webserver naar POST-verzoeken met de tekst PHP_SESSION_UPLOAD_PROGRESS, en op de server naar onverwachte processen en gewijzigde of nieuwe bestanden in de webmappen.
Controleer de adressen die Amazon noemt. Amazon zag pogingen vanaf onder meer 103.216.220.92 (17 oktober) en 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188 en 95.217.98.37 (21 oktober). Het gaat om gedeelde anonimiseringsnetwerken; Amazon raadt aan treffers te onderzoeken in plaats van de adressen simpelweg te blokkeren.
Plan de vervanging van oude PHP-versies. Alles van 7.3 en ouder krijgt geen oplossing, en 8.2 stopt eind dit jaar.
Vindt u sporen van misbruik, behandel het dan als incident. Stel bewijs veilig voordat u herinstalleert. Voor organisaties onder de Cyberbeveiligingswet loopt de meldtermijn vanaf het moment van constateren.