PHP2Shell (CVE-2026-109618 en CVE-2026-109619): wat bedrijven met PHP nu moeten doen

Een technicus met een laptop aan het werk bij een serverrack

Op 21 oktober 2026 bracht het PHP-project PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35 uit om twee kwetsbaarheden te verhelpen die “het op afstand uitvoeren van code zonder authenticatie mogelijk kunnen maken”. Eenvoudig gezegd: iedereen die een HTTP-verzoek naar uw website kan sturen, kan mogelijk eigen code op uw server uitvoeren. Een wachtwoord is daarvoor niet nodig, en bij sommige configuraties werkt de aanval voordat uw applicatie ook maar één regel heeft uitgevoerd. Het tweetal heeft de naam PHP2Shell gekregen, en PHP geeft beide een score van 9,2 (CVSS 4.0, op een schaal van 10).

Deze gids is bedoeld voor de mensen die ermee aan de slag moeten: eigenaren van PHP-websites en webwinkels, IT-managers en iedereen die PHP door een leverancier laat draaien. Hij is geschreven op 22 oktober 2026, de dag na de release, op basis van de eigen advisories van het PHP-project, de richtlijnen van nationale cybersecuritydiensten en de cijfers die leveranciers hebben gepubliceerd. Waar de bronnen elkaar tegenspreken, zeggen we dat.

In het kort

Update PHP zelf en herstart het daarna. Een update van WordPress, Drupal, Laravel of een plug-in lost dit niet op. De fout zit in PHP, onder uw applicatie.
Elke PHP-installatie die webverzoeken afhandelt, valt eronder, volgens PHP: PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed. PHP ziet Apache met mod_php als het grootste risico.
Bijna de helft van de PHP-websites draait op een branch waarvoor het PHP-project geen releases meer uitbrengt (onze lezing van de cijfers van W3Techs, zie verderop). Daarvoor is er geen officieel pakket om te installeren.
Instellingen en firewalls kopen tijd, geen veiligheid. PHP noemt tijdelijke maatregelen en zegt dat die “een installatie niet veilig maken”.
Kunt u vandaag niet patchen, dan geven de instanties in de VS, het VK en de EU hetzelfde advies: haal het systeem van internet tot u dat wel kunt.

Wat er gebeurde, op een rij

19 augustus 2026. Onderzoekers van Wiz vinden de eerste van de kwetsbaarheden, volgens hun openbaarmaking, en melden ze op 24 augustus bij het beveiligingsteam van PHP. In de advisories van PHP worden ook onderzoekers van verschillende andere bedrijven vermeld.
20 oktober. De CVE-nummers lekken twee dagen voor de geplande openbaarmaking online uit. PHP vervroegt zijn release met een dag, naar 21 oktober om 14:00 UTC, en vraagt iedereen zich voor te bereiden.
21 oktober, 03:02 UTC. Cloudflare zet firewallregels aan voor elke klant met zijn WAF, ook op het gratis abonnement. Later meldt het bedrijf dat het “aanvalsverkeer waarnam dat op onze klanten was gericht” en zag dat aanvallers “de payload van de aanval aanpasten om te proberen onze beveiliging te omzeilen”.
21 oktober, rond 14:00 UTC. PHP publiceert de fixes en zijn advisory. Dezelfde dag roepen CISA in de VS, het Britse NCSC, CERT-EU en een gezamenlijke verklaring van de Europese Commissie, ENISA, CERT-EU, Europol en de nationale CSIRT's van de EU organisaties allemaal op om onmiddellijk te patchen.

Hoe ernstig is het?

Drie dingen onderscheiden dit van de gebruikelijke maandelijkse patch.

De aanvaller heeft niets nodig behalve een verzoek. Geen login, en niemand hoeft op een link te klikken. De advisory van PHP beschrijft een gedemonstreerde exploit tegen Apache met mod_php “waarbij een verzoek zonder authenticatie de aanval kan starten voordat er applicatiecode draait”. Wiz demonstreerde aanvallen op actuele versies van WordPress, Drupal en Joomla, en merkt op dat “zelfs een eenvoudige ‘Hello World’-applicatie op een getroffen PHP-versie kwetsbaar kan zijn”. Code die zo wordt uitgevoerd, heeft de rechten van het account van de webserver, en dat account kan op de meeste sites de configuratie van de applicatie lezen: het databasewachtwoord, API-sleutels, inloggegevens voor mail en betalingen. Voor de tweede kwetsbaarheid, CVE-2026-109619, bevestigt PHP ook het uitlekken van geheugen: gegevens uit het geheugen van de server die naar buiten komen, ook zonder volledige uitvoering van code.

