PHP2Shell lijkt zich te ontwikkelen richting een grootschalig PHP-incident. Niet alleen omdat er twee kritieke remote code execution (RCE)-lekken spelen, maar vooral omdat beveiligingsbedrijven al dagen vóór de patches misbruikpogingen en vroege exploitdata zagen. Amazon en andere partijen rapporteren bovendien dat na het vrijgeven van de fixes de activiteit razendsnel toenam.
In dit artikel zetten we de belangrijkste feiten op een rij en vertalen we ze naar praktische acties voor teams die hun PHP-omgevingen moeten beveiligen. Ook leggen we uit waarom “patchen” niet genoeg is als je niet weet waar je allemaal kwetsbare installaties draait.
Wat is PHP2Shell precies?
PHP2Shell verwijst naar twee kwetsbaarheden in PHP die worden gebruikt voor remote code execution. Ze zijn geregistreerd als CVE-2026-109618 en CVE-2026-109619. De patches werden uiteindelijk vrijgegeven op 21 oktober, na afstemming binnen de PHP-gemeenschap en betrokken industriepartners.
Volgens meerdere waarnemers werd ondertussen gezocht naar servers die door de kwetsbaarheden geraakt waren. Dat gebeurde al vóórdat de fixes breed beschikbaar waren.
PHP2Shell dagen vóór patches: vroege signalen
Amazon meldt dat threat actors het doelwit al begonnen te verkennen vier dagen voordat de officiële fixes uitkwamen. De eerste exploitatie die Amazon observeerde, dateert van 17 oktober, dus terwijl de kwetsbaarheden nog onder embargo stonden.
Die vroege pogingen kwamen van een commercieel anonimiseringsnetwerk. In dat patroon zag Amazon aanwijzingen dat het om echte acteur-activiteit ging, al blijft onduidelijk hoe de informatie over exploits in handen is gekomen.
Ook noteert Amazon dat ongeveer twaalf uur vóór de publieke bekendmaking meerdere varianten van proof-of-concept (PoC) exploits opdoken vanuit extra geanonimiseerde infrastructuur. De variatie in payloads en herkomst suggereert dat niet één actor aan het werk was.
Van lek naar PoC: wat er gebeurde na het vrijgeven
Op 20 oktober werden de issues online gelekt. Daardoor verspreidden PoC’s zich sneller. Meerdere organisaties signaleerden activiteit, maar meldden dat de eerste exploitatiepogingen niet tot RCE leidden.
Zodra het embargo eindigde en de patch beschikbaar kwam, veranderde het tempo. Amazon geeft aan dat binnen uren extra PoC’s verschenen en dat die bijna meteen op sensoren werden gebruikt. Volgens Amazon is PHP2Shell inmiddels breed misbruik in het wild.
WatchTowr rapporteerde daarnaast massale exploitatiepogingen vlak na de release. Tegelijkertijd stelden zij dat de PoC’s die circuleerden lang niet altijd werken voor RCE: vaak testen ze op tijdsverschillen, falen ze, of veroorzaken ze crashes bij het doel.
Honderdduizenden pogingen: hoe snel het escaleerde
Cloudflare beschreef een bijna meetbaar “ramp-up” patroon. In de periode rond de aankondiging werden via het Cloudflare-netwerk duizenden pogingen gezien, met een duidelijke sprong na de publicatie:
- in de 10 uur vóór de aankondiging: duizenden pogingen
- na bekendmaking: tientallen duizenden
- na 2 uur: honderdduizenden
- vervolgens: miljoenen
Ook andere partijen, waaronder Hadrian, Patchstack en Cloudflare, zagen al uren vóór de fixes werden vrijgegeven exploitatiepogingen.
Niet alle PoC’s zijn “echt”, maar dat zegt niets over jouw risico
Een veelvoorkomend misverstand is dat “PoC’s die falen” automatisch betekent dat de echte exploit-sets ook niet werken. De observaties rond PHP2Shell laten juist zien dat de praktijk rommelig kan zijn: verschillende varianten, wisselende payloads en geanonimiseerde infrastructuur zorgen ervoor dat pogingen soms niet slagen, soms wel.
Daarnaast rapporteert JFrog het verschijnen van fake PoC’s en zelfs prank malware op GitHub. Dat versterkt de chaos, maar neemt het kernrisico niet weg: als jouw server kwetsbaar is en de juiste omstandigheden aanwezig zijn, kan een succesvolle poging alsnog leiden tot compromise.
Hoe groot is de blootstelling aan on-gepatchte PHP?
De schaal lijkt zorgelijk. VulnCheck, VirusTotal en Censys meldden dat op 21 oktober meer dan 1 miljoen PHP-servers draaiden op niet-gepatchte versies.
Censys rapporteert dat van de internet-facing hosts die identificeerbaar PHP rapporteerden, een groot deel niet gepatcht was. VulnCheck gaat nog verder met het aantal internet-facing PHP-hosts. Daarbij valt op dat een deel van de wereldwijde PHP-voorraad draait op end-of-life (EoL) versies, waaronder oudere PHP 3.x t/m 7.3, en daarnaast relatief recente EoL-varianten zoals 7.4 en 8.0/8.1.
De positieve noot: een substantieel deel van de geïnventariseerde omgevingen zit bij bekende cloudproviders. Dat maakt remediatie in de praktijk vaak haalbaar met gerichte configuratie-updates en passende WAF-regels.
Waarom patchen niet genoeg is: vind waar PHP draait
CISA riep organisaties op om direct bij te werken naar specifieke PHP-fixversies: 8.5.12, 8.4.27, 8.3.36 of 8.2.35, waarin de fixes voor beide PHP2Shell-issues zijn verwerkt.
Maar de hamvraag is: hoe vind je alles dat moet patchen? Experts waarschuwen dat gebeurtenissen zoals deze juist blootleggen wat organisaties niet (meer) goed in kaart hebben: vergeten applicaties, shadow systemen en PHP-installaties die buiten beeld zijn geraakt.
Met name als exploitatie kan plaatsvinden vóór sommige beveiligingschecks, wil je niet alleen de patch doorvoeren, maar ook actief onderzoeken of er sporen zijn van misbruik.
Praktische aanpak: wat je nu kunt doen
Bekijk het als drie parallelle sporen: patchen, jagen op zichtbaarheid en beperken van impact.
1) Patch direct naar de genoemde fixversies
Werk PHP bij naar de door CISA genoemde versies (8.5.12 / 8.4.27 / 8.3.36 / 8.2.35). Zorg dat je wijzigingen beheerst uitrolt, maar stel niet uit.
2) Zoek actief naar kwetsbare PHP-installaties
Inventariseer niet alleen servers, maar ook omgevingen waar PHP “ergens draait”: webhosts, containers, legacy applicaties en randcomponenten. Als je niet weet waar het draait, patch je uiteindelijk de verkeerde dingen—of te weinig.
Heb je al een aanpak voor kwetsbaarheidsdetectie en prioritering? Gebruik die om dit incident te versnellen. Zie bijvoorbeeld ook de aanpak achter PHP2Shell: wat echt helpt vóór de patch.
3) Zet extra beschermingslagen in als backstop
Zolang niet alles gepatcht is, kunnen beperkingen op web-facing processen helpen. Denk aan het beperken van wat een PHP-proces mag lanceren, openen of verbinden met andere diensten. Belangrijk: dit is een backstop, geen vervanging van patchen.
Daarnaast kan het nuttig zijn om je monitoring en detectie te richten op afwijkend gedrag rond webrequests, vermoedelijke PoC-patronen en signalen die passen bij het plaatsen of uitvoeren van webshells.
Vergelijking met eerdere grote incidenten
Beveiligingsspecialisten noemen PHP2Shell in dezelfde sfeer als eerdere massale gebeurtenissen. De vergelijking met Log4Shell zit vooral in het effect: breed bereik en veel “vergeten” infrastructuur die pas opduikt tijdens incidentresponse. Het verschil zit in de oorzaak: bij Log4j lag de uitdaging vaak in een onbewuste aanwezigheid van een bibliotheek; bij PHP2Shell komt het meer neer op het vinden van installaties die in omgevingen zijn blijven hangen.
De les waarover experts spreken is bruikbaar voor elk team: meet niet alleen patch-snelheid, maar ook de vaardigheid om te herkennen waar je een bepaald onderdeel gebruikt.
Wat betekenen deze signalen voor jouw planning?
Als je wacht op “bewijs” dat het bij jou ook misbruikt is, ben je te laat. De berichten tonen dat exploratie en PoC-verspreiding al vroeg plaatsvonden en dat het misbruik na patchrelease snel opschaalde. Zelfs als PoC’s niet altijd slagen, kan jouw omgeving wél kwetsbaar zijn op de juiste momenten en configuraties.
Concreet: patch vandaag, inventariseer morgen door en begin meteen met gerichte checks op tekenen van compromise. Wie dat niet doet, loopt het risico dat een aanvaller via een webshell of vergelijkbaar spoor je systeem als opstap gebruikt.
Wil je meer context rond soortgelijke patch-urgentie en wat je vooraf al kunt organiseren? Lees dan ook hoe je omgaat met multi-product patchrondes en koppel die werkwijze aan je PHP-inventaris.
Bron: https://www.securityweek.com/php2shell-exploitation-started-days-before-patches/
