Op 21 oktober stond een groot deel van het web onder druk. Twee kritieke kwetsbaarheden in PHP maakten het mogelijk om servers op afstand over te nemen, zonder in te loggen. Draaide je applicatie op PHP, dan was hij kwetsbaar. Zo simpel was het. Dat gold dus ook voor de applicaties die wij bij Cube bouwen en onderhouden.
Samen met onze hostingpartners Fundaments en Shock Media hebben we bijna alle omgevingen tijdelijk offline gehaald, gepatcht en op de avond van 21 oktober weer online gebracht. Dat klinkt als één druk op de knop, maar dat was het niet. Per omgeving moesten we weten welke gepatchte PHP-versie beschikbaar was en of de applicatie daarna nog precies deed wat hij moest doen.
Wat is PHP2Shell?
PHP2Shell is de naam voor twee kritieke kwetsbaarheden in PHP, de programmeertaal waarop een groot deel van het web draait. Aanvallers konden via speciaal gemaakte webverzoeken op afstand code uitvoeren op een server, zonder daarvoor in te loggen. De kwetsbaarheden zijn geregistreerd als CVE-2026-109618 en CVE-2026-109619. Beide kregen een ernstscore van 9,2 op 10. De ene kwetsbaarheid draait om geheugenbeschadiging wanneer het geheugen vol raakt. De andere om interne status die achterblijft nadat het bijbehorende geheugen is vrijgegeven. Het probleem zat in PHP zelf, niet in een specifieke website of plug-in. Dat maakte de impact groot. Websites en applicaties op PHP, van WordPress, Joomla en Drupal tot maatwerksoftware, konden kwetsbaar zijn. Volgens het NCSC was iedere PHP-installatie die webverzoeken verwerkt getroffen.
Hoe verliep de bekendmaking?
Bij ernstige kwetsbaarheden worden details normaal gesproken pas bekendgemaakt wanneer er een oplossing beschikbaar is. Zo krijgen beheerders de kans om hun systemen bij te werken voordat aanvallers de kwetsbaarheid kunnen misbruiken.
Bij PHP2Shell liep dat anders. Op 20 oktober lekten de details uit. Binnen enkele uren bevestigde securitybedrijf watchTowr dat de kwetsbaarheden daadwerkelijk exploiteerbaar waren. Op 21 oktober meldde Cloudflare de eerste aanvallen, nog voordat de beveiligingsupdates beschikbaar waren. Rond 16.00 uur Nederlandse tijd bracht PHP de updates uit. Achteraf bleek dat aanvallers al eerder actief waren. Amazon registreerde op 17 oktober een aanvalspoging. De dreiging was dus niet pas begonnen toen de kwetsbaarheden openbaar werden.
Waarom stond de hele sector op scherp?
PHP is een veelgebruikte basistechnologie. Daardoor raakte PHP2Shell niet één leverancier of een specifieke groep websites, maar een groot deel van het web. Het NCSC waarschuwde dat aanvallers servers konden overnemen, websites onbereikbaar konden maken en gegevens konden buitmaken. CybelAngel telde wereldwijd ongeveer 2,24 miljoen PHP-servers die rechtstreeks vanaf internet bereikbaar waren. Van de servers die hun PHP-versie tonen, draaide 59 procent op een versie waarvoor geen officiële update uitkomt. De ernst was ook zichtbaar in de maatregelen die organisaties namen. Het NCSC haalde uit voorzorg tijdelijk de eigen website offline. Andere organisaties deden hetzelfde. Een website die offline gaat, is daarmee niet automatisch gehackt. Soms is het juist een bewuste maatregel om risico's te beperken terwijl een oplossing wordt voorbereid.
Hoe pakten we PHP2Shell bij Cube aan?
Wij bouwen en onderhouden de applicaties, Shock Media en Fundaments beheren de servers waarop ze draaien. Tijdens PHP2Shell bleek hoe goed die verdeling werkt. Wij kennen de software en onze opdrachtgevers, zij kennen de infrastructuur. Door die kennis samen te brengen, wisten we snel wat iedere omgeving nodig had. We zijn direct aan de slag gegaan, met drie uitgangspunten:
1. Eerst controleren, dan weer online.
Een omgeving ging pas weer online nadat we hadden gecontroleerd of de beveiligingsupdate goed was toegepast. We wilden niet alleen dat de server weer bereikbaar was, maar ook dat de noodzakelijke bescherming daadwerkelijk actief was.
2. Zorgvuldig boven snel.
Niet voor iedere server was de update direct beschikbaar. Voor een deel van de omgevingen moest deze eerst worden opgenomen in een open source softwarebron. We hebben dat proces niet geforceerd. Bij beveiligingsupdates wil je zeker weten wat er wordt geïnstalleerd en welke versie daadwerkelijk draait. Snel handelen is belangrijk, maar niet ten koste van die zekerheid.
3. Ook na het herstel blijven controleren.
Een update installeren is niet het einde van het werk. Na het online brengen voeren we aanvullende controles uit om te kijken of de omgevingen goed functioneren en of er aanwijzingen zijn voor misbruik. Gedurende de dag hielden we onze opdrachtgevers op de hoogte van de situatie en de voortgang. Het team werkte tot laat in de avond door om de omgevingen weer online te krijgen. Inmiddels zijn alle betrokken omgevingen weer online. De controles na het herstel lopen door.
Waarom stopt het werk niet bij weer online?
Een beveiligingsupdate voorkomt dat een kwetsbaarheid opnieuw kan worden misbruikt. Maar daarmee weet je nog niet of een aanvaller vóór de update al toegang heeft gekregen. Amazon registreerde al op 17 oktober een aanvalspoging, vier dagen voor de bekendmaking. Daarom kijken we niet alleen naar de periode vanaf 20 oktober, maar nemen we ook de dagen daarvoor mee. We controleren of de kwetsbaarheid is verholpen én of er aanwijzingen zijn dat iemand er eerder gebruik van heeft gemaakt.
Gebruik je zelf PHP? Dit kun je doen.
Draait jouw website of applicatie op PHP? Dan is het belangrijk om te weten welke versie je gebruikt en of de beveiligingsupdate is toegepast. De fixes zijn beschikbaar in PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35. PHP 8.1 en ouder worden niet meer regulier ondersteund. Vanwege de ernst van de kwetsbaarheden heeft het PHP-team voor PHP 7.4, 8.0 en 8.1 toch minimale patches uitgebracht. Kun je niet direct updaten? Dan zijn er tijdelijke maatregelen beschikbaar. Volgens het PHP-team beperken die alleen bepaalde aanvalspaden en lossen ze het probleem niet volledig op.
Dit kun je doen:
Controleer je PHP-versie. Vraag je hostingpartij of softwareleverancier welke versie draait en of de beveiligingsupdate is toegepast.
Plan een upgrade als je op een verouderde versie draait. PHP 8.1 en ouder worden niet meer regulier ondersteund. Een minimale patch of tijdelijke maatregel is geen structurele oplossing.
Laat controleren op eerdere aanvallen. Neem daarbij ook de periode vanaf 17 oktober mee.
Raadpleeg de informatie van het NCSC. Het NCSC publiceert een beslisboom en houdt op GitHub bij welke PHP-gerelateerde producten kwetsbaar zijn.
Wat laat deze dag zien?
Opdrachtgevers merken meestal vooral dat hun website of applicatie werkt. Op een dag als 21 oktober wordt zichtbaar wat daarachter zit. Een beveiligingsupdate installeren is één onderdeel. Weten welke versies op welke servers draaien, afstemmen met de hostingpartner, controleren of de update goed is toegepast en na het herstel blijven monitoren: ook dat hoort bij het onderhouden van software. Veel applicaties die we bij Cube bouwen, draaien op PHP. Dat maakt dit soort kwetsbaarheden relevant voor ons én voor de organisaties waarvoor we werken. We vinden het belangrijk om open te zijn over hoe we ermee omgaan.
Meer weten over PHP2Shell? We helpen je graag verder.
Veelgestelde vragen over PHP2Shell.
PHP2Shell is de naam voor twee kritieke kwetsbaarheden in PHP, gepatcht op 21 oktober 2026. Aanvallers konden daarmee zonder in te loggen op afstand code uitvoeren op servers die PHP gebruiken.
De oplossing zit in PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Voor PHP 7.4, 8.0 en 8.1 kwamen alleen minimale patches uit, die geen volledige oplossing bieden.
Niet per se. Veel organisaties, waaronder het NCSC zelf, haalden hun website uit voorzorg offline. Vraag je hostingpartij of leverancier wat er bij jouw omgeving is gebeurd en gecontroleerd.
Plan een upgrade naar een ondersteunde PHP-versie. De minimale patches voor oudere versies beperken alleen enkele aanvalspaden en bieden geen volledige bescherming.