Het aantal installaties is enorm. Volgens W3Techs draait PHP op 69,3% van de websites waarvan de server-side programmeertaal bekend is (cijfers van 22 oktober 2026). Unit 42 van Palo Alto Networks telt op basis van eigen internetscans meer dan 22,6 miljoen blootgestelde instanties die mogelijk kwetsbaar zijn, en meldt dat ten minste één Europese overheid haar website uit voorzorg offline haalde.

Het werk aan exploits gaat snel. CERT-EU meldt dat eerste proofs of concept “zijn gaan circuleren”. Het beveiligingsbedrijf watchTowr zegt dat zijn honeypots sinds 21 oktober misbruik registreren. Cloudflare meldt aanvalsverkeer. En Wiz zegt dat zijn onderzoekers de hele tijd AI-modellen gebruikten, zodat één onderzoeker in een week deed wat “een team van wereldklasse maanden zou hebben gekost”. Aanvallers die een exploit aanpassen aan uw PHP-versie, hebben dezelfde tools.

Eerlijk is eerlijk: toen CISA op 21 oktober zijn waarschuwing publiceerde, had het geen misbruik waargenomen, en stond geen van beide kwetsbaarheden al in zijn catalogus Known Exploited Vulnerabilities (bekende misbruikte kwetsbaarheden). Red Hat beoordeelt het probleem als “Important” en niet als kritiek, omdat een standaardserver met Red Hat Enterprise Linux PHP-FPM draait, waar misbruik moeilijker is. Moeilijker is niet onmogelijk: PHP bevestigt dat één route voor de tweede kwetsbaarheid ook op PHP-FPM werkt. Niets hiervan verandert wat u moet doen. Het verandert alleen hoeveel waarschuwing u krijgt.

Welke versie draait u? De cijfers

W3Techs publiceert ook welke PHP-versies websites draaien, op basis van de sites die hun versie laten zien. Als we de twee tabellen van 22 oktober 2026 combineren:

PHP-branch	Aandeel van de PHP-websites	Fix van het PHP-project
8.3, 8.4, 8.5	ongeveer 34%	Ja: 8.3.36, 8.4.27, 8.5.12
8.2	ongeveer 18%	Ja: 8.2.35. Maar 8.2 zelf bereikt op 31 december 2026 het einde van zijn levensduur
8.0, 8.1	ongeveer 14%	Geen release. 8.0 en 8.1: alleen een backport in broncode
7.x	26,9%	Geen release. 7.4: alleen een backport in broncode; 7.3 en ouder: niets
5.x en ouder	7,8%	Niets

Ongeveer 48% van de PHP-websites draait dus op een branch waarvoor het PHP-project geen gepatchte release publiceert, en nog eens 18% krijgt nu zijn fix en verliest over tien weken de ondersteuning.

Twee kanttekeningen. W3Techs ziet alleen de sites die hun versie tonen. En een Linuxdistributie kan een oude branch zelf hebben gepatcht: Ubuntu heeft dat gedaan, zoals u hieronder ziet. Het versienummer alleen vertelt u niet of u beschermd bent. De versie van het pakket van uw leverancier wel.

Stap 1: breng al uw PHP in kaart

Wat u niet in beeld hebt, kunt u niet patchen, en PHP verstopt zich goed. Het Britse NCSC vraagt organisaties elk PHP-systeem op te sporen, te beginnen met de systemen die vanaf internet bereikbaar zijn, en voegt toe: “beperk de inventarisatie niet tot verouderde PHP-versies”. De gezamenlijke EU-verklaring waarschuwt dat sommige producten “door deze kwetsbaarheden getroffen kunnen zijn, ook als ze PHP niet direct lijken te gebruiken”.

Waar u moet kijken:

Websites en webwinkels: WordPress en WooCommerce, Drupal, Joomla, Magento en Adobe Commerce, Shopware, PrestaShop, TYPO3, en alles wat op Laravel of Symfony is gebouwd.
De vergeten systemen: microsites van campagnes, een oude taalversie, staging- en testservers die vanaf internet bereikbaar zijn, de webmail of helpdesk die iemand jaren geleden heeft geïnstalleerd.
Containers: elke image die is gebouwd op een php-basisimage heeft zijn eigen PHP aan boord. De host updaten doet daar niets aan.
Beheerpanelen voor hosting: cPanel, Plesk en vergelijkbare panelen leveren hun eigen PHP-builds naast die van het systeem. Elke versie die in het paneel is ingeschakeld, moet apart worden bijgewerkt.
Producten met PHP aan boord: appliances, monitoringtools, CRM's, helpdesks en beheerinterfaces van leveranciers. Het NCSC houdt een openbare lijst van zulke producten bij met hun status, leverancier voor leverancier.
Leveranciers: uw hostingbedrijf, uw bureau, elke dienst waarvan u weet dat er PHP onder zit. Vraag ze schriftelijk welke PHP-versies uw systemen draaien en wanneer die worden gepatcht.

