PHP2Shell: de balans opgemaakt

Wat is PHP2Shell?

PHP2Shell is de naam voor twee kritieke kwetsbaarheden in de kern van PHP, geregistreerd als CVE-2026-109618 en CVE-2026-109619¹. PHP is de programmeertaal die aan de serverkant van een website het werk doet: inloggen, betalingen verwerken, gegevens uit een database halen. PHP is groot, heel groot: het is de onderliggende technologie van onder meer WordPress, Wikipedia en Laravel (het framework waar wij veel mee werken). PHP zit ook in netwerkapparatuur, beheerpanelen en andere apparaten met een webinterface¹.

Het lek zit niet in één website of plugin, maar in de motor eronder. Een aanval bestaat uit minstens twee stappen: een aanvaller stuurt eerst een speciaal opgebouwde request waardoor PHP precies op het verkeerde moment zonder geheugen komt te zitten. PHP crasht en ruimt z'n geheugen dan niet netjes op. Door die bug kan een volgende request stukken van het geheugen uitlezen en misbruiken om eigen, kwaadaardige code uit te voeren². Dat laatste heet remote code execution (RCE): op afstand code uitvoeren op andermans server. Je kunt de server zo (vrijwel) alles laten doen wat je wilt.

Omdat het lek in die onderliggende motor zit, en niet in het framework of de applicatie die op PHP is gebouwd, is elke server kwetsbaar waar PHP met deze bug op draait. Elke PHP-versie van de afgelopen tien jaar is getroffen, terug tot PHP 5.4 (inmiddels zitten we op 8.5)³. Volgens W3Techs draait PHP op 69,2% van de websites waarvan de servertaal te achterhalen is⁴. Het NCSC (Nationaal Cyber Security Centrum) sprak van een zeer hoog risico op volledige overname van systemen¹, en Wiz plaatst PHP2Shell in het rijtje van Heartbleed (2014) en Log4Shell (2021)³.

Gevonden met AI

PHP2Shell is gevonden met hulp van AI. Onderzoekers van Calif, OpenAI en Wiz meldden het probleem in augustus 2026 onafhankelijk van elkaar bij PHP². Wiz gebruikte daarbij onder meer de AI-modellen Gemini 4 Argon en GPT-5.6 Sol³.

Het probleem was niet helemaal onbekend. Bij een externe security audit in 2024 zag een PHP-specialist al de eerste tekenen, maar niemand vond een concrete aanvalsroute. Het securityteam vond meerdere mogelijke oplossingen, maar elke oplossing had andere nadelen. Daarom konden ze het niet direct eens worden over de beste patch, waardoor het werk maandenlang stillag en weer opstartte. De PHP Foundation noemt dat zelf een structureel falen, veroorzaakt door de manier waarop besluiten worden genomen en door een gebrek aan mensen en middelen².

AI veranderde die afweging. Volgens Wiz deed één onderzoeker met AI-modellen in een week wat eerder een team van de beste professionals maanden zou kosten³. Complexiteit is daarmee geen bescherming meer: een lek dat voorheen eigenlijk te moeilijk was om uit te buiten, is nu door de toepassing van AI-modellen een reëel risico.

Wat gebeurde er op 21 oktober?

Op 21 oktober 2026 werd PHP2Shell bekend voordat iedereen de patch kon installeren. Dat maakte de dag tot een race tussen beheerders en aanvallers.

Bij een ernstig lek gaat het normaal anders. Het lek blijft geheim en een beperkte groep van vertrouwde partijen (bijvoorbeeld beheerders van Linux-distributies, beveiligingsbedrijven en hostingproviders) krijgt de patch vooraf onder embargo. Op een afgesproken moment gaat alles tegelijk live, zodat iedereen direct kan updaten. Dat moment is cruciaal: zodra een patch openbaar is, kunnen aanvallers zien wat er is veranderd, en dus waar ze moeten zoeken naar het lek.

Bij PHP2Shell liep die gecoördineerde release in de soep²:

Door de video kregen aanvallers extra aanwijzingen, en door de vroege publicatie van Chainguard konden ze de oplossing bestuderen terwijl de rest van de wereld nog wachtte. De PHP Foundation schrijft dat Chainguard daarmee weken werk van vele partijen negeerde².

Websites gaan op zwart

