PHP2Shell : De PHP Cyber attack

PHP2Shell: niemand zal jouw website aanvallen… toch?

Gisteren, 21 oktober, heb ik besloten om alle VPS’en die ik beheer tijdelijk plat te leggen. Ook heb ik, in overleg met de klanten, webshops die elders gehost worden tijdelijk offline gehaald, totdat de nieuwe PHP-versies met de veiligheidsupdate beschikbaar waren. Geen beslissing die je met plezier neemt, want een webshop die offline is, verkoopt niets. Maar soms is tijdelijk onbereikbaar zijn de verstandigste manier om grotere problemen te voorkomen.

Aanleiding was PHP2Shell, de naam waaronder twee ernstige kwetsbaarheden in PHP bekend zijn geworden. PHP is de programmeertaal waarop onder meer WordPress draait, en deze fouten kunnen aanvallers de mogelijkheid geven om zonder in te loggen eigen code op de server uit te voeren. Het probleem zit dus een laag dieper dan je plugins of je thema, en alleen WordPress bijwerken lost het niet op. De ontwikkelaars van PHP hebben hiervoor op 21 oktober noodupdates uitgebracht. Bron: PHP.

Ik was bepaald niet de enige die besloot tijdelijk de stekker eruit te trekken. Ook grote organisaties en officiële instanties haalden websites uit voorzorg offline. Dat betekent niet dat al die websites gehackt waren, maar dat hun beheerders het risico serieus genoeg namen om niet rustig af te wachten. Liever zelf bepalen wanneer je website even niet bereikbaar is, dan later moeten ontdekken dat iemand anders inmiddels bepaalt wat er op jouw server gebeurt.

Gezien het grote aantal mensen dat geen klant is, maar mij wel mailde met de vraag wat ze konden doen, heb ik ook via mijn nieuwsbrief uitgelegd hoe je je site tijdelijk ‘plat’ kunt leggen, zonder hem direct te verwijderen. Daarbij is het onderscheid tussen een onderhoudsmelding en werkelijk afschermen belangrijk: een onderhoudspagina die nog steeds via de kwetsbare PHP-installatie wordt uitgevoerd, neemt het onderliggende risico niet weg.

De gebeurtenissen van gisteren deden mij ook denken aan het cyberincident waarmee Albert Heijn eerder deze maand te maken kreeg. Het hele bedrijf lag niet letterlijk stil, want de winkels bleven open en de kassa’s werkten, maar de gevolgen waren groot. Digitale diensten vielen uit, online bestellen en bezorgen waren tijdelijk niet mogelijk en de bevoorrading raakte verstoord. Een deel van de systemen werd bovendien uit voorzorg uitgeschakeld om de IT-omgeving te beschermen. Bron: Albert Heijn.

Naar aanleiding daarvan zag ik verschillende mensen smalende opmerkingen maken. ‘Ze hebben geld genoeg’, bijvoorbeeld, of ‘hadden ze maar beter op de kleintjes moeten letten’. Leedvermaak ten top, en wat mij betreft vooral bedroevend. Achter zo’n bedrijfsnaam zitten ook medewerkers die hun werk proberen te doen, leveranciers die afhankelijk zijn van bestellingen en klanten die gewoon hun boodschappen nodig hebben.

Laat ik duidelijk zijn: het incident bij Albert Heijn en de cyberaanval op Odido maken vooral duidelijk dat niemand vrij is van risico. Ook een groot bedrijf met een eigen ICT-afdeling en een aanzienlijk beveiligingsbudget kan slachtoffer worden van cybercriminaliteit. Natuurlijk mag je vragen stellen over beveiliging, verantwoordelijkheden en gemaakte keuzes, maar uit het feit dat een bedrijf getroffen wordt, kun je niet automatisch afleiden dat men daar maar wat heeft zitten aanrommelen.

Onder een bericht in een grote online krant zag ik de vraag waarom dit Albert Heijn was overkomen en niet Jumbo. De reactie die mij bijbleef, kwam neer op: misschien is de vraag vooral waarom het Jumbo nog niet is overkomen. Dat is geen voorspelling dat ieder bedrijf onvermijdelijk gehackt wordt, maar wel een terechte correctie op het idee dat wie vandaag buiten schot blijft, zijn zaken dus vanzelfsprekend beter voor elkaar heeft.

In een maatschappij die steeds vijandiger lijkt te worden, waarin landen elkaar steeds nadrukkelijker als tegenstander behandelen, kijk ik ook anders naar onze digitale afhankelijkheid. We moeten rekening houden met meer dan criminelen die geld willen verdienen: digitale ontwrichting kan ook een middel zijn om politieke druk uit te oefenen of maatschappelijke onrust te veroorzaken. Daarmee zeg ik niet dat achter het incident bij Albert Heijn een buitenlandse overheid zit, want daarvoor heb ik geen bewijs, maar de afhankelijkheden die zichtbaar werden, geven wel te denken.