Noteer voor elk systeem de PHP-versie, hoe PHP draait (mod_php, PHP-FPM, LiteSpeed, FrankenPHP, een container), of het vanaf internet bereikbaar is, en wie het kan patchen.

Stap 2: patchen, in de juiste volgorde

Begin met alles wat vanaf internet bereikbaar is, en daarbinnen met configuraties van Apache met mod_php.

Op een ondersteunde branch (8.2 tot en met 8.5). Update naar 8.5.12, 8.4.27, 8.3.36 of 8.2.35, of naar het pakket van uw distributie dat de fix bevat. PHP zegt dat Linuxdistributies de patches vooraf hebben gekregen. Tot nu toe bevestigd:

Ubuntu: gepatchte pakketten voor elke release van 14.04 tot en met 26.10. Op 22.04 en later komen ze met de gewone updates mee; op 20.04 en ouder is een abonnement op Ubuntu Pro nodig, dat gratis is voor maximaal vijf machines (de mededeling van Canonical).
Debian: php8.4 8.4.27 voor Debian 13 (DSA-6574-1) en php8.2 8.2.35 voor Debian 12 (DLA-4848-1).
Red Hat Enterprise Linux: het beveiligingsbulletin RHSB-2026-013 van Red Hat vermeldt de pakketten per release.
De Remi-repository, veel gebruikt voor nieuwere PHP-versies op systemen uit de Red Hat-familie: CERT-EU merkte op 21 oktober op dat die op de releasedag geen pakketten had, en adviseerde over te stappen op pakketten van de distributie of zelf vanuit de broncode te bouwen. Controleer of de repository de achterstand heeft ingehaald voordat u erop vertrouwt.

Op PHP 7.4, 8.0 of 8.1. Het PHP-project publiceert voor deze versies geen release. Het beveiligingsteam maakte minimale backports in broncode voor de drie branches; daar hebt u iets aan als u PHP zelf compileert. Anders moet de fix van uw leverancier komen (Ubuntu Pro dekt bijvoorbeeld PHP 7.4 op Ubuntu 20.04) of van een upgrade van PHP. Het advies van CISA voor iedereen op 8.1 of ouder die niet kan updaten, is onomwonden: haal het systeem offline tot het is gepatcht of geüpgraded.

Op PHP 7.3 of ouder. Van het PHP-project komt niets. Tenzij een leverancier uw build nog patcht, is de keuze een upgrade of het systeem offline halen.

Herstart na het updaten. Een pakket installeren vervangt niet de PHP die al draait. De mededeling van Ubuntu zegt het zonder omwegen: de applicatie “zou waarschijnlijk opnieuw moeten worden gestart”. Herstart PHP-FPM, Apache, LiteSpeed of de container op elke server. Controleer daarna de versie die de webserver echt draait, niet alleen php -v op de opdrachtregel, want dat kan een andere build zijn.

Containers: bouw uw images opnieuw op basis van een gepatchte basisimage en rol ze opnieuw uit. Een gepatchte host die een oude image draait, is nog steeds blootgesteld.

Managed hosting: vraag uw provider naar de datum en de versie, en controleer het daarna zelf.

Stap 3: als u vandaag niet kunt patchen

De advisory van PHP noemt tijdelijke maatregelen en leidt ze in met een waarschuwing: ze “verkleinen de blootstelling aan specifieke aanvalspaden, maar maken een installatie niet veilig”. In het kort, voor wie uw servers beheert:

Voor CVE-2026-109618: stel memory_limit=-1 zo in dat de applicatie het niet kan overschrijven (bijvoorbeeld met php_admin_value in de PHP-FPM-pool of de Apache-configuratie); stel een lage post_max_size in (PHP stelt 8M voor zonder bestandsuploads, 32M met bestandsuploads); beperk de grootte van verzoeken, het aantal velden en het aantal multipart-delen op de webserver of proxy; en gebruik een geheugenlimiet voor de container of cgroup, nooit RLIMIT_AS of RLIMIT_DATA.
Voor CVE-2026-109619: zet session.upload_progress.enabled=0 in php.ini of de serverconfiguratie (niet met ini_set() of een .user.ini-bestand) en herstart elke worker. Zet op PHP 8.5 ook fatal_error_backtraces=0.

