Wat is PHP2Shell en waarom is het belangrijk voor bedrijven?
PHP2Shell is de naam voor twee kwetsbaarheden in de kern van PHP, geregistreerd als CVE-2026-109618 en CVE-2026-109619. Eenvoudig gezegd kan een aanvaller een speciaal opgesteld uploadverzoek sturen naar een webserver die PHP draait. In het ergste geval kan de aanvaller vervolgens eigen commando's op die server uitvoeren. Beide kwetsbaarheden kregen de beoordeling kritiek en binnen enkele dagen verscheen er openbaar proof-of-concept-exploitcode.
PHP bracht op de dag van de bekendmaking gerepareerde versies uit en nationale securityorganisaties zoals het NCSC-NL begonnen bij te houden welke software getroffen was. Oudere PHP-versies, zoals PHP 7.4, krijgen geen fixes meer. Systemen die daar nog op draaien, hebben dus een upgrade nodig in plaats van een patch.
Voor een bedrijf zit het risico in wat die servers bevatten. Een webshopserver verwerkt klant- en orderdata. Een integratieserver bevat meestal de inloggegevens waarmee hij verbinding maakt met het ERP, de webshop en het warehousesysteem. Dat maakt hem op zichzelf al een waardevol doelwit.
Waarom een gekoppelde stack lastiger te patchen is
De meeste middelgrote bedrijven hebben niet één PHP-systeem. Ze hebben er meerdere, in handen van verschillende teams en beheerd door verschillende partners. De webshop ligt misschien bij een bureau en het PIM bij een leverancier. De integratiescripts zijn mogelijk jaren geleden gebouwd door een developer, op een server waar sindsdien niemand meer naar heeft gekeken.
Als er een kritieke kwetsbaarheid opduikt, moet elk van die eigenaren worden gevonden, benaderd en opgevolgd. Sommige systemen worden door de leverancier gehost en voor je gepatcht. Andere zijn self-hosted en dan is de update jouw taak. Het lastigst te vinden zijn de stille systemen, zoals een maatwerk integratiescript op een oude PHP-versie dat elke nacht nog orders verplaatst.
Patchen is maar de helft van het werk. De andere helft is weten of er vóór de patch iets is gebeurd. Dat betekent logs nalopen die verspreid zijn over net zoveel systemen als er eigenaren zijn. Die versnippering is een van de redenen dat integratiebeveiliging een onderwerp voor de directie is geworden.
Wat een managed integratieplatform van je lijst haalt
Er zijn twee bekende manieren om integraties te draaien. Self-hosted middleware of maatwerkscripts geven volledige controle over de omgeving en sommige teams geven daar de voorkeur aan. De keerzijde is dat elke beveiligingsupdate, firewallregel en logreview voor die laag bij hen ligt, vaak op korte termijn.
Een managed integratieplatform legt dat werk bij de leverancier. Het bedrijf blijft eigenaar van zijn integraties en ziet wat er draait, maar de runtime eronder wordt up-to-date gehouden door een team dat daar speciaal voor is. Op het Alumio-integratieplatform komt dat neer op vier dingen:
- Beveiligingsupdates door het platformteam: updates van het besturingssysteem en de runtime worden uitgerold over alle door Alumio beheerde omgevingen, zodat klanten de integratielaag niet zelf hoeven te patchen.
- Kwaadaardige verzoeken gefilterd aan de rand: Cloudflare-firewallregels blokkeren kwaadaardige verzoeken voordat ze het platform bereiken.
- Eén plek om te controleren wat er is verplaatst: logs en een audit trail laten zien welke stromen liepen en wie wat heeft gewijzigd. Een review dekt dan in één keer de hele integratielaag.
- Strakke toegang: op rollen gebaseerde toegang bepaalt wie elke stroom mag bekijken of wijzigen en het platform is ISO 27001:2022-gecertificeerd.
Een managed platform haalt niet al het risico uit de rest van de stack. Het haalt wel een van de lastigst te patchen systemen van de lijst en het geeft één plek om te kijken wanneer het volgende advies binnenkomt.
Hoe Alumio met PHP2Shell omging
Het Alumio-platform gebruikt PHP, dus het PHP2Shell-advies was vanaf de dag van bekendmaking relevant. Cloudflare-firewallregels die kwaadaardige verzoeken blokkeren, waren al vóór 21 oktober 2026 actief op het hele Alumio-platform. Waar nodig werd Cloudflare-bescherming ook ingeschakeld voor klantomgevingen.
Zodra PHP en Ubuntu hun beveiligingsupdates publiceerden, voerde het Alumio-team ze tijdens geplande onderhoudsvensters door in alle door Alumio beheerde omgevingen. Alle getroffen omgevingen waren dezelfde dag weer online.
Daarna beoordeelde het team de monitoringdata vanaf 15 oktober 2026, waaronder Cloudflare-firewallgebeurtenissen en het bijhouden van applicatiefouten. Die review leverde geen bewijs op dat de kwetsbaarheden in door Alumio beheerde omgevingen waren misbruikt. Er was ook geen aanwijzing dat daardoor klantdata was ingezien. Alumio-klanten hoefden geen actie te ondernemen.
Wat je moet vragen vóór de volgende PHP-kwetsbaarheid
PHP2Shell zal niet de laatste kritieke kwetsbaarheid zijn in een technologie waar een groot deel van de commerce-stack op draait. De bedrijven die er rustig mee omgingen, wisten al welke systemen op PHP draaien, wie elk systeem patcht en waar ze moesten kijken naar tekenen van misbruik.
Die inventarisatie is het waard om nu te maken. Vraag per systeem of het door de leverancier of door jezelf wordt gehost, hoe snel beveiligingsupdates het bereiken en wie de logs kan controleren. Integratiescripts op vergeten servers komen daar meestal als zwakste schakel uit.
Integraties onderbrengen op een managed platform maakt de lijst korter. De integratielaag wordt gepatcht en gemonitord door het platformteam en het bedrijf houdt volledig zicht op zijn stromen. Wanneer het volgende advies binnenkomt, is er één server minder om achteraan te gaan en één duidelijke plek om te bevestigen wat er is verplaatst.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
