Twee kritieke kwetsbaarheden in de PHP-core, samen PHP2Shell genoemd, maken remote code execution zonder authenticatie mogelijk. Nadat een proof-of-concept voortijdig uitlekte, haalden Nederlandse organisaties, waaronder het NCSC, hun websites uit voorzorg offline. De officiële patches verschijnen vandaag om 16:00 uur.
De kwetsbaarheden zijn geregistreerd als CVE-2026-109618 en CVE-2026-109619 en hebben een CVSS-score van 9.2. Een aanvaller heeft geen inloggegevens nodig. Interactie met een gebruiker of beheerder is evenmin nodig. Volgens het Nationaal Cyber Security Centrum is een eenvoudig POST-verzoek mogelijk al genoeg om externe code uit te voeren op een kwetsbare webserver.
Het probleem zit in de PHP-engine zelf. Het gaat mis bij het parsingproces (data analyseren en omzetten naar een begrijpelijk formaat) van inkomende HTTP-verzoeken in het geheugen. Dat gebeurt nog voordat de applicatiecode actief wordt. Beveiliging op applicatieniveau helpt daardoor niet. Een zwaar beveiligd maatwerksysteem is net zo kwetsbaar als een standaard WordPress-installatie. Ook frameworks als Laravel of Symfony en een CMS als WordPress bieden geen bescherming, omdat hun securitychecks in deze requestfase nog niet actief zijn. Wie de exploit met succes uitvoert, kan direct code draaien met de rechten van het webserverproces.
De timing maakt de situatie extra lastig. Normaal gesproken verloopt zo’n lek via responsible disclosure, waarbij een geteste patch klaarligt voordat de details openbaar worden. Bij PHP2Shell ging dat mis. Via een anonieme publicatie op Hacker News kwam een werkende proof-of-concept naar buiten. Daardoor moesten de PHP-maintainers hun release-schema loslaten en in allerijl noodpatches maken.
Nederlandse sites gaan uit voorzorg op zwart
Vanochtend waren de gevolgen goed te zien. Diverse grote Nederlandse webplatforms, security-fora, nieuwssites en overheidsportals haalden hun systemen tijdelijk offline of zetten dynamische functies uit. Het NCSC deed dat ook met de eigen website. Deze organisaties vonden het risico te groot om op een werkende, geteste patch te wachten. IT-teams moesten vannacht al beslissen of ze kritieke systemen preventief zouden uitschakelen.
Die patch komt er nu aan. PHP brengt de officiële fixes vandaag om 16:00 uur Nederlandse tijd uit. Het NCSC adviseert organisaties om klaar te staan, zodat ze de update direct kunnen installeren. Daarna moeten ze PHP-FPM of Apache opnieuw starten. Wanneer je een Linux-server updatet, worden de nieuwe PHP-binaries en -libraries namelijk naar de schijf geschreven. Actieve processen in het werkgeheugen blijven echter oude code uitvoeren. Pas als de procesmanager die PHP aanstuurt herstart, laadt de server de gepatchte versie.
Wordt het lek al actief misbruikt? Daarover lopen de signalen uiteen. Volgens meldingen registreerden SOC’s binnen enkele uren na het uitlekken van de proof-of-concept massale, geautomatiseerde scans. Botnets doorzochten grote blokken IPv4- en IPv6-adressen op openstaande poorten, op zoek naar servers die verraden dat ze PHP draaien. De eerste aanvalsgolven zouden opportunistisch zijn en vooral bedoeld om web shells en cryptominers te installeren. Ook ransomwaregroepen en APT’s zouden de kwetsbaarheid inmiddels gebruiken om binnen te komen, waarna ze zich verder door het netwerk bewegen. Toch meldt het NCSC op dit moment geen bevestigd actief misbruik. Ook Huntress zag aanvankelijk geen misbruik in het wild.
Groot aanvalsoppervlak
Het aantal mogelijke doelwitten is groot. Naar schatting draait bijna 75 procent van alle websites waarvan de server-side techniek bekend is op PHP. De taal verloor de afgelopen jaren wel terrein aan Node.js, Go en Python. Omdat de fout in een breed gedeelde codebase zit, raakt het lek vrijwel alle actieve PHP-versies. Securitybedrijf Sansec noemt alle installaties vanaf PHP 5.4. Het bedrijf wijst daarbij vooral op webshops die draaien op Magento, Shopware of WooCommerce.
Ook CMS’en als WordPress, Drupal en Joomla lopen risico. Die vormen voor veel organisaties de basis voor hun website. Minder zichtbaar, maar net zo kwetsbaar, zijn interne applicaties: intranetten, urenregistratiesystemen en oudere CRM-pakketten. Ze lijken vaak niet vanaf internet bereikbaar, maar blijken via routeringsfouten of koppelingen met leveranciers (supply chain) toch toegankelijk.
Noodmaatregelen tot de patch
Voor veel organisaties is de PHP-versie die ze draaien het grootste probleem. Officiële fixes verschijnen alleen voor de ondersteunde branches, op dit moment PHP 8.2 tot en met 8.5. PHP 8.1 en oudere versies krijgen geen officiële patch van PHP zelf.
Wie zo’n oude versie draait, is aangewezen op dure commerciële supportcontracten van Linux-leveranciers of moet migreren. Het is aan te raden om sites op PHP 8.1 of ouder direct over te zetten naar een ondersteunde versie, of ze tijdelijk af te schermen.
In grote enterprise-omgevingen kost een gecontroleerde uitrol tijd. Daarom grijpen beheerders tot tijdelijke maatregelen. De eerste verdedigingslinie is een Web Application Firewall (WAF). Cloudflare, AWS en Akamai zetten binnen enkele uren zogenoemde virtual patches aan. Gebruikers van die diensten moeten wel nagaan of de regels tegen afwijkende multipart/form-data-payloads actief zijn en op blokkeren staan.
En zonder zo’n externe filterlaag? Dan moeten beheerders ingrijpen op de webserver zelf. Met aanpassingen in de configuratie kunnen ze verdachte verzoeken weggooien voordat die bij PHP-FPM aankomen. Een veelgebruikte maar voor gebruikers vervelende maatregel is het tijdelijk blokkeren van alle bestandsuploads of het flink verlagen van de maximale POST-grootte.
Lukt dat niet, dan blijft alleen de noodrem over: de applicatie in een statische read-only-modus zetten of helemaal offline halen. Daarnaast moeten security-analisten hun logbestanden doorzoeken op Indicators of Compromise (IoC’s). Geautomatiseerde scanners kunnen servers namelijk al zijn binnengedrongen in de uren voordat de noodmaatregelen van kracht waren.