Twee waarschuwingen. De sessie-instelling die op 20 oktober breed rondging, sluit alleen paden van de tweede kwetsbaarheid af, zoals een lid van het beveiligingsteam van PHP opmerkte; tegen de eerste doet ze niets. En memory_limit=-1 haalt de eigen geheugenlimiet van PHP weg, zodat één zwaar verzoek de server nu kan uitputten. Combineer het met de limiet voor de container of cgroup.

Een web application firewall helpt, een beetje. De regels van Cloudflare staan standaard aan op elk abonnement met zijn WAF, ook op het gratis abonnement, en Palo Alto Networks en andere leveranciers hebben hun eigen beschermingen gepubliceerd. Toch zegt Cloudflare tegen klanten dat ze PHP moeten patchen, “ook met WAF-bescherming”, en het zag aanvallers hun payloads aanpassen om langs zijn regels te glippen. Een WAF beschermt bovendien alleen het verkeer dat erdoorheen gaat. Antwoordt uw server op zijn eigen IP-adres, dan kan een aanvaller eromheen.

Lukt niets hiervan snel, dan wijzen CISA, CERT-EU, het Britse NCSC en de gezamenlijke EU-verklaring allemaal dezelfde kant op: haal het systeem van het openbare internet tot het is verholpen. Een dag een onderhoudspagina kost minder dan een server die opnieuw moet worden opgebouwd.

Stap 4: controleer of er al is ingebroken

Het venster ging open op 20 oktober, toen het uitlekken begon, en de volgende ochtend werd aanvalsverkeer gemeld. Was een systeem in dat venster bereikbaar en ongepatcht, dan sluit patchen de deur, maar het vertelt u niet of iemand al eerder binnen is gekomen. Het Britse NCSC vraagt iedereen die niet direct kon patchen, te controleren op tekenen van compromittering en op backdoors.

Waar u op moet letten, volgens de gepubliceerde richtlijnen en de gangbare praktijk bij incidenten:

PHP-processen die dingen doen die PHP nooit doet, zoals een shell starten of tools downloaden (CISA).
Ongebruikelijke multipart-verzoeken gevolgd door foutmeldingen over de geheugenlimiet of herhaalde HTTP 500-responses, PHP-workers die zonder duidelijke reden herstarten, en ongewoon grote of misvormde PHPSESSID-cookies in responses (Wiz).
Nieuwe of gewijzigde PHP-bestanden in uploadmappen, cachemappen of de webroot, nieuwe beheerdersaccounts in uw CMS, en geplande taken die niemand heeft aangemaakt.

Schone logs zijn geen bewijs. De advisory van PHP over de tweede kwetsbaarheid waarschuwt daar juist voor, en Wiz merkt op dat applicatielogs mogelijk weinig context bevatten.

Vindt u iets, behandel het dan als een incident, niet als een patchklus. Isoleer de server, bewaar het bewijs, schakel een partij voor incidentrespons in, en wijzig elk geheim dat de webserver kon lezen: databasewachtwoorden, API-sleutels, inloggegevens voor betalingen en mail, ondertekeningssleutels. De tweede kwetsbaarheid kan geheugen laten uitlekken. Overweeg daarom de gevoeligste van die geheimen te roteren op elke server die dagenlang blootgesteld en ongepatcht was, ook zonder tekenen van inbraak.

Stap 5: wat u mogelijk moet melden

Een kwetsbaarheid op zich is geen meldingsplichtig incident. Een misbruikte kwetsbaarheid kan dat wel zijn.

NIS2: valt uw organisatie eronder en is een compromittering een significant incident, dan moet de vroege waarschuwing binnen 24 uur bij uw nationale CSIRT liggen. Zie onze NIS2-gids.
AVG: is er toegang geweest tot persoonsgegevens, dan moet u dat binnen 72 uur nadat u van het datalek op de hoogte bent geraakt melden bij de toezichthouder, tenzij het onwaarschijnlijk is dat het een risico voor mensen oplevert. Zie onze AVG-gids.
Cyber Resilience Act: verkoopt u software of een apparaat met PHP erin, dan bent u daarvan de fabrikant in de zin van de CRA. Sinds 11 september 2026 moeten fabrikanten actief misbruikte kwetsbaarheden in hun producten melden via het CRA Single Reporting Platform, zoals de gezamenlijke EU-verklaring in herinnering brengt. Zie onze CRA-gids.
Uw klanten: host of draait u PHP voor klanten, dan gaan zij ernaar vragen. Een korte schriftelijke notitie (wat u draait, wanneer het is gepatcht, wat u hebt gecontroleerd) beantwoordt de vragen van de meesten, en het is dezelfde notitie die een auditor of een cyberverzekeraar wil zien.

