Het PHP-lek van 21 oktober: wat we deden en waarom we online bleven

Een kritiek lek in PHPKeurigOnline zegtPHPPHP (Hypertext Preprocessor) is een populaire open-source scripttaal die speciaal is ontworpen voor webontwikkeling en server-side programmering. raakt bijna elke website. WordPressKeurigOnline zegtWordPressWordPress is een open-source contentmanagementsysteem (CMS) geschreven in PHP, waarmee je eenvoudig websites en blogs kunt bouwen en beheren., WooCommerceKeurigOnline zegtWooCommerceWooCommerce is de gratis e-commerce plugin voor WordPress. Bouw een professionele webshop met producten, betalingen en verzending — zonder technische kennis., JoomlaKeurigOnline zegtJoomlaJoomla is een gratis, open-source content management systeem (CMS) voor het bouwen van websites. en de meeste webwinkels draaien erop. Toen het PHP-team op dinsdag 20 oktober een beveiligingsupdate aankondigde voor twee lekken met een CVSS-score van 9,2, wisten we dat de dagen daarna spannend zouden worden.

In dit artikel blikken we terug. Wat hebben we gedaan, welke keuzes hebben we gemaakt, en waarom hebben we onze servers niet offline gehaald, terwijl andere hosters dat wel deden? Alle updates zoals we ze die dagen publiceerden, staan in ons eerdere artikel over het lek. Wil je de techniek tot op de configuratieregel, met versies, commando's en hoe je een PHP-build zelf controleert? Lees dan onze technische deepdive.

Wat er aan de hand was

Het ging om CVE-2026-109618 en CVE-2026-109619. De fouten zitten in de manier waarop PHP uploads verwerkt, in het onderdeel session.upload_progress. Dat gebeurt nog voordat de code van een website aan de beurt is. Een plugin of beveiligingsplugin in je site houdt zo'n aanval dus niet tegen^[1].

De update stond gepland voor woensdag 21 oktober om 16:00 uur. Normaal blijven de details tot dat moment geheim. Dit keer gingen er kort na de aankondiging al technische details en een aanvalstool rond. Wachten tot 16:00 uur was dus geen optie: vóór de update moest er al iets gebeuren.

Onze keuze: online blijven, met meerdere lagen beveiliging

Sommige hosters kozen ervoor om hun servers tot de update offline te halen. Wij hebben die afweging ook gemaakt, en kwamen op een andere uitkomst. Dat had drie redenen.

PHP draait bij ons apart van de webserver

Het grootste risico zat bij servers waar PHP als module ín de webserver ApacheKeurigOnline zegtApacheApache HTTP Server is een open source webserver ontwikkeld door de Apache Software Foundation. draait, mod_php genoemd. Dat schreef CloudLinuxKeurigOnline zegtCloudLinuxCloudLinux is een gespecialiseerd Linux-besturingssysteem voor webhostingproviders dat elke gebruiker isoleert in een eigen container.^[2], en de aanvalstool die rondging werkte volgens de maker ook alleen in die opstelling. Bij ons draait PHP vrijwel overal als aparte processen: via PHP-FPM op onze VPSKeurigOnline zegtVPSEen VPS is een eigen virtuele server met meer vrijheid en flexibiliteit dan shared hosting.'en en DirectAdminKeurigOnline zegtDirectAdminDirectAdmin is een webhosting control panel ontwikkeld door JBMC Software als kostenefficiënt en gebruiksvriendelijk alternatief voor cPanel.-servers, en via LiteSpeedKeurigOnline zegtLiteSpeedLiteSpeed is een snelle webserver met een efficiënte event-driven architectuur en ingebouwde caching, compatibel met Apache. op onze shared hostingKeurigOnline zegtShared hostingShared hosting is een hostingvorm waarbij meerdere websites dezelfde serverresources delen. met CloudLinux.

Een latere technische analyse van beveiligingsonderzoeker Daniele Berardinelli laat zien waarom dat uitmaakt^[3]. Bij mod_php kan een aanvaller de beschadigde toestand van PHP in hetzelfde verzoek misbruiken. PHP-FPM sluit het proces bij die fout juist af. Voor PHP-FPM beschrijft hij één bevestigde aanvalsroute, en die loopt via session.upload_progress. Dat is precies het onderdeel dat wij die ochtend al hadden uitgezet.

Een tijdelijke maatregel die we echt hebben nagemeten

Tussen 08:30 en 10:00 uur zetten we session.upload_progress uit op al onze servers. Daarna hebben we per server gecontroleerd dat de instelling ook werkt in de PHP-processen die bezoekers bedienen, en niet alleen in een configuratiebestand. Hoe dat zit, lees je hieronder bij het configuratieverhaal.

Imunify360 en CloudLinux als extra lagen

Op het grootste deel van onze shared hosting draait Imunify360KeurigOnline zegtImunify360Imunify360 is een uitgebreide beveiligingssuite voor Linux webservers met AI-aangedreven malware scanning.. Die firewallKeurigOnline zegtFirewallEen firewall is een beveiligingssysteem dat netwerkverkeer filtert en ongeautoriseerde toegang tot netwerken en servers blokkeert. kreeg op 21 oktober al in de ochtend een regel tegen het aanvalspatroon. Om 20:00 uur volgden nieuwe regels (versie 8.85), die ook de publieke aanvalstool, varianten daarvan en verdachte uploads blokkeren^[2]. Op servers waar Imunify360 nog ontbrak, hebben we het die ochtend geïnstalleerd. Daarnaast draait elk account op onze shared hosting in een eigen afgeschermde omgeving, CloudLinux CageFS. Een aanval op de ene website komt daardoor niet zomaar bij een andere.