Grote organisaties wereldwijd haalden hun websites uit voorzorg offline, omdat het lek bekend was maar de patch nog niet beschikbaar. Het NCSC adviseerde per systeem een risicoafweging te maken, met het uitschakelen van systemen of bepaalde functionaliteiten als mogelijke maatregel¹. Hierbij maken systeembeheerders een afweging tussen de kans op een inbraak en de gevolgen ervan; bij grote, belangrijke systemen waar veel mensen op vertrouwen, zoals overheidsdiensten, is de impact van een hack veel groter dan bij kleine commerciële systemen. In Nederland gingen onder meer MijnOverheid, DigiD, de Tweede Kamer, het NCSC zelf, de Autoriteit Persoonsgegevens, RTL Nieuws en Tweakers om die reden tijdelijk offline, net als Notubiz, waarmee honderd gemeenten vergaderen⁵. Ook in de rest van Europa, in Azië en in Noord-Amerika gingen websites van overheden, scholen en ziekenhuizen tijdelijk uit de lucht.

Hoe Dutch Coding Company ermee omging

We hebben op 21 oktober het advies van het NCSC strak gevolgd en per systeem een afweging gemaakt tussen het risico van online blijven en de schade van offline gaan:

• Niet-kritische en interne systemen: deze hebben we direct offline gehaald. Een paar uur onbereikbaarheid weegt daar niet op tegen het risico.
• Productiesystemen van klanten: deze hebben we online gehouden. We hebben per klant het risico ingeschat en de hele dag gemonitord of we pogingen tot misbruik zagen en of er meldingen van geslaagde aanvallen in het nieuws kwamen.

Na de release om 16:00 hadden we de meeste systemen binnen tien minuten bijgewerkt. Twee systemen duurden iets langer door extra afhankelijkheden, zoals PHP-varianten waarvoor de patch pas later beschikbaar kwam.

Wat is het gevaar?

Het gevaar van PHP2Shell zit in drie eigenschappen tegelijk:

1. Geen inlog nodig: de aanvaller hoeft niet in te loggen en hoeft geen wachtwoorden te weten. Als de applicatie aan het internet hangt, is het al kwetsbaar.
2. Geen fout in de applicatie nodig: een aanval is niet afhankelijk van een fout in de specifieke applicatie, want PHP zelf is kwetsbaar.
3. Volledige controle: de aanvaller kan de hele server overnemen.

Om een aanval te kunnen doen volstaat een eenvoudige POST request, het soort request dat een browser verstuurt bij bijvoorbeeld het invullen van een formulier of bij inloggen, om de geheugencrash te veroorzaken¹. In de praktijk gebruikt een aanval een korte reeks van requests: de eerste brengt PHP in een kwetsbare toestand, de volgende maakt daar misbruik van⁶. Dat is volledig te automatiseren, waardoor een aanvaller automatisch kan proberen binnen te dringen bij miljoenen servers. Het is schieten met hagel.

Wat kan een aanvaller met RCE?

Een RCE is een van de meest impactvolle hacks. Een aanvaller die via RCE code uitvoert op een server, kan in principe alles wat de webapplicatie zelf kan en vaak nog meer:

• Gegevens stelen: klantgegevens, bestellingen en wachtwoorden uit de database, maar ook API-sleutels en toegang tot andere interne diensten.
• Een achterdeur plaatsen: met een zogenoemde webshell kan de aanvaller later altijd code uitvoeren op de server, ook nadat de server is gepatcht.
• Eenmaal binnen kunnen aanvallers verder doorbreken: de server wordt een opstapje naar interne systemen die vanaf internet niet bereikbaar zijn.
• De server inzetten bij andere hacks: cryptomining, spam en phishing versturen, of meedoen in een botnet (heel veel servers tegelijk een aanval laten uitvoeren).
• Toegang doorverkopen: zogeheten initial access brokers verkopen toegang tot gehackte servers door, bijvoorbeeld aan ransomwarebendes.

Het is daarmee eigenlijk alle hacks in één.

Hoeveel is er gepatcht?

Een week na de patch is een groot deel van de kwetsbare systemen nog niet bijgewerkt. Een systeem op PHP 8.2.35, 8.3.36, 8.4.27 of 8.5.12 (of nieuwer) is volledig beschermd tegen PHP2Shell². Patchen sluit de deur, maar als er al een hack heeft plaatsgevonden, hebben de hackers mogelijk al achterdeurtjes opengezet. Het is raadzaam om je logs na te kijken op mogelijke hackpogingen.

PHP is een enorm veelgebruikte programmeertaal. Lang niet alle servers worden goed onderhouden, dus er zijn veel servers die een verouderde versie van PHP draaien waar de patch niet voor beschikbaar komt. Securitybedrijf Wiz zag dat één week nadat de patch beschikbaar kwam, nog altijd bijna 53% van de getroffen organisaties kwetsbaar was⁶.

