Er is opnieuw reden om heel snel te patchen: het PHP2Shell misbruik begon al vóórdat de kwetsbaarheden publiek volledig werden aangekondigd. Amazon’s Threat Intelligence rapporteerde dat men exploit-pogingen detecteerde tegen de MadPot honeypot, precies in een periode waarin informatie nog onder embargo zou vallen.
Dat is zorgelijk, omdat de onderliggende problemen in PHP runtime kunnen worden misbruikt voor pre-authentication remote code execution—zonder inlog, zonder session-overname en zonder dat een specifieke CMS of plugin nodig is.
Wat Amazon aantrof: exploitpogingen vóór publicatie
Amazon stelt dat de eerste pogingen in oktober 2026 al opduiken rond het moment dat kwetsbaarheidsdetails nog niet breed gedeeld waren. Daarbij ging het om aanvallen die gericht waren op een honeypot, een omgeving die bewust wordt ingezet om verdachte activiteit te vangen.
Volgens Amazon kwam het verzoekverkeer vanaf een IP-adres dat gelinkt is aan een commerciële anonimiseringdienst. De activiteit werd onder meer geregistreerd vanaf 103.216.220 (geolocatie: Australië). Ook werden later in dezelfde periode meerdere andere IP-adressen waargenomen.
- 31.223.184
- 37.19.200
- 134.209.159
- 103.114.163
- 95.217.98
De kernvraag blijft: hoe kwamen aanvallers aan voldoende informatie om al vroeg te testen en payloads te bouwen?
Waarom dit zo gevaarlijk is: pre-auth RCE in PHP
De gemelde issues betreffen twee kwetsbaarheden in PHP core, met CVSS-scores van 9,2. Ze zijn gelabeld als CVE-2026-109618 en CVE-2026-109619. Beide kunnen worden misbruikt om remote code execution te bereiken zonder authenticatie.
De kwetsbaarheden zitten volgens de meldingen in delen van PHP die praktisch bij elk request worden geraakt. Dat betekent dat een server met een bereikbare PHP-endpoint—bijvoorbeeld statische formulieren, loginroutes en zelfs health checks—potentieel in de gevarenzone zit.
Belangrijk: de blootstelling hangt niet af van welk CMS, framework of welke plugin je gebruikt. Het probleem zit in de PHP runtime zelf.
Het probleem met detectie: weinig logsignalen
Wat het verdedigen extra lastig maakt, is dat de aanval volgens meerdere observaties nauwelijks “klassieke” sporen achterlaat. Werkprocessen blijven stabiel en responses blijven vaak “normaal” (zoals HTTP 200).
In logs kan lange tijd weinig of niets verschijnen, omdat volgens CrowdStrike geen applicatiecode daadwerkelijk draait. De enige server-side trace zou in sommige gevallen beperkt blijven tot een incidentele melding in de webserver error log—iets dat veel beheerders doorgaans als ruis beschouwen.
Daardoor is het voor teams moeilijk om op basis van reguliere logica direct vast te stellen welke endpoints al zijn gecompromitteerd.
Embargo doorbroken: release vervroegd en eerdere PoC’s
Oorspronkelijk stond gecoördineerde openbaarmaking gepland op 22 oktober 2026, maar details—inclusief de CVE-identifiers en een proof-of-concept—lekten eerder. De PHP Foundation besloot daarom de release een dag naar voren te halen.
Verder kwam er extra context naar voren over een verstoring van het embargo: de meldingen suggereren dat er partijen waren die al patches hadden voordat de brede release volgde, waardoor een deel van de community eerder kon analyseren. Dat versnelt de tijd van patch naar exploit, vooral als binair materiaal al beschikbaar is terwijl anderen nog wachten.
Waarom dit nu sneller gaat: “patch diff” naar werkende exploit
Een opvallende ontwikkeling in de meldingen is dat de tijd tussen patch en werkende exploit aantoonbaar afneemt. Amazon verwijst daarbij naar structurele redenen: analyse van verschillen tussen advisories en gepatchte code is voor aanvallers eenvoudiger geworden, mede door geautomatiseerde of AI-ondersteunde aanpak.
Waar eerdere exploitatie vaak pas echt op gang kwam na publicatie van een PoC, lijken er nu meer actoren sneller te kunnen handelen zodra technische details uitlegbaar zijn. Resultaat: aanvallen binnen uren of zelfs minuten in plaats van weken.
Wat organisaties nu moeten doen (praktisch en direct)
Omdat PHP2Shell misbruik aantoonbaar al vóór volledige publicatie plaatsvond, is de prioriteit helder: patch nu, en controleer daarna of je omgeving veilig is.
1) Identificeer waar PHP echt draait
Niet alleen “webservers” tellen mee. Veel omgevingen hebben PHP gebundeld in OS-distributies of draaien in legacy setup. Breng daarom in kaart welke PHP-versies op internet-facing hosts draaien en welke routes PHP daadwerkelijk raken.
In de meldingen worden grote aantallen internet-facing systemen genoemd, wat aangeeft dat de impact potentieel omvangrijk is.
2) Patchen vóór je detecties verfijnt
Omdat detectie signalen kan missen (stille compromis-kenmerken), kun je niet wachten op “eerst logsporen, dan fix”. Zorg dat de gepatchte PHP-runtime als eerste stap op productie beschikbaar is.
Werk daarna pas verder aan extra monitoring, isolatie en forensische controles.
3) Monitor op onverwachte command-shell gedrag
Beveiligingsinstanties en vendors adviseren vooral om webservers te monitoren op gedrag dat niet past: het onverwacht starten van command shells, het downloaden van bestanden of andere tekenen van code-executie.
Waar je al procesmonitoring hebt, is dat een sterkere basis om uit te zoeken of een endpoint doelwit is geweest.
4) Overweeg tijdelijke maatregelen bij blootgestelde omgevingen
In de meldingen wordt ook geadviseerd om—afhankelijk van je situatie—webservers tijdelijk offline te zetten of in elk geval risicovolle routes te beperken, zeker als patching niet direct mogelijk is.
Signalen uit het veld: blokkades, scans en muterende payloads
Naast honeypot-waarnemingen zijn er ook verschillende voorbeelden van defensieve teams die verdachte verkeer zien. Zo rapporteerde een webops-platform dat het tienduizenden verdachte requests blokkeerde die de kwetsbaarheid probeerden.
Daarnaast werd er gespot met user-agents die specifiek bedoeld lijken te zijn om te scannen of te weaponizen. Ook werd beschreven dat aanvalsvormen kunnen muteren om bescherming te omzeilen door volume en match-logica mee te meten.
Gerelateerd: hoe je sneller kunt reageren op exploit-achtige aanvallen
Als je organisatie vaker te maken krijgt met aanvallen die weinig “logruis” achterlaten, helpt een aanpak die exploit-gedrag centraal stelt. Lees ook: PHP2Shell: wat echt helpt vóór de patch.
Door alvast te werken met proces- en netwerkobservatie kun je na het patchen sneller bepalen waar onderzoek nodig is.
Conclusie: PHP2Shell misbruik vraagt om spoed en discipline
De boodschap is niet nieuw, maar wel urgent: het PHP2Shell misbruik werd al vroeg gezien, zelfs vóórdat alle details publiek beschikbaar waren. Dat onderstreept hoe belangrijk het is om je PHP runtime up-to-date te brengen en je monitoring te baseren op gedrag, niet alleen op logs.
Pak het daarom in volgorde aan: patch eerst, stel daarna controle en forensisch onderzoek scherp, en voorkom dat “eventuele” verdachte activiteit je primaire reactie vertraagt.
Bron: https://thehackernews.com/2026/10/someone-tried-to-exploit-php2shell-4.html
