PHP2Shell: kritieke PHP-kwetsbaarheid met uitvoering van code op afstand (CVE-2026-109618, CVE-2026-109619)

Wat is PHP2Shell? Laatste nieuws

Op 21 oktober 2026 publiceerde het PHP-project een beveiligingsadvies over twee kritieke fouten in de PHP-runtime die uitvoering van code op afstand zonder authenticatie mogelijk maken. De gangbare naam is PHP2Shell, bij de CISA „php2shell”.

Wordt PHP2Shell misbruikt?

• AWS MadPot meldde een misbruikpoging op 17 oktober 2026, nog vóór de openbare bekendmaking.
• Cloudflare, AWS en watchTowr beschrijven na het advies grote aantallen misbruikpogingen; de CEO van Cloudflare schreef op 22 oktober dat de pogingen waren gestegen van duizenden naar miljoenen.
• Een bevestigde compromittering van bij naam bekende productiewebsites is in de voor deze pagina bekeken bronnen niet aangetoond. Volgens secundaire berichten stonden de CVE’s op 22 oktober niet in de KEV-catalogus van de CISA; controleer de KEV-catalogus zelf.

Is mijn PHP-versie getroffen door PHP2Shell?

Voer de PHP-versie in die uw web-SAPI meldt (php -v, hostingpaneel of phpinfo()). Deze controle vergelijkt alleen versienummers met de upstream fix-releases. Backports van leveranciers herkent ze niet.

• Pagina’s per tak: 8.5, 8.4, 8.3, 8.2, EOL 5–8.1.
• Totaaloverzicht: getroffen versies.
• Chinees hostingpaneel: 宝塔面板.

Welke sites en leveranciers raakt PHP2Shell?

Meer hierover: status van leveranciers · beoordelingen van overheden.

Hoe los ik PHP2Shell op?

1. Werk bij naar PHP **8.5.12**, **8.4.27**, **8.3.36** of **8.2.35** (of nieuwer in dezelfde tak). Broncode en Windows-builds: php.net downloads.
2. Herstart elke worker die verzoeken afhandelt (Apache met mod_php, PHP-FPM-pools, php-cgi, FrankenPHP, LiteSpeed, containers).
3. PHP 8.1 en ouder: haal een backport bij uw leverancier, bouw eigen builds opnieuw vanuit de minimale broncode-backports van het project voor 7.4/8.0/8.1, of haal de dienst offline tot de upgrade – in lijn met het CISA-advies voor systemen die niet kunnen worden bijgewerkt.
4. WAF-regels en de tijdelijke php.ini-maatregelen uit het PHP-advies verkleinen alleen bepaalde paden. Ze zijn geen volledige oplossing.

Stap voor stap voor apt, yum, Docker, cPanel, Plesk en meer: herstel.

Hoeveel servers zijn blootgesteld aan PHP2Shell?

Openbare schattingen zijn groot en geen telling van daadwerkelijk gehackte websites. The Record (op basis van een VirusTotal-analyse) en een bericht van ThreatCluster noemen beide circa **5,1 miljoen** als PHP herkende internetadressen (volgens ThreatCluster tonen er maar zo’n 1,1 miljoen een versieheader). Een eerder aangehaald onderzoek plaatste schattingen in Censys-stijl op meer dan **1,3 miljoen** getroffen hosts. De recente PHP-waarnemingen van Bitsight concentreren zich op de VS, Duitsland, Frankrijk, Nederland en Japan – geen bewijs dat een land „verouderder” is.

Wij verzinnen **geen** totaalbedrag voor wereldwijde schade. Zolang verzekeraars, overheden of openbaarmakingen geen toerekenbare kosten publiceren, zou elk getal speculatie zijn.

Waarom is PHP2Shell lastiger in te dammen in het AI-tijdperk?

• Berichten over PHP2Shell (waaronder Wiz en het artikel van The Record over de PHP Foundation) beschrijven hoe AI-ondersteunde reviews hielpen kritieke fouten te vinden in een runtime van tientallen jaren oud. Aanvallers hebben dezelfde hefboom: zodra er een PoC bestaat, schalen scans en bewapening sneller dan handmatige patchcycli op vergeten hosts.
• Niet-ondersteunde PHP (5.x tot 8.1 zonder backport) is nog wijdverbreid op shared hosting, appliances en „eenmalig opgezette” CMS-sites. Vaak weet niemand meer hoe je ze bijwerkt – een RCE op taalniveau wordt zo een internetbreed opruimprobleem in plaats van een bugfix in een app.
• De praktische les voor beheerders: inventariseer elke plek waar PHP is ingebed, patch op de dag van het advies en faseer takken uit die het PHP-project niet meer levert. De les voor de sector: AI verkort de tijd van ontdekking tot misbruik; de patchvertraging op oude systemen is het eigenlijke aanvalsoppervlak.