Een belangrijk deel van het probleem zit in verouderde PHP-versies. Alleen PHP 8.2 tot en met 8.5 kregen een officiële update. Voor 7.4, 8.0 en 8.1 publiceerde het PHP-securityteam alleen de gepatchte broncode, die sommige Linux-distributies en leveranciers van extended support hebben uitgerold. PHP 7.3 en ouder krijgen niets. Dat raakt veel websites: volgens W3Techs draait nog 34,3% van de PHP-websites op PHP 7 of ouder⁴. Wie daarop draait, moet eigenlijk een volledige upgrade doen. Dat is vaak niet zo eenvoudig en vraagt aanpassingen aan de applicatie zelf. Partijen die achterlopen met hun onderhoud, zijn daardoor veel langer kwetsbaar. Daarnaast zit PHP soms ook ingebouwd in apparatuur en softwarepakketten van leveranciers; daar ben je voor een update afhankelijk van die leverancier¹.

Zien we al hacks?

Jazeker: er zijn bevestigde, succesvolle aanvallen met PHP2Shell, maar nog niet op grote schaal. Het aantal pogingen is enorm. Cloudflare, een van de grootste internetbedrijven ter wereld, zag binnen een dag na de bekendmaking miljoenen aanvalspogingen⁷. Het overgrote deel mislukt, omdat de aanval complex is en afhankelijk van de specifieke serverconfiguratie en de hoeveelheid traffic op de server⁶.

Toch lukt het steeds vaker. Onderzoeker Adel Karimi legde vast hoe aanvallers via PHP2Shell code uitvoerden op zijn honeypots (een soort lokservers die bewust gemakkelijk te hacken zijn). Ook een "Steal my Bitcoin" challenge is inmiddels succesvol gehackt⁸. De Amerikaanse cyberdienst CISA zette PHP2Shell op 26 oktober 2026 al op de lijst van actief misbruikte kwetsbaarheden⁶. En we weten mogelijk lang niet alles: een goede aanvaller maakt weinig lawaai.

25 servers overgenomen via verouderde firewalls

Het duidelijkste voorbeeld is een geavanceerde aanval die onderzoeksbureau Dream op 25 oktober 2026 ontdekte⁹. Het doelwit waren firewalls van Palo Alto Networks. De beheeromgeving daarvan draait op PHP 8.0, een versie die sinds november 2023 geen security updates meer krijgt. Palo Alto Networks schrijft de aanval toe aan een Chineessprekende aanvaller. Die combineerde PHP2Shell met een tweede lek, in Linux, om zo toegang tot de hele server te krijgen:

1. Verkennen: met een speciale zoekmachine vond de aanvaller zo'n 19.000 van deze Palo Alto Networks-firewalls.
2. Selecteren: na filtering op land (Verenigde Staten, Japan, Taiwan en Zuid-Korea) en softwareversie bleven 240 doelwitten over.
3. Overnemen: 24 firewalls werden volledig overgenomen. Bij 22 daarvan liet de aanvaller alleen een achterdeur achter, voor later gebruik.
4. Doordringen: twee firewalls hoorden bij een organisatie gelieerd aan de Amerikaanse overheid. Via een tunnel drong de aanvaller het interne netwerk binnen en nam een derde, interne server over: nummer 25.
5. Uitbuiten: van daaruit maakte de aanvaller de inloggegevens van een serviceaccount buit en las alle gebruikers en groepen in het netwerk uit. Daarna probeerde de aanvaller wachtwoorden te raden en achterdeur-accounts aan te maken.

Deze aanval duurde van begin tot volledige controle over de server minder dan een kwartier⁹. Als je realtime wilt reageren, ben je dus gegarandeerd te laat. Je moet jezelf vooraf beveiligen.

Of die laatste stappen zijn gelukt, kon Dream niet vaststellen. De casus laat wel zien hoe één beheerinterface met een verouderde PHP-versie toegang kan geven tot heel gevoelige systemen. Met een bijgewerkte PHP-versie was deze aanval niet gelukt. Klanten van Palo Alto Networks konden PHP alleen niet zelf updaten: zij moesten wachten op een nieuwe versie van de leverancier.

Wat staat er nog te wachten?

De grootste golf aan PHP2Shell-aanvallen zal nog komen, denken we. Op dit moment struikelen veel aanvallers over de technische details, maar de aanvallen worden steeds beter en daardoor wordt het steeds makkelijker om ze op schaal uit te rollen. Wiz verwacht ook dat ervaren hackergroepen de aanval zullen perfectioneren en automatiseren⁶. Het grote aantal ongepatchte organisaties zijn interessante doelwitten.

Botnets, spam en phishing

We verwachten een golf van opportunistische aanvallers: botnetbeheerders, cryptominers en initial access brokers die een achterdeur plaatsen om die toegang door te verkopen. Daar zijn al voorbeelden van. Aanvallers probeerden via PHP2Shell servers toe te voegen aan Potassium, een variant van het Mirai-botnet. Door heel veel servers aan dit botnet toe te voegen, kan een aanvaller vanaf duizenden servers tegelijk een gecoördineerde aanval uitvoeren (een DDoS), waardoor een systeem overbelast en onbereikbaar raakt. Die eerste pogingen mislukten vooralsnog, maar ze geven een indicatie van waar we naartoe gaan⁷.