Onze servers offline halen zou duizenden websites, webwinkels en formulieren urenlang onbereikbaar maken, voor een risico dat met deze lagen klein was. Voor klanten met gevoelige gegevens hebben we wel het advies van CERT-EU gedeeld: weeg zelf af of je je site tot de update afschermt^[4]. Dat advies volgden we zelf ook. Ons eigen klantsysteem hebben we tijdelijk achter een onderhoudsmelding gezet. Een handvol klanten vroeg ons hetzelfde voor hun website te doen, en dat hebben we gedaan.

Het configuratieverhaal: een instelling telt pas als PHP hem leest

Een onderdeel van PHP uitzetten klinkt als één regel in een configuratiebestand. In de praktijk zit er meer achter, en daar zit het verschil tussen een maatregel op papier en een maatregel die werkt.

• Draaiende processen lezen de instelling niet vanzelf. PHP-FPM en LiteSpeed lezen de configuratie bij het starten van hun processen. Een controle op de opdrachtregel zegt dan al "Off", terwijl de processen die je website bedienen nog met de oude instelling draaien. Daarom hebben we gemeten in de draaiende processen zelf, en PHP waar nodig opnieuw ingeladen. Dat kan zonder dat websites offline gaan.
• Elk account heeft zijn eigen omgeving. Op onze shared hosting draait elk account in CageFS, met een eigen kopie van de PHP-configuratie. We hebben de instelling daarom ook binnen de accounts van klanten nagemeten. Op een paar servers gold hij daar nog niet voor één soort PHP-versie. Dat hebben we dezelfde ochtend rechtgezet.
• Elke PHP-versie apart. Op onze servers draaien PHP-versies van 5.2 tot en met 8.5 naast elkaar, zodat ook oudere websites blijven werken. Elke versie heeft een eigen configuratie, en de maatregel moest in elke versie staan.

Op servers met een ouder besturingssysteem, waar de officiële update het langst op zich liet wachten, hebben we op de avond van 21 oktober nog een extra stap gezet. We installeerden daar een open-source PHP-extensie van de Belgische hoster Hosted Power^[6]. Die koppelt het kwetsbare onderdeel volledig los, zonder dat uploads op websites anders werken. We hebben hem eerst op een testserver beproefd en daarna server voor server geplaatst. Een deel van deze servers hebben we daarbij kort herstart, minder dan een minuut per server.

Wachten op de leveranciers, en dan meteen door

Een lek in PHPKeurigOnline zegtPHPPHP (Hypertext Preprocessor) is een populaire open-source scripttaal die speciaal is ontworpen voor webontwikkeling en server-side programmering. repareer je met een nieuwe versie van PHP. Die nieuwe versies maken drie partijen: het PHP-team zelf, DirectAdmin voor de PHP-versies op onze VPS'en en DirectAdmin-servers, en CloudLinux voor de PHP-versies op onze shared hosting. Sneller dan zij konden we niet zijn. Wel konden we ervoor zorgen dat elke update direct na verschijnen op onze servers kwam, ook midden in de nacht.

Bij de meeste PHP-versies is de reparatie ingebouwd zonder dat het versienummer verandert. Aan het nummer zie je dus niet of een server is bijgewerkt. Daarom hebben we na elke ronde per server en per PHP-versie in het programma zelf gecontroleerd of de reparatie erin zit.

Wat we onderweg tegenkwamen

Zo'n nacht gaat niet zonder kleine hobbels. In een paar PHP-versies stopt de reparatie een PHP-proces direct als het geheugen op is. Een paar websites liepen daardoor na de update tegen hun geheugenlimiet aan. Die sites hebben we direct een ruimere limiet gegeven.

Na de update meldden onderzoekers nog enkele problemen in PHP. Eén daarvan heeft het PHP-team bevestigd: een fout uit de update zelf, waardoor een PHP-proces in bepaalde gevallen kan crashen^[5]. De belangrijkste andere melding werkt alleen als session.upload_progress aanstaat, en dat laten we op onze servers uit. Brengt PHP een nieuwe versie uit, dan installeren we die meteen.

Wat betekent dit voor jou?

Je hoeft niets te doen. Werkt je website, dan is alles in orde. Heb je toch problemen, vul dan het contactformulier in op onze contactpagina.

Wel geven we je één advies mee: zet je website op de hoogste PHP-versie waarop hij goed werkt, het liefst minimaal PHP 8.4. Nieuwere versies krijgen langer beveiligingsupdates. Voor dit lek hebben we ook oudere versies laten repareren, maar bij een volgend lek is dat niet vanzelfsprekend. Hoe je wisselt, lees je in onze handleidingen PHP-versie wijzigen en PHP-versie wijzigen met CloudLinux.

Waarom we hosting zo inrichten

Dit lek liet zien waarvoor onze keuzes van de afgelopen jaren dienen. PHP draait apart van de webserver. Elk account heeft een eigen afgeschermde omgeving. De firewall krijgt nieuwe regels zodra een aanvalspatroon bekend is. En als er 's nachts een update verschijnt, staat die dezelfde nacht op onze servers.

Het resultaat: binnen tien uur na de release van PHP draaiden al onze servers op de gerepareerde versies, op CloudLinuxKeurigOnline zegtCloudLinuxCloudLinux is een gespecialiseerd Linux-besturingssysteem voor webhostingproviders dat elke gebruiker isoleert in een eigen container. vanaf PHP 5.2 en op onze andere servers vanaf PHP 5.6. Daarvoor hebben we geen servers offline gehaald, en we zien geen sporen van misbruik. Dank aan iedereen die ons die dagen vragen stuurde en ons het vertrouwen gaf. Zo willen we hosting doen: rustig, grondig en snel wanneer het erop aankomt.

Veelgestelde vragen