In het kort
In oktober 2026 zaten kritieke fouten in PHP, de serversoftware achter veel websites. Wij sloten eerst de bekende misbruikroute, zodat sites online konden blijven. De officiële PHP-securitypatch staat inmiddels op onze servers, dat is de definitieve oplossing. Klanten hoeven niets te doen.
Kernpunten
- Het lek zat in PHP zelf, niet in één plug-in van een site.
- Eerst een tijdelijke maatregel op serverniveau; sites bleven online.
- De officiële PHP-securitypatch is uitgerold op onze hosting.
- Klanten wijzigen niets aan website of wachtwoorden.
Er is een ernstig beveiligingslek in PHP gemeld: de software waarmee heel veel websites draaien. Hieronder in gewone taal wat dat betekende en wat wij hebben gedaan.
Update: officiële patch uitgerold
De makers van PHP hebben een securityupdate uitgebracht die de fouten in PHP zelf herstelt. Die patch staat inmiddels op onze hosting (inclusief test- en productieservers).
Wat is die patch? Het is geen extra plug-in of “antivirus”, maar een nieuwe versie van de PHP-software op de server. De kwetsbare code is daarin vervangen door een veilige versie.
Waarom is dit de definitieve oplossing? Onze eerdere maatregel sloot de bekende misbruikroute, zodat sites online en beschermd bleven. De officiële patch verwijdert de onderliggende fout uit PHP. Daarmee is het probleem bij de bron opgelost, niet alleen afgeschermd. Dat is wat in de branche als afronding geldt.
In het kort
PHP zit op de server, onder je website. Bij dit soort lekken kan een aanvaller in het ergste geval de server overnemen, niet omdat er iets mis is met je content of een plug-in, maar door een fout in die basislaag.
Verschillende partijen raadden aan om websites tijdelijk offline te zetten. Dat deden wij niet: eerst een gerichte maatregel, daarna zo snel mogelijk de officiële patch.
Voor onze klanten
- Je hoeft niets te doen aan je website of wachtwoorden.
- Je sites bleven en blijven online.
- De bekende misbruikroute is afgesloten; de officiële PHP-securitypatch staat erop.
Vragen? Bel 010 22 66 400 of mail via contact.
Wat wij hebben gedaan
- Misbruikroute dicht: op serverniveau de bekende weg geblokkeerd waarmee dit lek werd misbruikt. Sites bleven werken; je hoefde niets te wijzigen.
- Noodplan klaargezet: er stond een onderhoudspagina klaar voor het geval dat, maar die hebben we niet hoeven gebruiken. Offline zetten was niet nodig.
- Officiële PHP-patch uitgerold: de securityrelease van de PHP-makers is op onze servers geïnstalleerd. Dat herstelt de fout in de software zelf en is de definitieve oplossing.
Waarom wij zo kunnen handelen
Wij beheren de servers zelf. Daardoor konden we een tijdelijke blokkade snel zetten, controleren of die werkte, en de definitieve patch doorvoeren zonder onnodige vertraging of downtime. Veel grotere partijen hebben meer tijd nodig voor dezelfde stappen, vandaar berichten over sites die tijdelijk offline gingen. Dat is bij ons niet de standaardreactie.
Technische toelichting
Het ging om kritieke fouten in PHP zelf (in rapportages o.a. CVE-2026-109618 en CVE-2026-109619), met remote code execution als ernstigste scenario. Exacte exploit-details herhalen we hier niet.
Relevant voor hosting: wie PHP aanbiedt, moet op serverniveau handelen. Klanten met een site bij ons hoeven zelf niets te wijzigen.
Bronnen
Veelgestelde vragen
Moet ik iets aan mijn website of wachtwoorden doen?
Nee. Wij hebben op serverniveau gehandeld, inclusief de officiële PHP-patch. Je hoeft niets te wijzigen.
Waarom gingen andere websites offline en die van Exedo niet?
Sommige organisaties zetten sites preventief offline omdat updates bij hen langer duren. Wij blokkeerden eerst de misbruikroute en rollen de officiële patch snel uit. Offline zetten was bij ons niet nodig.
Is de officiële patch de definitieve oplossing?
Ja. De makers van PHP hebben de fouten in de software zelf hersteld. Onze eerdere maatregel dichtte de bekende aanvalsroute; de securityupdate verwijdert die fouten uit PHP. Samen is dat de afronding.