Inhoudsopgave
In oktober 2026 maakte PHP twee ernstige lekken bekend. Iemand zonder inlog kon er mogelijk code mee uitvoeren op een webserver. PHP is de taal waar WordPress en het grootste deel van alle websites op draaien, dus de schrik was groot. Een Europees agentschap waarschuwde dat websites misschien offline moesten tot de update er was. Bij ons hoefde dat niet.
Een lek, geen hack
In het nieuws liep het soms door elkaar, maar dit was geen hack. Bij een hack is er ingebroken: gegevens gestolen, een website overgenomen. Hier ging het om een lek, een zwakke plek in PHP die misbruikt kón worden. Dat is een ernstig risico en daarom moest het snel dicht. Maar een lek is nog geen inbraak. Wie op tijd maatregelen nam, kon zijn website gewoon online houden.
Wat er aan de hand was
De lekken kregen de nummers CVE-2026-109618 en CVE-2026-109619, allebei met een ernstscore van 9,2 op 10. Dat stond in de aankondiging van PHP zelf en in het advies van CERT-EU, het beveiligingsteam van de Europese instellingen. De technische details kwamen pas met de update. Die kwam op 21 oktober uit, met de uitleg op php.net.
Het eerste lek gaat over geheugen. Raakt PHP midden in een verzoek door zijn geheugen heen, dan kan het op een moment stoppen dat interne gegevens nog maar half zijn klaargezet. Bij het opruimen behandelt PHP die halve gegevens als echt en daar kan een aanvaller code doorheen smokkelen. Een aanvaller kan PHP met een slim opgebouwd formulierverzoek bewust door zijn geheugen jagen (technische details). Het tweede lek gaat over restjes: gegevens van het ene verzoek blijven soms achter in het proces dat daarna het volgende verzoek afhandelt, terwijl het geheugen eronder al is vrijgegeven (technische details).
Het gevaarlijkste is dat dit kan gebeuren voordat de website zelf ook maar een regel code uitvoert. Een beveiligingsplugin in WordPress of een controle in de code van de site komt dus te laat. Volgens PHP was het risico het grootst bij servers die PHP als module in de webserver draaien. Onze servers gebruiken PHP-FPM. Gaat daar bij de start van een verzoek iets mis, dan wordt het proces opgeruimd in plaats van hergebruikt. Dat maakt het eerste lek daar lastiger te misbruiken, maar niet onmogelijk.
De update stond gepland voor 21 oktober. Diezelfde ochtend zag Cloudflare de eerste aanvalspogingen en op internet ging een voorbeeld van een aanval rond. Vanaf dat moment was het de vraag wie er eerder was: de aanvallers of de update.
Wat we deden voordat de update er was
Beveiliging is bij ons dagelijks werk. Elke ochtend lopen we onze servers na en volgen we de beveiligingsmeldingen voor de software waar de sites van onze klanten op draaien. Daardoor waren we er vroeg bij. Op de ochtend van 21 oktober zagen we het advies van CERT-EU en rond acht uur stonden de eerste maatregelen al op al onze servers. Dat was ruim voordat het nieuws er vol van stond en voordat Cloudflare de eerste aanvalspogingen zag.
Het ging om vier maatregelen, op basis van wat er toen bekend was.
- Upload progress uit. De eerste analyses en het voorbeeld van een aanval dat rondging, draaiden om session upload progress, een functie die de voortgang van bestandsuploads bijhoudt. Die staat nu uit voor elke PHP-versie op elke server. Na het uitzetten werkten de sites die we controleerden gewoon door.
- Strengere sessies. PHP accepteert alleen nog sessies die het zelf heeft aangemaakt. Een aanvaller kan dan niet zelf een sessie verzinnen. Dit was een extra slot, op advies van beveiligingsbedrijf Sansec.
- Blokkade aan de voordeur. De firewall voor webverkeer op onze servers weigert verzoeken die op de aanval lijken die rondging. Zo'n verzoek komt niet eens bij PHP aan.
- Weg van oude PHP-versies. Alleen PHP 8.2 en nieuwer krijgen de update. De laatste sites die nog op een oudere versie draaiden, staan nu op PHP 8.3.
Toen de details bekend werden, bleek het lek breder dan die ene functie. De maatregelen sloten de route af die toen rondging, maar de echte oplossing was de update. Daarom hebben we die er zo snel mogelijk op gezet.
Daarnaast controleren we elke dag of er ergens sporen van misbruik zijn: nieuwe PHP-bestanden in uploadmappen, meldingen van de malwarescanner en de aanvallen die de firewall tegenhield. Dat doen we tot twee weken na de update. Tot nu toe hebben we geen sporen van misbruik gevonden.
De update
PHP bracht de update uit op 21 oktober: versie 8.2.35, 8.3.36, 8.4.27 en 8.5.12. Op de eerste van onze servers stond hij er dezelfde middag om 15:55 uur op, op de rest om 22:53 uur. We wachtten niet op het vaste onderhoud in de nacht. Een update van PHP komt op een hostingserver namelijk niet rechtstreeks van de makers. De beheersoftware van de server maakt er eerst eigen pakketten van en dat kost een paar uur. Juist die uren moesten de maatregelen hierboven overbruggen.
Dit werk hoort bij onze hosting: de servers bijhouden, updates installeren en ingrijpen als er iets speelt. Met website onderhoud houden we daarnaast WordPress, plugins en thema's van je site bij, zodat ook daar geen verouderde software blijft staan.
Waarom niets offline hoefde
Een site offline halen is de veiligste keuze als je verder niets kunt doen. Voor een webshop, of een bedrijf dat zijn aanvragen via de site krijgt, kost het wel klanten. Bij ons was dat niet nodig. De maatregelen hierboven sloten de route van de aanval af en de update stond nog dezelfde dag op al onze servers.
Staat je website niet bij ons?
Dan heb je met de maatregelen van je eigen hostingpartij te maken en niet met die van ons. Stel je hostingpartij dan deze vier vragen.
- Op welke PHP-versie draait mijn site? Lager dan 8.2 betekent: geen update van PHP zelf.
- Is de update al geïnstalleerd en wanneer?
- Draait PHP als module in de webserver of via PHP-FPM?
- Heeft de server een firewall voor webverkeer die deze aanval herkent?
Krijg je geen duidelijk antwoord, of wil je dat iemand meekijkt? Neem dan contact met ons op.