Na de noodsituatie: wat u moet veranderen

Op de meeste goed beheerde servers is PHP2Shell binnen enkele dagen gepatcht. Wat het over uw omgeving heeft blootgelegd, blijft daarna gewoon waar.

Weet hoe lang een patch bij u duurt. Van de advisory tot de laatste herstarte server: uren, dagen of weken? Is het eerlijke antwoord “dat zouden we aan het bureau moeten vragen”, los dat dan op vóór de volgende keer. Als onderzoekers zeggen dat AI hun exploitwerk van maanden terugbracht tot een week, ga er dan van uit dat aanvallers ook dat tempo aankunnen.
Houd de inventaris bij die u net hebt opgebouwd. Die was het moeilijkste deel van de aanpak, en hij veroudert zodra niemand er eigenaar van is.
Stap af van PHP-versies aan het einde van hun levensduur. Een site op 7.4 of 8.1 had deze keer een leverancier of een backport in broncode nodig; de volgende keer is er misschien geen van beide. PHP 8.2 bereikt op 31 december 2026 het einde van zijn levensduur, dus een site die 8.1 verlaat, moet meteen door naar 8.3 of later. Een overstap naar een andere PHP-versie betekent vaak dat ook de applicatie moet worden bijgewerkt: ons artikel over het einde van de levensduur van Drupal, Umbraco en Kentico laat zien wat dat voor één CMS inhoudt.
Kies waar het kan voor PHP-FPM boven mod_php. Dat was deze keer de configuratie met het lagere risico.
Laat de uploadvoortgang uit als u die niet gebruikt. De advisory van PHP raadt aan session.upload_progress.enabled ook na het patchen uit te laten staan als de applicatie het niet nodig heeft.
Leg patchtijden vast in uw contracten. Vraag uw hostingprovider en uw bureau hoe snel ze kritieke PHP-fixes doorvoeren, en zorg dat u het antwoord op schrift hebt.

Checklist voor deze week

Breng elke PHP-installatie in kaart, inclusief containers, beheerpanelen, producten van leveranciers en stagingservers.
Patch eerst de systemen die vanaf internet bereikbaar zijn, te beginnen met Apache met mod_php.
Herstart elk PHP-proces en controleer de versie die de webserver rapporteert.
Bouw de containerimages opnieuw en rol ze opnieuw uit.
Waar u vandaag niet kunt patchen: pas de tijdelijke instellingen van PHP toe, leid het verkeer via een WAF of haal het systeem offline.
Vraag leveranciers en hostingproviders schriftelijk naar hun PHP-versie en patchdatum.
Controleer logs en bestandswijzigingen op alles wat sinds 20 oktober blootgesteld en ongepatcht was.
Beslis of er een meldplicht geldt (NIS2, AVG, CRA).
Plan de overstap weg van PHP 8.1 en ouder, en weg van 8.2 vóór 31 december.

Waar wij kunnen helpen

Het ontbreekt de meeste bedrijven niet aan de wil om te patchen. Wat ze missen, is een helder beeld van wat ze draaien, of de mensen om het werk deze week te doen. Dat deel nemen wij over:

Inventarisatie en patchen, in dagen. We vinden uw PHP-installaties op servers, in containers, in hostingpanelen en bij leveranciers, patchen ze, herstarten en controleren, en laten u een schriftelijk verslag na van wat er is gedaan en wanneer. Dat verslag is ook uw antwoord aan klanten en auditors.
Weg van oude PHP. Applicaties die vastzitten op PHP 7.x, 8.0 of 8.1 omdat de code op niets nieuwers draait: die zetten we over naar een ondersteunde versie binnen onze dienst voor onderhoud van legacysystemen.
Verharding en een patchroutine, zodat de volgende advisory een geplande klus is in plaats van een noodgeval.

Vindt u tekenen van een inbraak, schakel dan eerst een partij voor incidentrespons in. Wij kunnen naast hen de herbouw en de upgrade op ons nemen.

Schrijf naar office@c9group.dev wat u draait, en we antwoorden met wat we als eerste zouden doen.

Bronnen

Gecontroleerd op 22 oktober 2026. De situatie is nog in beweging: vooral de status van misbruik en de pakketten van leveranciers kunnen sindsdien zijn veranderd.

PHP-project

Instanties

Onderzoekers, leveranciers en gegevens