PHP2Shell staat weer nadrukkelijk op de radar. Waar onderzoekers eerder vooral crashes en verkenningsgedrag zagen, zijn er nu aanwijzingen dat aanvallen zijn doorgegaan tot PHP2Shell werkende shells op honeypot-systemen. Dat betekent concreet: niet alleen foutjes veroorzaken, maar ook daadwerkelijk commando’s kunnen uitvoeren via misbruik van twee kritieke kwetsbaarheden.
De bevindingen sluiten aan op de kwetsbaarheidsnummers CVE-2026-109618 en CVE-2026-109619. Beide problemen kunnen worden misbruikt voor unauthenticated remote code execution—zonder dat een aanvaller eerst hoeft in te loggen. Daarmee is het risico voor organisaties met kwetsbare PHP-configuraties bijzonder hoog.
Van verkenningen naar echte command execution
Een onderzoeker zette honeypots in die normale PHP-gebaseerde pagina’s tonen. Deze opzet bestond uit PHP 8.4.26 onder Apache met mod_php, met een single-worker configuratie. In het eerste meetvenster zag de onderzoeker wel problemen: geheugenuitputting en worker-crashes, maar nog geen bevestigde code-uitvoering.
Dat veranderde op een later moment. Tijdens een daaropvolgende periode registreerden de sensoren meerdere shellstarts verspreid over meerdere honeypots. Daarbij vielen opvallende uitschieters op: één bron leverde meerdere shells binnen één honeypot, terwijl een andere bron zelfs tientallen shells over alle systemen tegelijk kon opstarten.
Wat de aanvallen precies deden (vierstaps keten)
De aanvallen verliepen via een duidelijke keten van vier HTTP-verzoeken. Niet elk verzoek had hetzelfde effect. Volgens de waarnemingen werden eerst stappen uitgevoerd die:
- de beschikbare PHP-geheugenresources konden uitputten,
- vervolgens geheugeninhoud konden lekken,
- en in de laatste stap een shellcommando daadwerkelijk konden uitvoeren.
Cruciaal is dat de interactie sterk leek op een publiek beschikbare proof-of-concept (PoC). Daarnaast paste het patroon bij exploitatie van met name CVE-2026-109618. Dit is precies het soort ontwikkeling dat je liever niet ziet: aanvallers blijken niet alleen te testen, maar de keten te kunnen afmaken tot een resultaat dat bruikbaar is.
ASLR-bypass speelde waarschijnlijk mee
Behalve het uitvoeren van de keten, is er nog een technische onderstroom. Eerder hadden onderzoekers al exploitvarianten ontwikkeld die ASLR-bescherming konden omzeilen. In de huidige waarnemingen wordt dat indirect bevestigd door het feit dat de laatste stap tot shelluitvoering leidde.
Belangrijk detail: de bevindingen zijn gedaan in een specifieke honeypot-omgeving met een gunstige configuratie (single worker, mod_php, een specifieke PHP-versie). Dat betekent niet dat exploitbetrouwbaarheid automatisch gelijk is in elke andere productie-instelling, maar het toont wel aan dat PHP2Shell werkende shells realistisch zijn.
Geen tweede-stage payload gezien
Bij de geregistreerde activiteit zagen de onderzoekers geen vervolg van het type tweede-stage payload. Met andere woorden: in deze waarneming draaide de keten niet zichtbaar door naar extra download- of installatiehandelingen.
Dat neemt niet weg dat een webshell of vergelijkbare command execution al schadelijk is. Zelfs zonder verdere payloads kan een aanvaller daarna data verzamelen, laterale beweging proberen of bestaande backdoors inzetten—afhankelijk van wat er al op het systeem aanwezig is.
Waarom deze bevestiging zwaarder weegt dan “alleen crashes”
In eerste instantie werd in de markt vooral gerapporteerd dat er veel exploitpogingen plaatsvonden met crashgedrag. Crashen is echter niet hetzelfde als gecontroleerde code-uitvoering. De nieuwe observatie verschuift het beeld: het gaat nu om een scenario waarin de keten daadwerkelijk tot bruikbare output leidt.
Een andere securityonderzoeker typeerde dit als een van de best onderbouwde bevestigingen tot nu toe. Tegelijkertijd wees dezelfde onderzoeker er ook op dat je niet te ver moet doordenken op basis van één specifiek meetprofiel.
Wat CISA al had gemeld (en wat nog niet)
Rond de updates voor PHP2Shell hebben overheidsinstanties ook communicatie gedeeld over detecties en waargenomen exploitatie. Een eerdere alertupdate bevatte bijvoorbeeld een Sigma-detectieregel. Tegelijk werd aangegeven dat er op dat moment nog geen succesvolle exploitatie was gezien.
Voor organisaties betekent dit vooral dat je niet moet wachten op een “officiële” bevestiging dat het bij jou ook echt is gebeurd. Als er werkende uitkomsten in het wild opduiken, is de kans groot dat kwetsbare omgevingen snel aan de beurt komen.
Welke acties moet je nu nemen?
De praktische kern is eenvoudig: patch en verklein het aanvalsoppervlak. Hieronder een aanpak die past bij PHP2Shell-achtige risico’s.
1) Werk PHP en je stack direct bij
PHP heeft de issues gepatcht. Check daarom of je PHP-versie—en eventuele onderliggende pakketten—daadwerkelijk up-to-date zijn. Vergeet ook niet dat PHP in combinatie met Apache en mod_php specifieke routes kan blootleggen.
2) Valideer of je kwetsbare configuraties nog actief zijn
Als je werkprocessen anders dan in de honeypot draaien (andere worker-aantallen, andere builds, andere routing naar PHP), kan de exploitimpact verschillen. Maar dat is geen reden om achterover te leunen: het doel blijft hetzelfde, namelijk remote code execution voorkomen.
3) Zet gerichte detectie en logging aan
Let op patronen rond ongebruikelijke HTTP-sequenties naar PHP-afhandeling. Ook al zag men in dit geval geen tweede-stage payload, de eerste keten is al een signaal. Zorg dat je WAF/IDS en serverlogs voldoende detail hebben om verdachte reeksen te relateren aan specifieke endpoints.
4) Test in een gecontroleerde omgeving
Als je een patch- of hardeningstrategie hebt, test die dan eerst op staging. Zo voorkom je dat “veiligheidswerk” nieuwe storingen introduceert.
Vergelijkbare PHP-aanvallen: waarom het relevant blijft
PHP-kwetsbaarheden leveren vaker serieuze productierisico’s op omdat ze direct gekoppeld zijn aan server-side logica. Als je geïnteresseerd bent in de bredere trend van exploitchains en hoe aanvallen zich ontwikkelen van probe naar uitvoering, dan is het nuttig om ook recente PHP-incidenten in context te bekijken.
Op deze site bespreken we bijvoorbeeld exploitachtige patronen en detectiepunten rond PHP2Shell: Mirai misbruikpogingen en ASLR-truc. Dat helpt om te begrijpen waarom omzeilen van omgevingsbescherming (zoals ASLR) zo vaak het verschil maakt tussen “crash” en “shell”.
Conclusie: neem PHP2Shell werkende shells serieus
De signalen rond PHP2Shell schuiven van “probeergedrag” naar “werkende shells”. Onderzoek in honeypots laat zien dat een aanvallende partij met een geteste vierstaps HTTP-keten niet alleen fouten veroorzaakt, maar ook daadwerkelijk commando-uitvoering kan bereiken.
De boodschap voor beheerders blijft hetzelfde: patch zo snel mogelijk, controleer je PHP/Apaсhe-mod_php inrichting, en zet detectie op verdachte exploitketens. Wacht niet op extra bevestiging wanneer er al bewijs is dat de keten tot een bruikbaar resultaat kan leiden.
Bron: https://www.securityweek.com/php2shell-exploitation-moves-from-probes-to-working-shells/
