Na de publicatie van de PHP2Shell-kwetsbaarheden reageren leveranciers en securitybedrijven met advisories, detecties en noodmaatregelen. De reden: om afstand kwetsbare systemen te treffen, is geen authenticatie nodig. Daardoor is PHP2Shell patchen geen “later”-klus, maar een actie die je zo snel mogelijk wilt uitvoeren.
De twee kritieke bugs heten CVE-2026-109618 en CVE-2026-109619. Wiz, OpenAI en Calif brachten ze eerder in augustus in kaart. PHP zelf verwerkte de fixes op 21 oktober in versies 8.5.12, 8.4.27, 8.3.36 en 8.2.35.
In dit artikel zie je hoe het ecosysteem reageert: wat er al is gedetecteerd, welke controlemomenten organisaties moeten meepakken en welke praktische mitigaties en signalen je kunt gebruiken.
Wat maakt PHP2Shell zo lastig?
De kern is eenvoudig maar impactvol: de fouten kunnen op afstand code-uitvoering mogelijk maken via ongeauthenticeerde requests. Daardoor kun je te maken krijgen met snelle compromissen wanneer een omgeving kwetsbaar is.
Daarnaast is PHP vaak geen “standalone” onderdeel. Het zit ingebouwd in uiteenlopende software, appliances en cloudservices. Het gevolg: je kunt een kwetsbaar systeem raken, ook als je zelf niet bewust een “oudere PHP-versie” draait.
Daarom ligt de focus bij veel partijen niet alleen op patching, maar ook op inventariseren en het afdekken van routes naar kwetsbare PHP-runtimes.
Wanneer kwam de exploitatie op gang?
PHP publiceerde de release een dag eerder dan gepland. Volgens de berichtgeving begonnen exploitatiepogingen al op 17 oktober, voordat het embargo op het moment van bekendmaking werd opgeheven.
Meerdere partijen meldd(en) detecties in de uren voorafgaand aan de patches. Hadrian, Patchstack en Cloudflare zagen aanvalspogingen tijdens die periode. WatchTowr constateerde ook massale exploitatie direct na publicatie van de fixes, al leidden de in omloop zijnde PoC’s niet altijd tot succesvolle code-uitvoering.
Voor IT-teams betekent dit: zelfs als je PoC’s hebt gezien maar geen directe succesvolle aanvallen ziet, kan de druk op systemen toch al gestart zijn.
PHP2Shell patchen: wat deden bekende leveranciers?
Omdat PHP in brede tooling en platformen zit, liepen reacties uiteen: van directe PHP-updates tot het controleren van producten waarin PHP verwerkt kan zijn.
Cisco: tientallen producten in review
Cisco publiceerde een advisory waarin het meer dan 30 producten en cloudservices noemt die mogelijk onder de controle vallen. Daarbij staan onder meer Identity Services Engine, Catalyst Center, Catalyst SD-WAN Manager, Expressway, Umbrella, Webex en de AppDynamics PHP Agent.
Cisco stelt dat er momenteel geen producten bekend zijn die daadwerkelijk zijn getroffen. Tegelijkertijd deelde Cisco Talos Snort-coverage en wees het op detectieregels uit het Community Ruleset.
Op basis van open data schat Talos dat ongeveer de helft van de PHP-systemen geen patch zou krijgen. In dat licht adviseert het om zeker op PHP 8.1 of eerder direct naar een nieuwere versie te gaan.
Red Hat: ernst in context, maar wel actie
Red Hat beoordeelde de impact anders dan de hoogste kwetsbaarheidsscores in NVD. De score voor beide bugs komt uit op 8.1, waar NVD uitgaat van 9.8. Red Hat labelt beide issues niet als “critical” binnen zijn inschatting.
Het bedrijf benadrukt dat voor betrouwbare uitbuiting precieze heap-manipulatie en timing nodig zijn, en dat remote code execution in de praktijk moeilijk kan zijn en vaak niet-standaard gedrag vereist.
Belangrijk is dat dit geen reden is om af te wachten: het gaat om “moeilijker”, niet om “onmogelijk”. Bovendien draait het om je eigen risicoprofiel en blootstelling.
Cloud en hosting: updates in diverse diensten
Ook cloud- en platformaanbieders namen maatregelen. AWS werkt onder meer aan fixes in Elastic Beanstalk, WorkMail, Amazon Linux en Amazon Lightsail. Google Cloud stelt dat het zelf niet kwetsbaar is, maar dat ondersteunde PHP-runtimes voor App Engine standard environment automatisch zijn bijgewerkt, met nieuwe base images voor serverless PHP-services.
Voor hosting control panels meldd(en) leveranciers patches. cPanel en Plesk brachten ook fixed builds uit voor end-of-life PHP 7.4, 8.0 en 8.1 branches. DirectAdmin publiceerde eveneens updates.
Securityfirma’s: detecties, mitigaties en SIEM-content
Naast patching zetten securitybedrijven vooral in op het sneller herkennen van pogingen en het beperken van impact.
Detecties en regels voor waarneming
Corelight maakte vroegtijdig Zeek– en Suricata-detecties beschikbaar en stelde ze open source beschikbaar. Zo kun je sneller signalen verzamelen zonder vanaf nul te beginnen.
JFrog waarschuwde daarnaast dat er rond de bekendmaking fake PoC’s in omloop waren. Dat is relevant voor teams die hun eigen testen doen: niet elke PoC is betrouwbaar, en sommige kunnen je in de verkeerde richting sturen.
Gedragsgerichte mitigaties
Een opvallende mitigatie kwam van Qualys: die schakelt op getroffen hosts de PHP session upload-progress-functionaliteit uit. Dit past in een bredere aanpak: niet alleen patchen, maar ook functies beperken die exploitpaden kunnen faciliteren.
Daarnaast deden meerdere aanbieders analyse en remediation guidance. Datadog, Endor Labs, Huntress, Patchstack, Recorded Future, Sansec en Tenable publiceerden technische analyses en adviezen.
SIEM- en productcontent
Palo Alto Networks gaf aan dat toekomstige PAN-OS releases de issue aanpakken. Voor de tussentijd deelde het workarounds en mitigaties, met een hoge impactinschatting (CVSS 8.7) en zonder kennis van aanvallen tegen hun eigen producten.
CrowdStrike testte en concludeerde dat één ongeauthenticeerde POST-request genoeg kan zijn om een Apache mod_php worker in een shell te laten starten en een commando uit te voeren dat de aanvaller kiest—zonder dat er kwetsbare applicatiecode nodig is. Het bedrijf voegde detectiecontent toe aan Falcon Next-Gen SIEM.
Qualys en andere partijen benoemden ook specifieke afscherming of detecties. Het algemene patroon: zorg dat je monitoring kan zien wat je patcht.
Overheidswaarschuwingen: zoek ook naar “verborgen” PHP
Overheden en CERT’s benadrukken dat je niet alleen moet kijken naar direct zichtbare applicaties. CISA riep organisaties op om meteen te patchen, te starten met internet-facing systemen, en waarschuwt dat PHP vaak in andere software verstopt zit.
De Britse NCSC adviseert om elke PHP-installatie te ontdekken, dus niet alleen verouderde versies. Ook moeten teams letten op updates van leveranciers van appliances en services die PHP in de keten kunnen meeleveren.
Verder adviseert het om actief te jagen op mogelijke backdoors die aanvallers mogelijk hebben achtergelaten vóórdat mitigaties werden toegepast.
Wat betekent dit voor jouw organisatie?
Je doel is tweeledig: verminderen van blootstelling en verifiëren dat de fix echt werkt.
1) Inventariseer alle PHP-runtimes
Maak een lijst van waar PHP draait: webservers, applicaties, hostingomgevingen, CI/CD-omgevingen, appliances en cloudservices. Let daarbij op dat PHP ook onderdeel kan zijn van “achter de schermen” componenten.
2) Patch nu: PHP-versies uitrollen of runtimes vervangen
PHP heeft updates klaarstaan in de eerder genoemde versies (8.5.12, 8.4.27, 8.3.36 en 8.2.35). Neem bovendien end-of-life varianten mee als je omgeving daarvoor kwetsbaar kan zijn, gezien de signalen uit de hostingsector.
3) Detectie en hunting parallel aan patching
Werk detecties uit of integreer ze in je SIEM. De uitwisseling van Zeek/Suricata-detecties en SIEM-content kan helpen om te bepalen of er al activiteit is geweest.
Als je meer wilt lezen over het belang van vroege voorbereiding en concrete maatregelen vóór je patchrondes, is dit gerelateerde onderwerp interessant: PHP2Shell: wat echt helpt vóór de patch.
4) Controleer ook downstream-producten
Omdat leveranciers meerdere producten “in review” hebben, moet je nagaan welke pakketten, agents of cloud services PHP-runtimes (of gerelateerde functionaliteit) bevatten. Cisco’s advisory laat bijvoorbeeld zien hoe breed de check kan zijn, zelfs wanneer er “geen bekende impact” wordt gerapporteerd.
Snelle checklist voor actie vandaag
- Inventariseer alle PHP-instances, inclusief ingekapselde of ingebedde PHP.
- Rol PHP2Shell patchen uit met de gepubliceerde PHP-fixes.
- Activeer detectie(s) en voer hunting uit op basis van de beschikbare regels/content.
- Toepassen van compensating controls waar patchen niet direct haalbaar is (bijvoorbeeld functionaliteitsbeperking).
- Verifieer na uitrol: versie klopt, routes zijn afgedekt en logs tonen geen verdachte activiteit.
Zie het als één keten: patchen zonder monitoring is risico blijven opbouwen; monitoring zonder patchen blijft kwetsbaarheid blootgeven.
Conclusie
De respons op PHP2Shell laat één duidelijke les zien: zodra kritieke RCE-kwetsbaarheden met ongeauthenticeerde toegang in omloop komen, draait het om snelheid én volledigheid. Veel partijen—van Cisco en Red Hat tot cloudproviders en securityfirma’s—zetten in op advisories, detecties en mitigaties, terwijl overheden expliciet waarschuwen voor “verborgen” PHP in onderliggende software.
Daarom is PHP2Shell patchen nu het logische startpunt: patch zo snel mogelijk, vul je inventarisatie aan en verifieer met detectie of er al activiteit is geweest. Wil je je planning aanscherpen voor volgende incidenten, dan is PHP-kwetsbaarheden: bereid je voor op patchen een goede vervolgstap.
Bron: https://www.securityweek.com/tech-and-security-companies-respond-to-php2shell-vulnerabilities/
