PHP2Shell: zo hielden we je website veilig én online

Op 20 oktober 2026 werden twee ernstige beveiligingslekken in PHP bekend, ook wel PHP2Shell genoemd. Bij Hoasted hebben we direct maatregelen genomen om websites te beschermen, zonder ze preventief offline te halen. Inmiddels zijn alle servers bijgewerkt en zijn de tijdelijke maatregelen teruggedraaid.

In dit artikel leggen we uit wat er gebeurde, welke keuzes we maakten en wat dit betekende voor jouw website of die van je klanten. Ook kijken we terug op wat beter kon en delen we enkele bijzondere reacties die we van klanten ontvingen.

Wat was er aan de hand?

Op dinsdag 20 oktober werden twee ernstige kwetsbaarheden in PHP bekendgemaakt: CVE-2026-109618 en CVE-2026-109619.

PHP is de programmeertaal waarop veel websites en applicaties draaien, waaronder WordPress en WooCommerce. Door deze kwetsbaarheden konden aanvallers onder bepaalde omstandigheden eigen code uitvoeren op een server.

Omdat het probleem in PHP zelf zat, konden websites wereldwijd ermee te maken krijgen. Een definitieve beveiligingsupdate werd op woensdag 21 oktober verwacht.

Totdat die update beschikbaar en geïnstalleerd was, moesten hostingproviders bepalen hoe ze hun klanten zouden beschermen.

Onze keuze: websites beschermen én beschikbaar houden

Bij een ernstig beveiligingslek is het tijdelijk offline halen van websites een mogelijke voorzorgsmaatregel. Daarmee voorkom je dat websites via het internet bereikbaar zijn, maar tegelijkertijd worden ze onbereikbaar voor bezoekers en klanten.

Voor een webshop betekent dat gemiste bestellingen. Voor een webbureau betekent het mogelijk tientallen klanten die tegelijkertijd vragen waarom hun website niet bereikbaar is.

Daarom kozen we bij Hoasted voor een andere aanpak: websites online houden en de bekende aanvalsroutes met aanvullende beveiligingsmaatregelen afschermen.

Onze inschatting was dat we hiermee de risico’s voldoende konden beperken totdat de definitieve beveiligingsupdate beschikbaar was.

We hielden daarbij rekening met twee belangrijke zaken:

1. Beveiliging: de bekende aanvalsmethoden zo snel mogelijk blokkeren en aanvullende maatregelen nemen zodra er nieuwe informatie beschikbaar kwam.
2. Beschikbaarheid: websites en applicaties zoveel mogelijk bereikbaar houden, zodat jouw bedrijfsvoering en die van je klanten konden doorgaan.

We boden daarnaast instructies voor klanten die hun website uit voorzorg toch tijdelijk offline wilden halen.

Welke beveiligingsmaatregelen hebben we genomen?

In de uren voorafgaand aan de officiële PHP update hebben we meerdere beveiligingslagen toegevoegd aan ons hostingplatform.

1. Aanvullende firewallregels

Vanaf woensdag 21 oktober om 08:30 activeerden we eigen regels in onze Web Application Firewall (WAF).

Deze firewall controleert inkomende verzoeken aan websites en kan verdachte verzoeken blokkeren voordat ze de website bereiken.

Hiermee konden we bekende aanvalspatronen gericht tegenhouden zonder alle websites offline te halen.

2. Tijdelijk uitschakelen van een kwetsbare PHP functie

Om 08:50 schakelden we de uploadvoortgangsfunctie van PHP uit. Via deze functie liep een van de bekende aanvalsroutes.

Deze maatregel gold voor alle PHP versies op onze shared, reseller en managed VPS servers, inclusief oudere versies.

Normale uploads bleven mogelijk. Alleen een voortgangsindicator die specifiek van deze PHP functie gebruikmaakte, kon tijdelijk niet goed werken.

3. Extra bescherming via Imunify360

Om 13:40 voegden we aanvullende beveiligingsregels toe vanuit Imunify360.

Dit is beveiligingssoftware die we op ons hostingplatform gebruiken om onder andere schadelijke verzoeken en aanvallen op websites te detecteren en te blokkeren.

