Op woensdag 21 oktober 2026 stond voor veel websitebeheerders alles in het teken van PHP2Shell. Twee kritieke beveiligingslekken in PHP vormden een serieus risico voor websites en webapplicaties over de hele wereld. Ook bij Webworx moesten we direct ingrijpen en besloten we uit voorzorg alle op PHP gebaseerde websites en applicaties binnen onze hostingomgeving tijdelijk offline te halen.

Inmiddels zijn alle benodigde beveiligingsupdates uitgevoerd en zijn de websites en applicaties weer online. In dit artikel blikken we terug op wat er gebeurde, waarom we deze beslissing namen en hoe we de situatie hebben aangepakt.

Wat was PHP2Shell?

Op dinsdag 20 oktober werd bekend dat er twee ernstige kwetsbaarheden waren ontdekt in PHP, de programmeertaal waarop een groot deel van het internet draait.

De kwetsbaarheden, geregistreerd als CVE-2026-109618 en CVE-2026-109619, kregen beide een kritieke CVSS-score van 9,2 op een schaal van 10.

Onder bepaalde omstandigheden konden kwaadwillenden deze kwetsbaarheden misbruiken om zonder inloggegevens schadelijke code op een server uit te voeren. Daarmee bestond het risico dat aanvallers toegang kregen tot vertrouwelijke gegevens of wijzigingen konden aanbrengen in systemen.

Het beveiligingsprobleem bevond zich niet in een specifiek CMS of framework, zoals WordPress, Craft CMS of Laravel, maar in PHP zelf. Hierdoor konden wereldwijd websites en webapplicaties die gebruikmaken van PHP worden getroffen.

Uit voorzorg hebben wij daarom alle op PHP gebaseerde websites en applicaties binnen onze hostingomgeving tijdelijk offline gehaald. Dit betrof onder andere websites die draaien op WordPress en Craft CMS, evenals onze maatwerkapplicaties die zijn ontwikkeld met het Laravel-framework.

Websites en applicaties die geen gebruikmaken van PHP, zoals onze Shopify-webshops en volledig headless oplossingen zonder PHP, konden gewoon bereikbaar blijven.

Meer technische achtergrondinformatie vind je in het artikel van Tweakers: Wat we nu weten over PHP2Shell.

Waarom besloten we websites en applicaties tijdelijk offline te halen?

De kwetsbaarheden waren al enige tijd bekend bij beveiligingsonderzoekers en de ontwikkelaars van PHP. Achter de schermen werd gewerkt aan een oplossing, die oorspronkelijk op 22 oktober beschikbaar zou komen.

Op 20 oktober kwam echter voortijdig informatie over de beveiligingslekken naar buiten. Een dag later werd zelfs al een gepatchte versie van PHP gepubliceerd, terwijl de officiële beveiligingsupdates voor de meeste gebruikers nog niet beschikbaar waren.

Hierdoor ontstond een risicovolle situatie: kwaadwillenden konden mogelijk achterhalen hoe de kwetsbaarheden werkten, terwijl veel websites nog niet konden worden bijgewerkt.

Er waren tijdelijke beveiligingsmaatregelen mogelijk, waaronder aanvullende firewallregels. Toch kon op dat moment niet met zekerheid worden vastgesteld dat deze voldoende bescherming boden.

Ook een reguliere onderhoudsmodus binnen bijvoorbeeld WordPress bood geen afdoende bescherming. Het beveiligingsprobleem bevond zich namelijk in PHP zelf, waardoor de kwetsbare code nog steeds uitgevoerd kon worden wanneer bezoekers alleen een onderhoudsmelding te zien kregen.

Daarom besloten wij alle op PHP gebaseerde websites en applicaties binnen onze hostingomgeving preventief offline te halen, totdat de officiële beveiligingsupdates beschikbaar waren en veilig konden worden geïnstalleerd.

Dat was geen eenvoudige beslissing. We realiseren ons dat websites en webapplicaties een belangrijk onderdeel vormen van de bedrijfsvoering van onze klanten. Een tijdelijke onderbreking kan directe gevolgen hebben voor de bereikbaarheid, dienstverlening en omzet.

Toch vonden we het risico om mogelijk kwetsbare websites en applicaties online te laten staan zwaarder wegen dan de gevolgen van een tijdelijke onderbreking.

Meer achtergrondinformatie over het verloop van deze gebeurtenissen lees je in het artikel van Tweakers: Tijdlijn: hoe kon het gebeuren dat sites offline moesten door de PHP-lekken?.

Waarom duurde het herstellen van de websites enkele uren?

Op woensdagmiddag 21 oktober kwamen de officiële beveiligingsupdates voor PHP beschikbaar. Daarmee was het probleem echter nog niet direct opgelost.