Wat als zoiets niet alleen Albert Heijn overkomt, maar meerdere supermarktketens tegelijkertijd, of een leverancier waarvan zij allemaal afhankelijk zijn? Wat als een verstoorde distributieketen ervoor zorgt dat boodschappen niet meer op de juiste plek terechtkomen? Ik ben geen crisisdenker, maar ik heb inmiddels wel meer blikvoer in huis dan ik normaal in een jaar koop. En dan ook nog van dat spul dat je desnoods koud kunt eten.

Maar wat heeft dat nu te maken met jouw webshop, je online leeromgeving of gewoon de website waarop je je bedrijf presenteert? Niemand zal jouw site aanvallen… toch? Ik heb in het verleden meer dan eens mensen mogen helpen die precies dat dachten, totdat zij ontdekten dat hun website wel degelijk slachtoffer was geworden. Voor een aanvaller hoeft jouw bedrijf helemaal niet interessant te zijn; soms is een bruikbare server al voldoende.

Zo’n site kan worden misbruikt om spam te versturen, bezoekers naar frauduleuze pagina’s te leiden of onderdeel te worden van een botnet waarmee andere partijen worden aangevallen. Soms gaat het om gegevens of afpersing, soms om experimenteren, en vaak zoekt geautomatiseerde software simpelweg naar alles wat kwetsbaar is. Die software vraagt niet eerst hoeveel bezoekers je hebt, wat je omzet is of hoe belangrijk jij je eigen website vindt.

Met de komst van AI wordt het bovendien makkelijker om code te onderzoeken en zwakke plekken te vinden. Dat helpt ontwikkelaars om fouten sneller te repareren, maar dezelfde mogelijkheden kunnen ook worden gebruikt om kwetsbaarheden uit te buiten. Ik verwacht daarom dat we vaker met situaties als deze te maken krijgen, en ik vind het verstandig om rekening te houden met de mogelijkheid dat ook jouw site een keer geraakt wordt. Of mijn site.

Het is goed om regelmatig je plugins, je thema en WordPress zelf bij te werken, sterke en unieke wachtwoorden te gebruiken en waar mogelijk tweestapsverificatie in te schakelen. Wanneer je de artikelen leest die op deze blog met ‘veiligheid’ getagd zijn, kom je nog veel meer maatregelen tegen waarmee je de kans op problemen kunt verkleinen. Maar PHP2Shell laat ook zien dat je met een keurig bijgewerkte website nog steeds afhankelijk bent van de software en het beheer van de server waarop die website draait.

En als het je dan toch overkomt, wat dan? Dan wil je vooral zo snel mogelijk weer veilig online zijn, met een schone website en betrouwbare gegevens. Daarvoor heb je meer nodig dan de mededeling dat er ‘ergens een backup’ staat: je moet weten of die backup bruikbaar is, of hij van vóór de besmetting dateert en of je hem ook kunt terugzetten wanneer je hostingomgeving niet beschikbaar is. Een backup die alleen bestaat op de server waar je niet meer bij kunt, biedt op dat moment weinig houvast.

In mijn artikel over ‘De Wet van Murphy’ leg ik uit waarom het samenbrengen van e-mail, websitehosting en domeinregistratie je kwetsbaar kan maken wanneer er iets misgaat. Als alles van dezelfde omgeving of toegang afhankelijk is, kun je behalve je website ook je mogelijkheden verliezen om klanten te informeren of je domeinnaam naar een andere server te verwijzen. Door die afhankelijkheden te beperken, maak je je online aanwezigheid robuuster en houd je meer mogelijkheden om in te grijpen.

Dat is ook de gedachte achter de hulp die ik bied met het WP Digital Marketing Service Contract. Goed onderhoud is belangrijk, maar ik vind het minstens zo belangrijk om vooraf na te denken over wat er moet gebeuren als onderhoud en voorzorgsmaatregelen een keer niet voldoende blijken. Gisteren betekende dat voor mij dat websites tijdelijk offline gingen, omdat ik liever die beslissing uitleg dan achteraf moet uitleggen waarom ik een bekend risico heb laten voortbestaan.

Voetnoot — PHP-versies controleren, stand 22 oktober 2026: de reparaties voor PHP2Shell zitten in PHP 8.2.35, 8.3.36, 8.4.27 en 8.5.12, en in eventuele latere onderhoudsversies binnen die reeksen. ‘Veilig’ betekent hier dat deze specifieke kwetsbaarheden zijn verholpen. Sommige hostingpartijen verwerken de reparatie in pakketten met een ouder versienummer; laat je hoster dat bij twijfel bevestigen. In WordPress vind je jouw versie via Gereedschap → Sitediagnose → Informatie → Server → PHP-versie. PHP bijwerken gebeurt via je hostingpartij of serverbeheerder, niet via de gewone WordPress-updates. Bronnen: PHP-beveiligingsadvies en WordPress Sitediagnose.