Twee dagen nadat PHP noodreparaties uitrolde voor PHP2Shell, probeerden aanvallers de kwetsbaarheden in te zetten om een Mirai-achtig botnet te verspreiden. Het gaat om twee kritieke bugs in de PHP-engine die kunnen leiden tot ongeauthenticeerde remote code execution (RCE). Belangrijk: tot en met de laatste updates zijn er geen bevestigde compromissen in het wild gemeld.
Wel was er in meerdere landen een zichtbare terugval in online dienstverlening door organisaties die uit voorzorg systemen offline haalden terwijl zij patchden. Dat patroon, samen met nieuwe exploit- en toolinganalyses, maakt duidelijk dat organisaties snel moeten handelen.
Wat is PHP2Shell precies?
PHP2Shell is de naam voor twee kwetsbaarheden in PHP: CVE-2026-109618 en CVE-2026-109619. Beide issues hebben een CVSS v4.0-score van 9.2 en kunnen misbruikt worden voor ongeauthenticeerde RCE. Onderzoekers vonden de problemen in augustus, waarna PHP ze op 21 oktober repareerde.
De publicatie van de CVE-identifiers zorgde ervoor dat de patchroute eerder werd doorgetrokken: leveranciers rolden de fixes al uit op een moment dat eerder dan gepland lag.
Waarom duiken er nu PHP2Shell misbruikpogingen op?
Volgens meerdere partijen is er kort na de patchrelease een toename gezien van pogingen om systemen te benaderen die nog kwetsbaar waren of in een kwetsbare configuratie draaiden. Er waren ook aanwijzingen van aanvalsspreiding richting botnet-infrastructuur.
In analyses werd beschreven dat dreigingsactoren probeerden een afgeleide van een Mirai-achtige familie te installeren. In ten minste één onderzocht geval bleef de malwarepoging steken, waardoor de payload het doelwit niet bereikte.
Mirai-achtige campagne: Potassium
Sophos meldde dat aanvallers PHP2Shell gebruikten om Potassium te installeren. Sophos ziet Potassium als een variant/uitloper die qua gedrag aansluit bij Mirai. In het voorbeeld dat Sophos analyseerde, werd de actie gestopt, zodat de besmetting niet tot het einddoel kwam.
Volgens Sophos gaat het om een aangepaste build die extra functionaliteit biedt: de malware kan bijkomende componenten binnenhalen en vervolgens DDoS-aanvallen starten. Ook andere onderzoeken wijzen erop dat de actor tooling klaar had liggen, maar dat niet elk gericht doelwit aan de randvoorwaarden voldeed.
Geen bevestigde inbreuken, maar wel voortgaande scanning
Hoewel er pogingen tot misbruik zijn vastgesteld, is er (voor zover gemeld) nog geen sprake van succesvolle compromissen in het wild. Wordfence beschreef bijvoorbeeld dat aanvallen doorgaan zonder bekende bekende succesvolle inbraken.
Hunt.io kwam tot een vergelijkbaar beeld: exploitpogingen en het voorbereiden van gereedschappen werden waargenomen, maar zonder bevestiging van een daadwerkelijke succesvolle exploitatie. Sansec nuanceerde bovendien verwachtingen: massale uitbuiting binnen minuten na patchen kwam niet uit, mede omdat aanvallers specifieke kennis en voorwaarden nodig hebben.
De ASLR-bypass: hoe onderzoekers de drempel zagen
Een van de grootste hindernissen voor RCE is ASLR (Address Space Layout Randomization). ASLR maakt het voor aanvallers lastiger om te voorspellen waar code en data in het geheugen terechtkomen.
Onderzoekers van VulnCheck claimden een manier gevonden te hebben om die bescherming te omzeilen. Hun exploit voor CVE-2026-109618 leunt op een memory leak en richt zich op x86-64-systemen met ASLR ingeschakeld, terwijl ook rekening wordt gehouden met een productie-instelling waarin PHP error display uit staat.
VulnCheck gaf aan dat hun exploit RCE kan realiseren in meerdere PHP-versies onder productieconfiguraties. Tegelijk benadrukte het bedrijf dat er op GitHub wel veel PoC’s circuleren, maar dat slechts een klein deel ook echt als werkende exploit te gebruiken is.
Tooling gevonden op een aanvallersserver
SOCRadar ontdekte een server die onder controle stond van de aanvaller, waarop PHP2Shell-tooling publiek inzichtelijk was via browsen. Daarin zat niet alleen een exploitketen, maar ook scripts om de configuratievoorwaarden te controleren.
Volgens SOCRadar ging de chain specifiek over PHP 8.4.26 in combinatie met Apache mod_php. De operator testte dit in een lab en presenteerde het als een “one-click” exploit. Cruciaal detail: de vereiste configuratie bleek zeldzaam en leek meer op een testopstelling dan op “hardened” productie.
SOCRadar beschreef dat de operator sites fingerprintte in onder andere de VS, het VK, Canada, Frankrijk, Finland, Polen en China. Maar geen van de onderzochte doelen voldeed aan de voorwaarden die nodig waren voor succesvolle exploitatie.
Waarom patchen nu zo belangrijk is
Zelfs als een exploit in analyses faalt zonder specifieke voorwaarden, blijft het risico dat kwetsbare systemen alsnog geraakt worden. Het tempo waarmee organisaties patchen bepaalt daarom hoe lang aanvallers kansen hebben.
Qualys onderzocht geanonimiseerde data van duizenden klanten en rapporteerde dat binnen 12 uur na bekendmaking slechts een beperkt deel van de PHP-instanties was gepatcht. Tegelijk gaf Qualys aan dat een groot deel van de PHP-installaties ouder is en mogelijk nooit meer vendorreparaties zal ontvangen. Ook waren er installaties op versies die wel binnen support vallen, maar waar fixes nog niet waren toegepast.
Daarnaast liep het toevoegen aan centrale dreigingscatalogi (zoals KEV) op dat moment nog achter. Dat betekent: het ontbreken van een KEV-vermelding is geen geruststelling om te wachten.
Hoe je nu actie onderneemt
Pak de kwetsbaarheid praktisch aan, ongeacht of je al gerichte aanvallen verwacht. Concreet:
- Patch PHP naar de versies waarin de fixes zitten: genoemd werden 8.5.12, 8.4.27, 8.3.36 en 8.2.35.
- Controleer internet-facing services die PHP gebruiken (met name webservers met mod_php of vergelijkbare setup).
- Verifieer configuraties die vaak in productie voorkomen, omdat misbruik in analyses juist ook met “productieachtige” instellingen besproken werd.
- Monitor op scanning- en exploitpatronen en stem je detectieregels bij zodra advisories uitkomen.
Als je wilt vergelijken hoe andere PHP-issues afgelopen tijd werden aangepakt, kan je ook lezen hoe organisaties reageerden op eerdere PHP2Shell-achtige scenario’s. Zie bijvoorbeeld PHP2Shell: bedrijven reageren en patchen nu.
Vooruitblik: waarom succesvolle uitbuiting nog kan volgen
De huidige signalen wijzen erop dat aanvallers mogelijk moeite hebben om direct overal binnen te dringen. Dat beeld bestaat zowel uit het ontbreken van bevestigde compromissen als uit de bevinding dat publieke PoC’s vaak niet gelijk zijn aan echte, betrouwbare exploits.
Tegelijk kan de situatie omslaan zodra actoren exploitchains verfijnen of meer geschikte doellijsten verzamelen. Onderzoekers verwachten dat dreigingsgroepen iteratief verbeteren, juist omdat RCE bij productiesystemen een aantrekkelijk doelwit blijft.
Daarom is het verstandig om patchen niet te koppelen aan nieuws over “bewezen” aanvallen, maar aan je eigen kwetsbaarheid: zolang er PHP-instanties draaien die nog niet gerepareerd zijn, blijft het risico reëel.
Conclusie
PHP2Shell misbruikpogingen laten zien dat aanvallers na de noodpatches snel proberen te profiteren van resterende zwakheden. Vooralsnog is er geen bevestigde succesvolle inbreuk gemeld, maar er is wél sprake van scanning, toolingontwikkeling en pogingen om Mirai-achtige malware zoals Potassium te installeren.
De beste bescherming blijft een snelle upgrade naar de door PHP vrijgegeven versies en een gerichte controle van internet-facing omgevingen. Wacht niet op “bevestiging in het wild”; pak je eigen risicoprofiel meteen aan.
