PHP waarschuwt voor twee kritieke RCE-kwetsbaarheden die remote code execution mogelijk maken. In de berichtgeving worden ze inmiddels PHP2Shell RCE genoemd. De situatie is extra urgent omdat er vooraf informatie gelekt is en omdat er aanwijzingen zijn dat er nog geen volledige details en werkbare mitigaties openbaar waren op het moment van de aankondiging.
Onderzoekers geven aan dat de kwetsbaarheden een CVSS-score van 9.2 krijgen op schaal v4.0 van PHP. Tegelijkertijd circuleren eerder in het nieuws hogere scores en een mogelijke impact die nog niet door een officiële vendor advisory was bevestigd. Wat wél duidelijk is: je moet je voorbereiden alsof je systemen direct kunnen worden geraakt.
Waarom PHP2Shell RCE nu direct aandacht vraagt
In het bericht draait het om twee PHP-lekken die volgens onderzoekers remote code execution mogelijk maken. Dat betekent in de praktijk dat een aanvaller via een kwetsbare webomgeving code kan laten uitvoeren op de server. Daarmee groeit het risico op onder meer webshell-infecties, datadiefstal en verdere compromittering.
PHP heeft aangekondigd dat er een out-of-cycle security release komt, met publicatie op dezelfde dag als de aankondiging. De planning is gekoppeld aan mogelijke publicatie van details of het verschijnen van bewijs van actieve exploitatie in het wild.
Voor welke PHP-versies komt de fix?
PHP stelt dat alleen de vier ondersteunde PHP-branches kunnen worden voorzien van de update, namelijk 8.2 t/m 8.5. Binnen die ondersteunde takken geldt dat 8.2 en 8.3 uitsluitend security fixes krijgen en dat 8.4 en 8.5 nog actief in ondersteuning zijn.
Alles wat ouder is—zoals 8.1, 8.0, 7.x en 5.x—valt onder end of life en ontvangt geen vendor-patch. Als je applicaties op die versies draaien, heb je dus geen “normale” upgrade-optie richting een officiële fix.
Daarnaast is er aandacht voor “versieherkenning” aan de buitenkant: een veiligheidsbedrijf telde op basis van HTTP-banners grofweg 884.000 internet-facing hosts met PHP 8.1 of ouder die door Shodan werden gerapporteerd. Dat is geen bevestiging dat die hosts daadwerkelijk kwetsbaar zijn, maar het geeft wel een schaal van blootstelling.
Wat is er bekend over CVE’s en de naam PHP2Shell RCE?
In de berichtgeving circuleren twee CVE-identifiers die onderzoekers gebruiken: CVE-2026-109618 en CVE-2026-109619. PHP noemt in de eigen notice echter geen van beide CVE-nummers. Bovendien is de exacte scope—welke versies precies geraakt worden en onder welke omstandigheden—nog niet volledig publiek geverifieerd.
De term PHP2Shell RCE komt uit de hoek van onderzoekers en wordt in de community gebruikt om deze twee RCE-kwetsbaarheden te onderscheiden. PHP zelf kondigt aan dat de volledige details, de getroffen versies en de fixed versies worden gepubliceerd met de release.
Geen workaround: zo bereid je je nu voor
Omdat er geen officiële workaround is aangekondigd, draait de voorbereiding om drie kernacties: uitzoeken waar je PHP draait, patchen waar mogelijk, en isoleren waar patchen nog niet lukt.
1) Maak direct een inventaris van je PHP-installaties
Start met het compleet in kaart brengen van PHP op elk systeem. Denk niet alleen aan webservers, maar ook aan PHP die gebundeld is in vendor appliances, Windows-software en hostingpanelen zoals cPanel en Plesk.
Let op dat interne tooling en door leveranciers meegeleverde componenten vaak vergeten worden—terwijl ze wel degelijk internet-facing kunnen zijn.
2) Zorg dat je op tijd kunt upgraden
PHP positioneert de release op een concreet moment (14:00 UTC in de aankondiging). Plan daarom vooraf je upgradevensters. Patch eerst de systemen die direct vanaf internet bereikbaar zijn.
Controleer daarnaast of je Linux-distributie of hostingprovider backports aanbiedt. Niet elke omgeving update hetzelfde tempo, en je wilt voorkomen dat “update gepland” gelijkstaat aan “update vertraagd”.
3) Pak end-of-life versies harder aan
Als je PHP op een end-of-life branch draait (zoals 8.1 of ouder), dan is er geen vendor fix. In dat geval heeft de aanpak twee opties: upgraden naar een ondersteunde versie, of het systeem tijdelijk uit het publieke netwerk halen.
Waar upgrade niet meteen kan, wordt geadviseerd om systemen achter een VPN of een web application firewall te plaatsen. CERT-EU adviseert bovendien om internet-facing applicaties te isoleren van publieke netwerken totdat de fix beschikbaar is.
4) Verhoog je detectie op verdachte processen
Omdat de aanvallen RCE kunnen misbruiken, is het logisch om te letten op gedrag rond PHP. De aankondiging noemt het monitoren van het opstarten van componenten zoals php-fpm, php-cgi, httpd of apache2, en specifiek om te zien of er shells, interpreters of download-tools worden gestart vanuit webcontext.
Voor Linux-omgevingen zonder endpoint detection wordt een proces-watcher genoemd die elk programma dat een PHP-proces start logt, inclusief command lines. Let wel: zo’n detectie voorkomt niets op zichzelf, maar helpt je wél om snel te zien dat er iets misgaat.
5) Reageer als je iets vindt
Als je verdachte activiteit detecteert, isoleer de server direct. Bewaar vervolgens relevante logs van webserver en PHP zodat je later gericht kunt onderzoeken. Ga daarna systematisch na op sporen zoals webshells, nieuwe bestanden in de webroot, en daarnaast zaken als nieuwe cron jobs, geplande taken en accounts die je niet herkent.
Is er al exploitatie in het wild?
Op het moment van de melding werd aangegeven dat er geen aanwijzingen waren van actieve exploitatie in de onderzochte omgevingen. Er wordt bovendien vermeld dat er geen proof of concept was gebouwd of gereproduceerd en dat er geen publieke exploitcode bekend was. Ook staat de koppeling dat de kwetsbaarheden nog niet in CISA’s Known Exploited Vulnerabilities catalog waren opgenomen.
Ter vergelijking: bij een eerdere PHP-kwetsbaarheid uit 2024 zagen partijen al binnen 24 uur exploitpogingen tegen honeypots. Dat laat zien hoe snel het mis kan gaan wanneer details eenmaal breed beschikbaar worden.
Praktische checklist voor IT & security teams
- Inventariseer alle PHP-omgevingen (incl. appliances, panelen en Windows-software).
- Prioriteer internet-facing systemen voor patching vóór/na de aangekondigde release time.
- Upgrade of isoleer end-of-life PHP (geen vendor fix beschikbaar).
- Detecteer verdacht procesgedrag vanuit php-fpm/CGI en bijbehorende webservers.
- Onderzoek bij incidenten direct webshell-indicatoren en persistence (cron/taken/accounts).
Wil je je voorbereiden op rogue agent- en compromisindicatoren in AI-gedreven workflows, dan kun je ook lezen hoe je snel en goed reageert op rogue AI-agenten. Dat artikel gaat niet over PHP2Shell RCE, maar helpt wel bij het opzetten van responsstappen wanneer systemen onverwacht opdrachten uitvoeren.
Wat je nu moet doen vóór de fix live gaat
Hoewel de publicatie van volledige details nog volgt, is de actie voor organisaties helder: ga uit van worst-case impact. Het feit dat er vooraf gelekte informatie is geweest, maakt het extra belangrijk om te zorgen dat jouw omgeving klaar is om direct te patchen.
Concreet betekent dit dat je vandaag nog moet weten welke systemen PHP draaien, welke branches je gebruikt, en hoe je internet-facing exposure tijdelijk kunt terugbrengen als er vertraging ontstaat bij upgrade of backporting.
Door PHP2Shell RCE nu proactief aan te pakken—inventariseren, patchen voor de blootgestelde systemen en isoleren waar je niet snel kunt upgraden—beperk je de kans dat je in de eerste golf van aanvallen terechtkomt.
Conclusie
De aangekondigde out-of-cycle release voor twee kritieke RCE-kwetsbaarheden maakt duidelijk dat PHP2Shell RCE serieus genomen moet worden. Omdat de fix alleen beschikbaar komt voor de ondersteunde PHP-branches (8.2 t/m 8.5) en er geen workaround is, ligt de nadruk op snelle voorbereiding, gerichte patching en het isoleren van omgevingen met end-of-life PHP.
Pak het gestructureerd aan: weet waar je PHP draait, zorg dat upgrades klaarstaan rond het publicatiemoment en versterk je detectie op verdachte proces- en persistence-activiteiten. Daarmee sta je beter voorbereid als de volledige details bekend worden of als aanvallen sneller op gang komen dan verwacht.
Bron: https://thehackernews.com/2026/10/php2shell-two-unpatched-critical-php.html
