PHP-lek van 21 oktober: wat er gebeurde en hoe het nu staat

Op woensdag 21 oktober werden twee ernstige beveiligingslekken in PHP bekend, de programmeertaal waarop het overgrote deel van alle websites draait, waaronder WordPress. Misschien heb je er iets van gemerkt, want een deel van de dag stonden de websites bij ons offline. In dit artikel zetten we op een rij wat er gebeurde, hoe we gehandeld hebben en hoe het er nu voor staat.

Wat was er aan de hand?

De lekken (CVE-2026-109618 en CVE-2026-109619) maakten het voor onbevoegden mogelijk om code uit te voeren op een webserver. Dat is zo ongeveer het ergste soort lek dat er bestaat: een aanvaller heeft er geen wachtwoord voor nodig en het raakt vrijwel het hele internet.

Hoe we gehandeld hebben

1. Tijdelijke maatregelwoensdag 21 oktober, 10:00

   Op dat moment was alleen bekend dat er twee ernstige lekken in alle PHP-versies zaten, met een CVE-score van 9,2. Details waren er nog niet en er waren nog geen geslaagde hacks bekend, al zag bijvoorbeeld Cloudflare wel steeds meer pogingen. Omdat de details van het lek niet bekend waren, wist niemand hoe het precies zat en wat er gedaan kon worden om het risico te beperken. Er werden wel steeds meer mitigaties en mogelijke acties om het risico te beperken bekend. Die hebben we steeds direct doorgevoerd, zoals het uitschakelen van bepaalde PHP-functies en het meerdere keren updaten van de firewall.
   Vanaf 10:00 hebben we ook continu zeer strenge malwarescans laten draaien, zodat we direct zouden zien als er ergens een script op onze servers of in de accounts van onze klanten werd geplaatst. Dat gebeurde niet.

2. Websites offlinewoensdag 21 oktober, 15:15

   Hoewel we geen pogingen tot misbruik zagen op onze servers, besloten we te kiezen voor de veiligste optie: alles offline. De grootste reden daarvoor is dat wij onze twijfels hadden over de effectiviteit van de mitigaties (tijdelijke oplossingen) die rondgingen op het internet, omdat niemand kon bevestigen dat dit voldoende bescherming zou bieden.
   In een situatie met zoveel onduidelijkheden en in potentie enorme gevolgen is enkele uren downtime te verantwoorden; het risico nemen niet.

3. Officiële oplossingwoensdag 21 oktober, 16:00

   De makers van PHP brachten de officiële update met daarin de fix voor versies 8.3, 8.4 en 8.5 uit. Daarna was het wachten op bijgewerkte pakketten van CloudLinux, de leverancier van de PHP-versies op onze servers.
   Bij het publiceren van de update werden ook de details van de kwetsbaarheden bekend en dat bevestigde ons voorgevoel: de bekende mitigaties en extra firewallregels verkleinden weliswaar het risico op een hack, maar dit was niet voldoende om de server te beschermen.

4. Tijdelijke oplossingwoensdag 21 oktober, 19:00

   Helaas duurde het een stuk langer dan we hoopten en hadden verwacht voordat CloudLinux de updates klaar had. Uit ons contact met andere providers bleek dat we niet de enigen waren die verrast waren. Omdat we zagen dat ze al meerdere keren hun zelfgestelde deadlines niet hadden gehaald, werkten we aan een tijdelijke oplossing.
   We installeerden zelf PHP-versie 8.3.36 op al onze servers en zetten al onze klanten tijdelijk op deze versie. 90% van de websites kwam tussen 19:00 en 20:30 weer online. De enige websites die niet online kwamen, waren verouderd en konden niet met een moderne PHP-versie omgaan.

5. Bijwerkendonderdag 22 oktober, 00:30

   De updates kwamen beschikbaar en we zijn direct begonnen met installeren en controleren, server voor server.

6. Opgelostdonderdag 22 oktober, 02:30

   Alle servers waren bijgewerkt en alle websites stonden weer online, op de PHP-versie die ze voorheen ook gebruikten.

We begrijpen goed dat het vervelend is als je website een middag en avond niet bereikbaar is. Dit ongemak weegt echter niet op tegen de mogelijke gevolgen. We hebben nooit eerder hoeven te beslissen alles uit voorzorg offline te halen, maar als dezelfde situatie zich weer voordoet, doen we precies hetzelfde.

Hoe staat het er nu voor?

• Alle PHP-versies die we aanbieden, van 5.2 tot en met 8.5, bevatten de beveiligingscorrecties voor beide lekken.
• De enkele websites die op een nog oudere PHP-versie draaiden, waarvoor geen correctie bestaat, hebben we naar een gecorrigeerde versie gezet.
• We hebben de servers tijdens en na het lek gecontroleerd op sporen van misbruik, zoals vastlopende PHP-processen, verdachte processen, geüploade bestanden en verzoeken die passen bij de bekende aanval. We hebben geen aanwijzingen gevonden dat het lek op onze servers is misbruikt en voordat we offline gingen zijn er ook geen pogingen hiertoe gevonden.

Is mijn website gescheiden van die van anderen?

Ja. Ieder hostingpakket draait bij ons in een eigen, afgeschermde omgeving. PHP draait onder de gebruiker van jouw pakket, zonder beheerrechten op de server, en kan niet bij de bestanden of databases van andere klanten. Ook het gebruik van processor en geheugen is per pakket begrensd. Meer details over onze beveiliging delen we bewust niet openbaar: hoe minder een aanvaller weet, hoe beter.