Op 21 oktober 2026 gingen veel Magento-webshops een paar uur op zwart. Niet door een storing, maar met opzet. Een kritiek lek in PHP, inmiddels bekend als PHP2Shell, was uitgelekt voordat er een patch bestond. Hypernode haalde de servers offline, wachtte op de officiële fix, rolde die uit en zette de shops daarna weer online.
De uitkomst is inmiddels duidelijk: de enige oplossing was een PHP-update. Geen Magento-patch, geen extensie, geen firewallregel. Hieronder wat er gebeurde, waarom dat zo was en wat je nu nog moet nalopen.
Wat was PHP2Shell?
Twee kwetsbaarheden in de kern van PHP, geregistreerd als CVE-2026-109618 en CVE-2026-109619. Beide kregen een CVSS v4.0-score van 9.2 op 10. Allebei maakten remote code execution mogelijk: een aanvaller kon via een gewoon HTTP-request zijn eigen code op je server laten draaien, zonder in te loggen.
Het probleem: de details lekten op 20 oktober uit, samen met een exploit-tool die het lek zijn naam gaf. Normaal krijgen beheerders eerst een patch en komen de details later. Nu was het andersom. Hoe makkelijk het lek te misbruiken was, wist op dat moment nog niemand. De zorg was dat aanvallers de patch zouden gebruiken om snel een werkende aanval te bouwen, want een patch laat precies zien waar het lek zit.
Het lek raakte vrijwel elke PHP-versie, terug tot PHP 5.4. Magento, Adobe Commerce, WooCommerce en Shopware draaien allemaal op PHP. Of jouw shop ook echt aan te vallen was, hing af van je serverinstellingen. Maar patchen moest iedereen.
Wat Hypernode deed
Wij zijn partner van Hypernode, en veel van de shops die wij onderhouden draaien daar. Hun aanpak was grondig. De tijdlijn op 21 oktober, volgens de statuspagina van Hypernode:
- 11:39 Hypernode zet tijdelijke maatregelen in PHP-instellingen door op alle servers, in afwachting van de patch.
- 14:30 Alle Hypernodes gaan offline. Bezoekers zien een onderhoudspagina.
- 15:45 De officiële PHP-patches zijn beschikbaar, later dan gepland. Hypernode begint direct met uitrollen.
- 16:45 De eerste websites komen weer online.
- 18:18 Het grootste deel van de servers met PHP 8.2 tot en met 8.5 is bijgewerkt.
- 20:33 Alle PHP-versies op het platform zijn gepatcht, ook de verouderde versies waar PHP geen nieuwe release meer voor uitbrengt.
Op 22 oktober meldde Hypernode dat alles weer volledig draaide.
Was offline halen nodig?
Achteraf: waarschijnlijk niet. Sansec concludeerde later dat de publieke exploits niet werken tegen een standaard PHP-installatie. Een aanval vraagt specifieke kennis van de server en specifieke omstandigheden. Massaal misbruik bleef uit, en hun advies is inmiddels dat je je winkel niet offline hoeft te halen.
Dat betekent niet dat het lek alleen theoretisch was. Inmiddels is gedemonstreerd dat een volledige aanval werkt op een ongepatchte server. Maar alleen op één precies nagebouwde testopstelling: een exacte PHP-build, een specifieke serverconfiguratie en geheugenadressen die daarop zijn afgestemd. Dezelfde PHP-versie met een andere build werkte al niet. Het lek is dus echt te misbruiken, maar niet met één knop tegen elke willekeurige webshop. Patchen bleef nodig, paniek was het niet.
Maar op de ochtend van 21 oktober wist niemand dat. Wat je toen wel wist: er lag een exploit-tool op straat, Cloudflare zag die ochtend al de eerste aanvalspogingen, en de verwachting was dat aanvallers binnen minuten na de patch zouden toeslaan. Honderden servers patch je niet in een paar minuten.
Dan is het een rekensom. Een paar uur offline kost omzet. Een gehackte webshop kost klantgegevens, een skimmer in je checkout, een melding bij de Autoriteit Persoonsgegevens en weken opruimwerk. Met de informatie van dat moment vinden wij de keuze van Hypernode goed te verdedigen. De tijdelijke PHP-instellingen van die ochtend waren een extra slot op de deur, geen garantie.
Waarom alleen een PHP-update hielp
Dit is het deel dat afwijkt van de meeste lekken waar je als webshop mee te maken krijgt.
Normaal zit een lek in Magento zelf of in een extensie. Dan installeer je een patch in je applicatie, en een WAF of een tool als Sansec Shield kan je in de tussentijd beschermen. Bij PHP2Shell werkte dat niet. Het lek zat in PHP, de laag onder je webshop.
PHP zelf is geschreven in C, zonder automatisch geheugenbeheer. Volgens Sansec ging het mis bij een fatale fout tijdens een request, bijvoorbeeld als een request over de memory_limit gaat. PHP stopt dan halverwege, voordat het intern heeft opgeruimd, en gebruikt daarna geheugen dat al was vrijgegeven. Zo’n fout kan een aanvaller misbruiken om eigen code uit te voeren of om stukjes servergeheugen uit te lezen.
Dat speelt zich af in PHP zelf, buiten je webshopcode. Sansec zegt zelf dat hun eigen Sansec Shield hier niet helpt, omdat het lek al toeslaat voordat je winkelcode en Shield aan de beurt zijn. Wat je in Magento ook aanpast, het helpt niet.
Wat had een aanvaller ermee kunnen doen? Het geheugenlek alleen al kon wachtwoorden, sessietokens en API-sleutels prijsgeven. En bij code-uitvoering draait de aanvaller als de gebruiker van de webserver. Die kan bij app/etc/env.php, met je databasegegevens en de sleutel waarmee Magento gevoelige data versleutelt. Vanaf daar is het een kleine stap naar klant- en bestelgegevens, een webshell voor blijvende toegang, of een skimmer die betaalgegevens aftapt in je checkout.
De fix was dus een nieuwe PHP-versie op de server:
| PHP-versie | Gepatcht vanaf |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
PHP 8.1 en ouder zijn end-of-life en kregen geen nieuwe officiële release, alleen een beperkte source-patch voor wie PHP zelf compileert. Distributies als Debian, Ubuntu en RHEL en sommige hosters, waaronder Hypernode, leveren voor die versies zelf gepatchte pakketten. Reken daar niet blind op als je ergens anders host.
Wat je nu nog moet checken
Zit je op Hypernode, dan is je productie-omgeving gepatcht. Toch is het goed om een paar dingen na te lopen, vooral als je ergens anders host of je server zelf beheert.
Draai je echt op een gepatchte versie? Check de versie die je webshop draait (PHP-FPM), niet alleen php -v op de command line. Die kunnen verschillen. Hosters op Debian, Ubuntu of RHEL leveren soms een gepatcht pakket met een ander versienummer. Vraag je hoster dan om bevestiging.
Vergeet je andere omgevingen niet. Staging, test-omgevingen, een oude shop die nog “even” online staat, een losse server voor een koppeling. Alles met PHP dat vanaf internet bereikbaar is, was een ingang.
Draai je op PHP 8.1 of ouder? Dan heb je een groter probleem dan dit ene lek. Je krijgt geen securityfixes meer, en het volgende lek komt er gewoon aan. Een oude PHP-versie hangt meestal samen met een oude Magento-versie. Upgraden betekent dan vaak beide tegelijk aanpakken.
Twijfel je of je op tijd was? Kijk naar nieuwe of gewijzigde bestanden in je webroot, onbekende cronjobs, nieuwe admin-accounts en scripts in je checkout-templates die je niet kent. Bij twijfel: laat iemand meekijken voordat je verder gaat.
De echte les: wie beheert jouw PHP?
Bij PHP2Shell bleek wie er verantwoordelijk is voor de laag onder je webshop. Bij Hypernode was het antwoord duidelijk, en werd het binnen een middag geregeld. Bij goedkope shared hosting of een server die ooit eenmalig is ingericht en daarna is vergeten, is het antwoord vaak: niemand.
Weet je niet precies op welke PHP-versie je shop draait, of wie die zou moeten updaten? Dat is meestal het moment om het uit te zoeken, en liefst voor het volgende lek. Voor de laag erboven, Magento zelf, geldt hetzelfde: lees waarom ‘laatste versie’ bij Magento-patches niet meer genoeg is.
Wat wij voor onze klanten deden
Voor de shops die wij onderhouden hebben we de releases en de status bij Hypernode die dag op de voet gevolgd en na de uitrol gecontroleerd of alles weer goed draaide. Al onze shops draaien op een ondersteunde PHP- en Magento-versie. Daardoor kregen ze de officiële fix direct, zonder noodoplossingen voor verouderde versies. Dat is precies waarom we shops bij blijven houden.
Wil je dat ook voor jouw shop? Bekijk ons Magento-onderhoud.
Veelgestelde vragen
Moet ik iets aanpassen in Magento?
Nee. Het lek zat in PHP, niet in Magento. De enige fix was een PHP-update op de server. Draai je op een gepatchte PHP-versie, dan ben je voor dit lek klaar.
Mijn shop draait op Hypernode. Ben ik veilig?
Voor PHP2Shell wel: Hypernode heeft alle PHP-versies op het platform gepatcht, inclusief verouderde versies. Check wel je andere omgevingen buiten Hypernode, zoals een losse staging- of koppelingsserver.
Was offline halen niet overdreven?
Achteraf wel, volgens Sansec: de publieke exploits werkten niet tegen een standaard PHP-installatie. Maar dat wist je op 21 oktober nog niet, en er werden die ochtend al aanvalspogingen gezien. Met wat toen bekend was, is een paar uur onderhoudspagina goed te verdedigen.
Ik draai nog op PHP 8.1. Wat nu?
Upgraden naar PHP 8.2 of hoger, en in de meeste gevallen je Magento-versie meenemen. Tot die tijd draai je op een versie die geen securityfixes meer krijgt.
Weet je niet zeker of jouw shop bij is?
Dan zoeken we het voor je uit: welke PHP- en Magento-versie je draait, of die nog securityfixes krijgt en wat er moet gebeuren als dat niet zo is. Vraag een quickscan aan of neem contact op.