Kritiek PHP-beveiligingslek (PHP2Shell, 21 oktober 2026): is jouw website gepatcht?

Controleren en oplossen

Shared hosting, managed WordPress, VPS of cloud: wie is verantwoordelijk voor het patchen van PHP op je website?

De vraag die we sinds 21 oktober het vaakst hebben gehoord is niet "ben ik kwetsbaar?" maar "wiens taak is dit?". PHP2Shell is niet op te lossen door WordPress, een thema of een plugin bij te werken, omdat de lekken in PHP zelf zitten. Of de fix je site bereikt, hangt af van hoe de site wordt gehost, en het antwoord is minder voor de hand liggend dan het lijkt.

Shared hosting (cPanel, Plesk, DirectAdmin)

De host onderhoudt de PHP-pakketten. Jij kiest welke versie je domein gebruikt.

De provider installeert en werkt de PHP-builds op de server bij. Dat deel kun je aan hen overlaten, al is het verstandig om het te controleren in plaats van aan te nemen. Wat de host niet doet, is de versie veranderen waarop je domein staat ingesteld. Staat de PHP-keuze van je account nog op 7.4 of 8.1, dan bereikt het patchen van de host je niet, omdat er voor die reeksen geen patch bestaat. Jij, of wie de site voor je beheert, moet de keuze omzetten naar een ondersteunde reeks en de site daarna controleren.

Managed WordPress-hosting

De host regelt de runtime, meestal binnen een dag of twee. Jij bevestigt.

Managed WordPress-providers draaien PHP voor je en hebben de fix doorgaans op alle servers uitgerold. Ze tonen de PHP-versie meestal ook in het sitedashboard, dus bevestigen is een kwestie van dertig seconden. Het resterende risico is een site die op jouw verzoek op een oude PHP-versie is vastgezet, vaak omdat een plugin ooit kapotging op PHP 8. Is dat jouw situatie, dan is het pluginprobleem nu een beveiligingsprobleem geworden dat opgelost moet worden.

Onbeheerde VPS of dedicated server

Jij, volledig.

Een onbeheerde server komt met een besturingssysteem en verder niets. Pakketupdates, PHP-herstarts, webserverconfiguratie en monitoring zijn voor jou. Heeft niemand sinds 21 oktober de pakketbeheerder gedraaid, dan is de server ongepatcht. Het praktische minimum is een update van de PHP-pakketten, een herstart van PHP-FPM of Apache, en een controle van de draaiende versie. Automatische beveiligingsupdates zijn daarna het inschakelen waard.

Managed VPS of beheercontract

De provider, binnen de reikwijdte van het contract. Lees het contract.

"Managed" loopt uiteen van "we bewaken de beschikbaarheid" tot "we patchen alles binnen 24 uur". Vraag of beveiligingsupdates van het besturingssysteem zijn inbegrepen, of PHP eronder valt, en of herstarts van services na updates erbij horen. Een gedateerde bevestiging voor PHP2Shell is een redelijke vraag.

Platformhosting (Laravel Cloud, met Forge ingerichte servers, platformen in de stijl van Heroku of Vercel)

Het hangt ervan af waar het PHP-binaire bestand staat.

  • Op een platform dat de PHP-runtime voor je draait, patcht het platform die; jouw taak is controleren dat de uitgerolde applicatie op de nieuwe runtime is herstart.
  • Bij een inrichtingstool zoals Laravel Forge is de server van jou: de tool installeert PHP, maar doorlopende pakketupdates en herstarts zijn jouw verantwoordelijkheid, tenzij je automatische updates hebt ingeschakeld.

Containers (Docker, Kubernetes)

Wie de image beheert.

De officiële php-images zijn opnieuw gebouwd met de gepatchte releases; images die uitgaan van een distributiebasis en PHP uit pakketten installeren, krijgen de fix van de leverancier bij een nieuwe build. In productie verandert niets totdat de image opnieuw is gebouwd en de containers opnieuw zijn aangemaakt. Heeft een bureau je deploypipeline gebouwd, bevestig dan dat er een nieuwe build is geweest, niet alleen een code-deploy.

Door een bureau gebouwde sites

Hier zitten de meeste gaten.

Een site die twee jaar geleden door een bureau is gebouwd, op een account dat de klant betaalt, heeft vaak niemand die actief verantwoordelijk is voor de runtime. Het bureau neemt aan dat de host patcht; de host patcht zijn pakketten maar laat de versiekeuze met rust; de klant neemt aan dat het bureau erbovenop zit. Iedereen heeft deels gelijk en de site blijft op PHP 7.4 staan.

Heb je zo'n site, dan is de snelste oplossing één e-mail aan het bureau en de host met elk één vraag: "Welke PHP-versie draait mijn site vandaag, en is dat 8.2.35, 8.3.36, 8.4.27 of 8.5.12 of een pakket met de teruggeporteerde fix?"

De drie gaten, samengevat

  1. Versiekeuzes. Hosts patchen reeksen; ze veranderen niet de reeks die jouw domein gebruikt.
  2. Herstarts. Pakketten worden geïnstalleerd, processen niet herstart, oude code blijft draaien.
  3. Eigenaarschap. Niemand heeft vastgelegd wie de runtime onderhoudt.

De eerste twee kun je vandaag controleren. De derde is een beslissing: benoem de persoon of het bedrijf dat verantwoordelijk is voor de runtime en leg het schriftelijk vast, zodat het volgende advies niet hetzelfde gesprek opnieuw start.

Worden wij die partij, stuur dan je websiteadres en hostingprovider en we beginnen met een versiecheck.

ZET JE VOLGENDE STAP

Klaar om je bedrijf
vooruit te helpen?

Vertel ons waar je naartoe wilt. We helpen je de website, applicatie of integratie vorm te geven om te beginnen.

Laten we het over je project hebben
Chat via WhatsApp