Deze extra regels vormden een aanvullende beveiligingslaag bovenop onze eigen firewallregels en de eerder genomen PHP maatregel.

4. Aanvullende maatregelen na de PHP release

Toen op woensdagmiddag de officiële PHP updates beschikbaar kwamen, werd ook meer duidelijk over de kwetsbaarheden.

Daarom namen we tijdelijk extra voorzorgsmaatregelen:

• OPcache werd uitgeschakeld. Dit is een techniek die PHP code tijdelijk opslaat om websites sneller te laten reageren.
• Uploads en formulierverzendingen werden tijdelijk beperkt tot 32 MB, met een maximum van 30 MB per bestand.
• De eerder uitgeschakelde uploadvoortgangsfunctie bleef uitgeschakeld.

Deze maatregelen konden tijdelijk invloed hebben op de prestaties en functionaliteit van websites, maar boden aanvullende bescherming zolang de definitieve updates nog niet waren geïnstalleerd.

Belangrijk: deze maatregelen waren geen vervanging voor de officiële beveiligingsupdate. Ze waren bedoeld om de periode tot de installatie daarvan zo veilig mogelijk te overbruggen.

Waarom duurde het installeren van de PHP updates langer?

Op woensdag 21 oktober om 16:00 werd de officiële beveiligingsupdate door het PHP team uitgebracht.

Maar een nieuwe PHP release betekent niet automatisch dat deze direct op iedere hostingserver geïnstalleerd kan worden.

Ons platform maakt onder andere gebruik van CloudLinux en cPanel. Deze software helpt ons om hostingaccounts gescheiden te houden, PHP versies te beheren en websites via een controlepaneel te laten beheren.

De leveranciers moesten de nieuwe PHP code eerst verwerken tot installatiepakketten die geschikt waren voor onze servers.

Deze pakketten kwamen gefaseerd beschikbaar en later dan verwacht. Daarnaast ontstond er wereldwijd grote drukte op de downloadservers doordat hostingproviders tegelijkertijd dezelfde updates probeerden binnen te halen.

We bleven de beschikbaarheid van de pakketten controleren en installeerden de updates zodra dat mogelijk was.

Ondertussen bleven onze tijdelijke beveiligingsmaatregelen actief.

Wanneer waren alle servers bijgewerkt?

Sinds donderdag 22 oktober om 03:32 zijn alle betrokken servers volledig bijgewerkt.

Daarna hebben we de tijdelijke maatregelen teruggedraaid. OPcache staat weer aan, de tijdelijke uploadlimiet is vervallen en de uploadvoortgangsfunctie is opnieuw ingeschakeld.

Wat heb je als klant hiervan gemerkt?

Ons doel was om websites bereikbaar te houden en de impact op dagelijkse werkzaamheden zoveel mogelijk te beperken.

Dat is gelukt wat betreft het voorkomen van een preventieve uitschakeling van websites. Wel konden de tijdelijke beveiligingsmaatregelen invloed hebben op bepaalde functies.

Mogelijk heb je het volgende gemerkt:

• Een tijdelijk tragere website: doordat OPcache was uitgeschakeld, moest PHP meer werk uitvoeren bij het verwerken van verzoeken.
• Beperkingen bij grotere uploads: bestanden boven de tijdelijke limiet konden niet via de gebruikelijke webinterface worden geüpload. Uploaden via FTP of SFTP bleef mogelijk.
• Een incidentele 403 melding: bepaalde verzoeken konden door onze beveiligingsregels worden tegengehouden, ook wanneer het om een legitieme actie ging.

Deze tijdelijke beperkingen zijn inmiddels opgeheven.

Speciaal voor resellers en webbureaus

Beheer je meerdere websites voor klanten? Dan heeft een beveiligingsincident niet alleen technische gevolgen. Je moet ook kunnen uitleggen wat er speelt, of websites bereikbaar blijven en welke acties eventueel nodig zijn.

Onze aanpak betekende concreet dat:

• Je klantwebsites niet preventief offline werden gehaald.
• Wij de beveiligingsmaatregelen centraal uitvoerden, zonder dat je iedere website afzonderlijk hoefde aan te passen.
• Ook oudere PHP versies werden meegenomen in de beveiligingsupdates.
• Je via onze statusupdates kon volgen welke maatregelen actief waren en wanneer de definitieve updates werden geïnstalleerd.

Zo kon jij je blijven richten op je klanten, terwijl wij de beveiliging van het hostingplatform verzorgden.

Hoe weet je of jouw PHP versie is bijgewerkt?

Alle PHP versies op onze betrokken servers zijn bijgewerkt voor CVE-2026-109618 en CVE-2026-109619. Ook oudere versies, waaronder PHP 7.4, hebben de beveiligingsfix ontvangen.

Mogelijk zie je in cPanel nog steeds hetzelfde PHP versienummer als vóór de update.

Dat komt doordat leveranciers gebruikmaken van een zogenaamde backport. Hierbij wordt een beveiligingsoplossing toegevoegd aan een bestaande softwareversie zonder het oorspronkelijke versienummer te wijzigen.

Zo kan een website nog PHP 8.4.26 tonen, terwijl de beveiligingsfix al is verwerkt.

Je hoeft daarom niet zelf van PHP versie te wisselen om deze specifieke beveiligingsupdate te ontvangen.

Wil je de installatie controleren? Dan kun je via de PHP informatiepagina de builddatum bekijken (Terminal > typ in ‘php -v’). Voor de betrokken PHP pakketten is een builddatum vanaf 21 oktober 2026 een aanwijzing dat je de bijgewerkte versie gebruikt.

Wat hadden we beter kunnen doen?

Bij een beveiligingsincident telt niet alleen hoe snel je technische maatregelen neemt. Ook duidelijke communicatie is belangrijk.

Daarom willen we transparant zijn over de punten die tijdens dit incident beter konden.

Duidelijker benoemen dat het om een beveiligingsincident ging

Op onze statuspagina werd het incident aanvankelijk aangeduid als gepland onderhoud.

Dat was niet de juiste omschrijving. Een ernstig beveiligingslek verdient een duidelijke aanduiding, zodat je direct begrijpt waarom maatregelen nodig zijn.

Bij toekomstige incidenten willen we vanaf het begin duidelijker communiceren over de aard van het probleem.

Eerder uitleggen waarom PHP versienummers niet veranderden

Door de backports bleven sommige PHP versienummers ongewijzigd. Dat leidde begrijpelijkerwijs tot vragen of de beveiligingsupdates daadwerkelijk waren geïnstalleerd.

We hadden eerder moeten uitleggen hoe deze updates werken en hoe je kunt controleren of een versie is bijgewerkt.

Zorgvuldiger communiceren over de beschikbaarheid van updates

Tijdens de nachtelijke uitrol meldden we dat bepaalde PHP pakketten beschikbaar waren. Later bleek dat deze pakketten voor een andere productlijn van onze leverancier bedoeld waren.

Om 00:10 hebben we dit op onze statuspagina gecorrigeerd.

Voortaan willen we de beschikbaarheid van zulke pakketten eerst zelf verifiëren voordat we hierover communiceren.

Sneller kunnen opschalen bij uitzonderlijke drukte

Door het incident nam het aantal supportvragen sterk toe. Om ons te concentreren op de beveiligingsupdates en urgente vragen, hebben we terugbelverzoeken en migraties tijdelijk gepauzeerd.

Toch duurde het beantwoorden van sommige vragen langer dan je van ons gewend bent.

We bekijken hoe we onze supportcapaciteit bij vergelijkbare situaties sneller kunnen opschalen.

Hoe hebben onze klanten dit ervaren?

Tijdens het beveiligingsincident ontvingen we veel vragen, maar ook mooie reacties van klanten. Vooral de duidelijke communicatie en het feit dat websites online konden blijven, werden gewaardeerd.

Voor ons zijn die reacties belangrijk. Zeker tijdens een beveiligingsincident wil je als webprofessional weten waar je aan toe bent, zodat je ook je eigen klanten goed kunt informeren.

Wat klanten over onze aanpak zeggen