Onze hostinginfrastructuur bestaat uit verschillende serverconfiguraties, waaronder LiteSpeed en Nginx. Deze maken gebruik van verschillende PHP-pakketten en softwarebronnen, waardoor beveiligingsupdates niet altijd op hetzelfde moment beschikbaar komen.

De beveiligingsupdates voor onze LiteSpeed-servers waren eerder beschikbaar dan die voor onze Nginx-servers. Hierdoor konden we een deel van onze servers al bijwerken, terwijl we voor andere servers nog moesten wachten op de benodigde updates.

Tegelijkertijd probeerden wereldwijd grote aantallen serverbeheerders hun systemen bij te werken. Dit zorgde voor een uitzonderlijk hoge belasting van de achterliggende infrastructuur. Verschillende softwarebronnen en externe diensten waren hierdoor tijdelijk niet of beperkt bereikbaar, waardoor updates niet altijd direct konden worden opgehaald.

Ook wij ondervonden hiervan hinder. Verschillende systemen die we dagelijks gebruiken, waaronder CRM- en serverbeheeromgevingen, waren tijdelijk beperkt toegankelijk.

Het herstellen van de websites en applicaties was daardoor niet simpelweg een kwestie van één update installeren.

Hoe hebben wij de websites weer online gebracht?

Zodra de benodigde beveiligingsupdates beschikbaar waren, zijn we gestart met het patchen en testen van onze servers.

Vervolgens hebben we iedere tijdelijk offline gehaalde website en applicatie afzonderlijk gecontroleerd voordat deze weer online werd gebracht. We wilden niet alleen vaststellen dat de beveiligingsupdates correct waren doorgevoerd, maar ook controleren of alles daarna goed bleef functioneren.

Rond 19:00 uur konden we de eerste websites weer online brengen. Vervolgens hebben we de overige websites en applicaties één voor één nagelopen en opnieuw beschikbaar gesteld.

Later die avond waren alle tijdelijk offline gehaalde websites en applicaties weer bereikbaar en konden we de werkzaamheden afronden.

Gedurende de dag hebben we onze klanten via e-mail en onze statuspagina op de hoogte gehouden van de ontwikkelingen.

De gebeurtenissen op een rij

Wat kunnen we hiervan leren?

PHP2Shell laat zien dat de veiligheid van een website verder gaat dan alleen het installeren van updates voor WordPress, plugins of thema’s.

Een website of webapplicatie is afhankelijk van meerdere technische onderdelen: van het CMS of framework en de applicatiecode tot de programmeertaal, webserver, het besturingssysteem en de onderliggende infrastructuur.

Zelfs wanneer een website volledig up-to-date is, kan er in een van deze onderliggende onderdelen een ernstig beveiligingsprobleem ontstaan.

Daarnaast werd duidelijk hoe afhankelijk de internetsector is van gedeelde technologie en softwarebronnen. Wanneer wereldwijd grote aantallen beheerders tegelijkertijd beveiligingsupdates moeten uitvoeren, kunnen zelfs de systemen die deze updates beschikbaar stellen overbelast raken.

Ook het gebruik van actuele, ondersteunde softwareversies blijft belangrijk. Hoewel voor sommige oudere PHP-versies alsnog beveiligingspatches beschikbaar kwamen, is dit geen vanzelfsprekendheid. Het structureel bijhouden en moderniseren van de technische infrastructuur blijft daarom essentieel.

Voor ons onderstreept dit incident het belang van actief technisch beheer, goede monitoring en snel kunnen handelen wanneer er onverwacht een beveiligingsprobleem ontstaat.

Goed technisch beheer maakt het verschil

PHP2Shell laat zien dat een veilige en betrouwbare website meer vraagt dan alleen het regelmatig bijwerken van WordPress, plugins of andere software. Ook de onderliggende serverinfrastructuur, PHP-versies, beveiligingsmaatregelen en monitoring spelen een belangrijke rol.

Een beveiligingsincident als dit kun je niet altijd voorkomen. Waar je wél invloed op hebt, is hoe snel en zorgvuldig erop wordt gereageerd. Dat vraagt om actuele technische kennis, een goed beheerde infrastructuur en de mogelijkheid om direct in te grijpen wanneer dat nodig is.

Juist op zulke momenten blijkt de waarde van een betrokken technische partner. Een partij die niet alleen websites ontwikkelt, maar ook verantwoordelijkheid neemt voor het onderhoud, de beveiliging en de continuïteit ervan.

Bij Webworx vinden we dat onze verantwoordelijkheid niet ophoudt zodra een website of applicatie is opgeleverd. We blijven betrokken bij de techniek erachter en nemen waar nodig proactief maatregelen om de websites en applicaties van onze klanten te beschermen.

De tijdelijke onbereikbaarheid op 21 oktober was vervelend en had impact op onze klanten. Toch staan we achter onze keuze om veiligheid voorop te stellen.

We bedanken onze klanten voor hun geduld en begrip tijdens deze uitzonderlijke situatie.