Afgelopen woensdag stond de webwereld even op scherp. PHP, de taal waarop een groot deel van alle websites draait, bleek twee kritieke lekken te bevatten waarmee een aanvaller zonder inloggegevens code op een server kan uitvoeren. De lekken kregen samen de naam 'PHP2Shell'. Hieronder leggen we rustig uit wat er speelde, hoe het aan het licht kwam, en wat het betekent voor jouw website.
Wat is er precies gebeurd?
Het gaat om twee kwetsbaarheden in PHP zelf: CVE-2026-109618 en CVE-2026-109619, samen 'PHP2Shell' genoemd. Allebei maken ze remote code execution mogelijk: een aanvaller kan van buitenaf, zonder account, code laten draaien op de server, met de rechten van het webproces. Eén van de twee kan daarnaast stukjes werkgeheugen van PHP uitlezen.
Het belangrijkste om te snappen: de lekken zitten niet in een plugin, thema of in jouw eigen code, maar in de PHP-runtime, de motor die de code uitvoert. Daardoor is een site kwetsbaar ook als de eigen code netjes is. CVE-2026-109618 draait om een geheugenfout: als een verzoek het geheugen laat vollopen, kan PHP halverwege worden onderbroken terwijl interne gegevens nog maar half zijn opgezet, waarna de opruimstap die kapotte gegevens als geldig behandelt.
PHP beoordeelt beide lekken met een CVSS-score van 9.2 (kritiek); sommige securitybedrijven gingen zelfs richting de 10. Volgens de ontdekkers zijn versies vanaf PHP 5.4 tot en met PHP 8 kwetsbaar, en werkt een aanval ook tegen een standaardconfiguratie. Omdat PHP op het overgrote deel van het web draait (grofweg 70% van alle websites), raakt dit potentieel enorm veel sites in één klap.
- Twee lekken in de PHP-runtime: CVE-2026-109618 en CVE-2026-109619
- Ongeauthenticeerde remote code execution, plus uitlezen van werkgeheugen
- CVSS 9.2 (kritiek) volgens PHP
- Kwetsbaar van PHP 5.4 t/m 8, ook in standaardconfiguraties
- Zit in de motor, niet in jouw code of plugins
Wat bracht het aan het licht?
Twee dingen maakten dit verhaal bijzonder. Ten eerste de manier van ontdekken: de lekken werden gevonden met behulp van AI, door onderzoekers van onder andere Wiz en OpenAI. Geautomatiseerde analyse vond een type fout dat jarenlang onopgemerkt in de code zat.
Ten tweede de timing. Normaal gesproken verloopt zoiets via 'coordinated disclosure': eerst stil een patch klaarmaken, dan pas de details naar buiten. Maar op dinsdag 20 oktober lekten de details vóór die afspraak online uit, nog voordat er een patch was. Daarmee veranderde een gecontroleerde aankondiging in een race tegen de klok: aanvallers kregen de kennis op hetzelfde moment als verdedigers.
PHP reageerde daarop met noodpatches op woensdag 21 oktober. En het bleef niet bij theorie: securitybedrijven zagen al vroeg misbruikpogingen, deels zelfs vóór de officiële release. Een honeypot registreerde al op 17 oktober een poging, en Cloudflare zag in de vroege ochtend van de 21e aanvallen voorbijkomen nog voor de patch uit was.
Waarom dit ook kleinere websites raakt
Bij 'hack' denk je al snel aan grote bedrijven, maar juist dit type lek raakt iedereen. Omdat het in de runtime zit, helpt het niet dat jouw website-code netjes is: zodra de server PHP draait, is het aanvalsoppervlak er. Op gedeelde hosting, waar veel sites dezelfde PHP-installatie delen, weegt dat extra zwaar.
Webshops lopen daarbovenop nog een extra risico. Platforms als Magento, Shopware en WooCommerce draaien allemaal op PHP en zijn dus blootgesteld, ook als hun eigen code en plugins volledig up-to-date zijn. De enige echte bescherming komt van de hostingkant: een gepatchte PHP-versie.
Wat je nu moet doen
De boodschap van PHP zelf is helder: updaten is de enige veilige oplossing. Tijdelijke maatregelen (geheugenlimieten, WAF-regels) dichten maar een deel van de aanvalswegen.
- Zorg dat je server draait op een gepatchte PHP-versie: 8.5.12, 8.4.27, 8.3.36 of 8.2.35 (of nieuwer).
- Herstart na de update de PHP-FPM- of Apache-service, anders blijft de oude versie actief.
- Controleer de daadwerkelijk draaiende versie (niet alleen wat de pakketbeheerder meldt).
- Draai je op PHP 8.1 of ouder (end-of-life)? Daarvoor is geen officiële release, maar vaak wél een backported update via je host of distributie: laat die toepassen en plan een migratie naar 8.3 of nieuwer.
- Laat je logs nakijken op verdachte verzoeken rond en na 21 oktober.
En als BRKdesign je website verzorgt?
Dit lek raakt precies het soort sites dat wij dagelijks onder handen hebben. We bouwen en beheren zowel moderne, grotendeels statische websites als WordPress-sites, en die laatste draaien volop op PHP, dus daar is up-to-date blijven cruciaal.
Voor websites die wij hosten of beheren houden we de PHP-versie, de WordPress-core en de plugins bij, en volgen we dit soort kwetsbaarheden op de voet, zodat jij er zelf geen omkijken naar hebt. Twijfel je of jouw site (of die van je vereniging of bedrijf) goed zit? Vraag het ons gewoon, dan kijken we mee.
Veelgestelde vragen
Is mijn website hierdoor nu gehackt?
Niet automatisch. Het lek maakt een aanval mogelijk, maar of iemand het bij jouw site misbruikte hangt af van je server, je PHP-versie en hoe snel er is gepatcht. Sites op bijgewerkte hosting en grotendeels statische sites hebben weinig te vrezen.
Mijn site draait helemaal niet op PHP, loop ik dan risico?
Het lek zit in PHP, dus een puur statische site (alleen HTML, CSS en JavaScript) zonder PHP op de server heeft hier geen aanvalsoppervlak. Let op: veel 'gewone' sites draaien ongemerkt tóch PHP, bijvoorbeeld via WordPress of een webshop.
Ik gebruik WordPress of WooCommerce, wat nu?
Die draaien op PHP en zijn dus kwetsbaar, zelfs als je thema en plugins keurig up-to-date zijn. Zorg dat je hostingpartij PHP heeft gepatcht, en houd daarnaast je CMS en plugins zoals altijd bij.
Hoe weet ik of mijn hosting gepatcht is?
Vraag het je hostingprovider, of laat de draaiende PHP-versie controleren. Die moet 8.5.12, 8.4.27, 8.3.36 of 8.2.35 zijn (of nieuwer binnen dezelfde reeks).
Mijn site draait op PHP 8.1 of ouder. En dan?
Die versies zijn officieel end-of-life, dus PHP brengt er geen gewone release voor uit. Voor dit lek maakte het PHP-securityteam wél uitzonderlijk een source-backport voor 7.4, 8.0 en 8.1, en veel hosts en distributies (zoals cPanel, AlmaLinux en TuxCare) hebben daar een kant-en-klare update van uitgebracht. Laat die door je host toepassen, en plan daarnaast een migratie naar een ondersteunde versie (8.3 of nieuwer) als echte oplossing op lange termijn.
Wat als patchen nu even niet lukt?
Dan kunnen een firewallregel (WAF) of strakke geheugenlimieten tijdelijk wat risico wegnemen, maar ze vervangen de update niet. Zie het als een pleister, niet als de behandeling.