“Hoasted is gewoon top. Snelle service, duidelijke communicatie. Exact wat je wil van een hostingpartij. […] Dit wordt nogmaals duidelijk op dagen als vandaag (PHP vulnerability). Open en transparante communicatie, waar ik als klant volle vertrouwen in heb.”

Ook een webbureau dat websites voor meerdere klanten beheert, liet weten hoe belangrijk de communicatie tijdens het incident was.

“De recente kritieke PHP-kwetsbaarheden waren daar een goed voorbeeld van. Hoasted pakte de situatie voortvarend op en hield ons met regelmatige, duidelijke statusupdates op de hoogte. […] Dank aan het hele team voor de inzet, ook tot in de late uren.”

Deze reacties laten zien dat niet alleen de technische oplossing telt, maar ook hoe we klanten tijdens zo’n incident informeren en begeleiden.

En toen kregen we zelfs een taart

Sommige reacties kwamen op een onverwachte manier binnen. Na de beveiligingsupdates ontvingen we van een klant een taart als bedankje voor onze inzet.

Op het bijgevoegde kaartje stond een toepasselijke regel PHP code:

if ($hosting == 'Hoasted') { $zorgen = null; }

Met daaronder de boodschap:

“Bedankt voor jullie snelle actie rond het PHP-lek. Dit is precies waarom we naar jullie zijn overgestapt.”

Een bijzonder gebaar na een intensieve periode waarin ons team tot diep in de nacht werkte om alle servers bij te werken.

Natuurlijk doen we dit werk niet voor een taart of een mooie review. Maar het is fijn om te merken dat klanten onze inzet en communicatie waarderen.

Bedankt aan iedereen die tijdens het incident met ons meedacht, geduld had en een berichtje stuurde.

Wat betekent dit voor de toekomst?

Dit incident laat zien waarom beveiliging niet alleen draait om het installeren van updates.

Het gaat ook om het snel beoordelen van risico’s, het inzetten van tijdelijke beschermingsmaatregelen, het volgen van ontwikkelingen bij softwareleveranciers en het helder informeren van klanten.

Bij Hoasted verzorgen we de beveiliging en het onderhoud van het hostingplatform centraal. Zo hoef je als klant of reseller niet zelf iedere serverupdate te volgen of uit te voeren.

Tegelijkertijd blijven we kritisch kijken naar onze eigen werkwijze. De ervaringen van dit incident gebruiken we om onze technische procedures en communicatie verder te verbeteren.

Moet je zelf nog iets doen?

Voor deze specifieke PHP kwetsbaarheden hoef je niets meer te doen. De beveiligingsupdates zijn op onze servers geïnstalleerd.

Wel adviseren we om regelmatig te controleren of je websites een ondersteunde PHP versie gebruiken.

Gebruik je nog PHP 8.1 of ouder? Dan is het verstandig om een overstap naar PHP 8.3 of nieuwer te plannen. Oudere PHP versies ontvangen geen reguliere beveiligingsupdates meer vanuit het officiële PHP project.

Wij hebben de fixes voor dit incident ook op oudere versies beschikbaar gemaakt, maar dat betekent niet dat deze versies voor onbepaalde tijd veilig blijven.

Via cPanel kun je zelf de PHP versie van je website aanpassen. Test een nieuwe versie bij voorkeur eerst in een stagingomgeving, zodat je eventuele compatibiliteitsproblemen kunt oplossen voordat je de wijziging op je live website doorvoert.

Heb je vragen over de beveiligingsupdate of wil je hulp bij het upgraden van PHP? Neem dan contact op met onze Nederlandstalige support via een supportticket.

Tot slot

Van de eerste aankondiging op dinsdagavond tot de laatste beveiligingsupdate op donderdagochtend heeft ons team gewerkt aan het beschermen van websites en het informeren van klanten.

We zijn blij dat we websites gedurende het incident beschikbaar konden houden zonder ze preventief offline te hoeven halen.

Ook waarderen we de reacties, vragen en het geduld van onze klanten. Die feedback helpt ons om onze dienstverlening verder te verbeteren.

Want bij een beveiligingsincident wil je kunnen vertrouwen op een hostingprovider die snel handelt, duidelijk communiceert en verantwoordelijkheid neemt.