Dat risico komt doordat er veel kleine, slecht onderhouden servers in omloop zijn waar oude versies van PHP op draaien. Denk aan de oude WordPress-site van een vereniging, een verouderde webshop of een vergeten testomgeving. Zo'n server is op zichzelf geen interessant doelwit, maar kan gerecruteerd worden door hackers om te gebruiken in andere aanvallen:

• Spam en phishing: mail en phishingpagina's vanaf een bestaand, betrouwbaar ogend domein komen makkelijker langs spamfilters dan vanaf een nieuw adres.
• Botnets: duizenden overgenomen servers samen kunnen grote websites en diensten platleggen.
• Camouflage: aanvallen lijken dan te komen van een onschuldig bedrijf in plaats van van de echte aanvaller.
• Verdienmodellen op de achtergrond: cryptomining op kosten van de eigenaar, of het doorverkopen van de toegang.

Het is aannemelijk dat deze kleine servers nog maanden kwetsbaar blijven en een vast doelwit worden van geautomatiseerde scans. Waarnemers vergelijken PHP2Shell met Log4Shell uit 2021, een lek dat jaren later nog werd misbruikt.

Wat moeten we hiervan leren?

Doordat AI steeds beter wordt in het opsporen van beveiligingsproblemen zoals PHP2Shell, zullen deze steeds vaker voorkomen. De tijd om erop te reageren wordt ook steeds korter. AI maakt het namelijk makkelijker om kwetsbaarheden te vinden, zowel voor verdedigers als voor aanvallers.

Dit zien we ook terug in de cijfers: er worden op dit moment ongekend veel kwetsbaarheden gevonden. Het PHP-securityteam publiceerde sinds 1 juli 2026 vijftien CVE's (officiële registraties van een kwetsbaarheid)². En hoewel je het in het nieuws misschien niet bent tegengekomen, werd in dezelfde week een vergelijkbaar kritisch lek gevonden in Brotli, een compressietechnologie die wordt gebruikt in Node.js, Python en .NET (van Microsoft). GitLab dichtte binnen twee weken tweemaal met spoed een lek waarmee aanvallers een server konden overnemen.

Snel updaten wordt steeds belangrijker

Als je bij dit soort lekken pas na dagen of weken patcht, loop je een steeds groter risico. Bij PHP2Shell waren er al aanvalspogingen vóór de patch beschikbaar was, en binnen de eerste uren na de release liep dat op tot miljoenen aanvalspogingen. Om snel te kunnen updaten, moet je voorbereid zijn:

1. Weet wat je draait: houd een overzicht bij van al je systemen, inclusief de versies van PHP en andere onderdelen. Je kunt niet patchen wat je niet kent.
2. Zorg dat je up-to-date blijft: wie op een verouderde versie draait, krijgt bij een incident geen update en moet onder tijdsdruk een veel grotere upgrade doen.
3. Maak updaten routine, en bij voorkeur geautomatiseerd: met een geautomatiseerd updateproces staat een patch binnen minuten live in plaats van na dagen.

Conclusie: door AI gaat dit steeds vaker gebeuren

Een lek zoals PHP2Shell is buitengewoon complex. Juist door de komst van steeds krachtigere AI-modellen, wordt het niet alleen mogelijk, maar ook steeds makkelijker, om dit soort complexe lekken te exploiteren. De race tussen de beveiligers en aanvallers is van alle tijd, maar maakt nu een ongekende versnelling door.

Uiteindelijk is snel kunnen updaten je beste wapen in de strijd. Daarvoor moet je zorgen dat je je code onder controle houdt: draai up-to-date versies zodat je vooraan zit als er een patch komt, en zorg dat je code goed onderhouden is. Die controle geeft je namelijk snelheid, niet alleen bij het ontwikkelen van nieuwe features, maar ook bij het oplossen van bugs en security problemen. Een applicatie die al jaren niet is aangeraakt, kan vaak niet snel gepatcht worden zonder eerst een deel van het achterstallig onderhoud weg te werken.

Onderhoud voelt soms als een kostenpost zonder zichtbaar resultaat – tot het moment dat het ertoe doet. Als je snel moet schakelen, wil je je codebase onder controle hebben. Wij helpen je om verouderde systemen bij te werken en brengen snelheid in je softwareproject. Benieuwd hoe jouw software ervoor staat? Lees meer over onze werkwijze of neem contact met ons op voor een vrijblijvende kennismaking.