PHP2Shell: twee kritieke lekken in PHP halen DigiD en MijnOverheid offline

Wie woensdag wilde inloggen met DigiD of iets wilde regelen op MijnOverheid, kwam voor een dichte deur. Niet door een aanval, maar uit voorzorg: in PHP, de programmeertaal achter een groot deel van alle websites, zitten twee lekken waarmee een aanvaller zonder in te loggen eigen code op een webserver kan draaien. Rond vier uur ‘s middags kwam de update. Hieronder wat er aan de hand is, hoe het zo liep en wat je nu moet doen.

Wat er mis is met PHP

Het gaat om CVE-2026-109618 en CVE-2026-109619, samen PHP2Shell genoemd. Het PHP-project geeft beide een ernstscore van 9,2 op 10. De fout zit niet in WordPress, Drupal of een plug-in, maar in PHP zelf. Daarom raakt het in principe elke server die webverzoeken met PHP afhandelt, of dat nu via PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP of LiteSpeed gaat.

Beide lekken draaien om wat er gebeurt als PHP halverwege een verzoek moet stoppen, bijvoorbeeld omdat het geheugenlimiet is bereikt. Bij het eerste lek blijven half opgebouwde gegevens achter die PHP bij het opruimen toch als geldig behandelt. Bij het tweede blijft er interne status hangen die naar al vrijgegeven geheugen wijst, en die een volgend verzoek op dezelfde worker weer gebruikt. Een aanvaller kan die situatie met slim opgebouwde formulieren en uploads zelf veroorzaken. Volgens PHP is mod_php het gevaarlijkst: daar volstaat één verzoek, nog voordat de code van de website zelf draait.

Het onderzoeksbureau Calif bevestigde aanvallen zonder inloggen op onder meer WordPress, Drupal, Joomla, MediaWiki, Magento, Nextcloud, phpMyAdmin en Roundcube. De oudste getroffen code stamt uit PHP 5.4, uit 2012. Wiz liet daarnaast zien dat een aanvaller werkgeheugen kan uitlezen, met daarin mogelijk wachtwoorden, sessietokens en API-sleutels van andere verzoeken of van de server zelf.

Een oude fout, gevonden met AI

De wortels liggen ver terug. Calif beschrijft hoe beveiligingsonderzoeker Stefan Esser in 2004 al een vergelijkbaar lek rond de geheugenlimiet van PHP vond, en hoe in 2020 een bugmelding over lange formuliervelden waardoor PHP zonder geheugen kwam weinig aandacht kreeg. In 2024 stuitte een PHP-ontwikkelaar na een externe audit, betaald door het Duitse Sovereign Tech Agency en uitgevoerd door Quarkslab, op de eerste tekenen van het probleem. Een concrete aanval vond niemand, en de reparatie bleef volgens de PHP Foundation maandenlang hangen omdat elke oplossing iets anders brak. De stichting noemt die vertraging zelf een structureel falen van het securityteam, dat te klein was en te traag besliste.

Op 30 juli begon Calif een audit binnen Patch the Planet, een programma van OpenAI. Onderzoeker Ryan Austin ging met een taalmodel gericht zoeken naar verwanten van Essers oude fout, en had binnen enkele dagen een werkende aanval op WordPress. Op 11 augustus meldde Calif het lek bij PHP; OpenAI meldde dezelfde oorzaak onafhankelijk op dezelfde dag. Wiz volgde op 24 augustus met nieuwe aanvalsroutes. Calif benadrukt dat er geen speciale modellen aan te pas kwamen: kennis van de geschiedenis van PHP stuurde het model de goede kant op. Wiz stelt dat taalmodellen het bouwen van werkende exploits terugbrachten van een bijna onhaalbare klus tot uren werk. Dat past in wat we eerder zagen bij de cyberscores van nieuwe AI-modellen.

Hoe de bekendmaking ontspoorde

Het plan was een gezamenlijke bekendmaking op donderdag 22 oktober. Dinsdagmiddag rond vijf uur Nederlandse tijd doken de twee CVE-nummers op fora en sociale media op, met een verkeerde score van 10 en een verkeerd tijdstip. PHP vervroegde daarop de release naar woensdag 16.00 uur. Kort daarna zette Calif per ongeluk een video online waarin de aanval op meerdere systemen te zien was. Die werd snel verwijderd, maar kopieën gingen rond en hielpen anderen volgens de PHP Foundation bij het bouwen van eigen aanvallen.

Woensdagochtend om 09.41 uur publiceerde Chainguard, dat de patch net als andere distributeurs vooraf had gekregen, al images met de reparatie. Daarmee kon iedereen de fix bestuderen terwijl de rest van de wereld nog wachtte. Cloudflare had al sinds vijf uur ‘s ochtends filterregels actief voor zijn klanten en zegt aanvalsverkeer te hebben gezien na het uitlekken.

Nederland gaat op slot

Het NCSC adviseerde eigenaren van PHP-sites om zelf de risico’s af te wegen en hun site zo nodig tijdelijk offline te halen. Dat gebeurde op grote schaal. Volgens de Rijksoverheid gingen onder meer Overheid.nl, MijnOverheid.nl en DigiD uit de lucht, al draait Rijksoverheid.nl zelf niet op PHP. Sansec zag ook Tweakers, de Tweede Kamer, Security.NL en de site van het NCSC zelf verdwijnen. Om 15.13 uur meldde de Rijksoverheid dat er nog geen signalen van actief misbruik waren.

Om 16.00 uur verschenen PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Het NCSC geeft het lek de hoogste inschaling voor kans en schade en zegt: installeer met spoed. Het Europese CERT-EU waarschuwt dat de eerste proofs of concept rondgaan en adviseert om sites die niet direct te patchen zijn los te koppelen van internet.

Wat je nu moet doen

• Update PHP. Dat is de enige echte oplossing. Heb je hosting, vraag je provider of de update al is geïnstalleerd. Een update van WordPress of een plug-in helpt hier niet.
• Draai je PHP 8.1 of ouder? Dan krijg je geen officiële update meer. PHP heeft wel minimale reparaties voor 7.4, 8.0 en 8.1 gepubliceerd voor wie zelf compileert; anders is overstappen nodig.
• Gebruik je de pakketten van rpms.remirepo.net? Die kregen woensdag nog geen update. PHP raadt aan over te stappen op de pakketten van je distributie of zelf te bouwen.
• Kun je niet meteen updaten? Zet memory_limit=-1 en session.upload_progress.enabled=0 en herstart alle workers. Dat sluit bekende routes af, maar maakt de server niet veilig. De onderhoudsmodus van je CMS helpt volgens Sansec niet, omdat PHP het verzoek al verwerkt voordat de applicatie iets doet.
• Twijfel je? Omdat een aanvaller werkgeheugen kan uitlezen, raden wij aan om bij een server die ongepatcht openstond de wachtwoorden en sleutels die erop staan te vervangen.