PHP2Shell: is jouw website kwetsbaar en wat moet je nu doen?

Wat is PHP2Shell?

PHP is de programmeertaal waarop het grootste deel van het web draait. WordPress, WooCommerce, Joomla, Drupal en Magento zijn er allemaal in geschreven. PHP2Shell is de naam die beveiligers gaven aan twee fouten in PHP zelf, niet in een plugin of thema. Via een speciaal opgesteld verzoek kan een aanvaller de server code laten uitvoeren, zonder wachtwoord en zonder dat iemand op een link hoeft te klikken. PHP gaf beide lekken een score van 9,2 op 10.

Het ging snel. De fouten waren in augustus al gemeld bij het PHP-team, dat een gecontroleerde release voorbereidde. Op dinsdag 20 oktober lekten de details uit via een bericht op Hacker News. Het PHP-team vervroegde de release daarop met een dag: op woensdag 21 oktober om 16.00 uur Nederlandse tijd kwamen de gerepareerde versies uit. Volgens beveiligingsbedrijf Sansec zag Cloudflare die ochtend al de eerste aanvalspogingen, dus nog voordat er een patch was.

In Nederland trok het lek veel aandacht. Het NCSC haalde uit voorzorg zijn eigen website offline, en ook verschillende overheidsportalen en nieuwssites gingen tijdelijk uit de lucht of zetten functies uit tot de update erop stond. Een bevestigde inbraak meldde het NCSC in die eerste dagen niet. Beveiligers verwachten inmiddels minder massale aanvallen dan eerst gevreesd, omdat er geen aanval bekend is die op elke server werkt. Dat is geen reden om te wachten: een server zonder update blijft kwetsbaar, en aanvallers hebben alle tijd om te zoeken.

Is jouw website kwetsbaar?

Het korte antwoord: als je website op PHP draait en de server nog niet is bijgewerkt, ja. Het maakt daarbij niet uit hoe goed je WordPress, plugins en thema's bij zijn. Het lek zit een laag dieper, in de software die de server gebruikt om je site te laten werken. WordPress.org heeft dan ook laten weten dat er geen WordPress-update voor komt: die zou niets oplossen.

Of jij zelf iets moet doen, hangt af van wie je server beheert. Bij gedeelde hosting en managed hosting doet je hostingpartij de update; controleer wel of dat ook echt gebeurd is. Heb je een eigen VPS of een server die een bureau ooit voor je heeft ingericht, dan gebeurt er niets tot iemand de update installeert. Sites op een gesloten platform zoals Shopify, Wix of Squarespace beheer je niet op serverniveau; daar regelt het platform dit zelf.

Zo controleer je welke PHP-versie je site gebruikt

In WordPress vind je de versie in het dashboard onder Gereedschap, Sitediagnose (in het Engels: Tools, Site Health). Open het tabblad Info en klap het onderdeel Server open; daar staat de PHP-versie. Heb je geen WordPress, kijk dan in het controlepaneel van je hosting, zoals DirectAdmin, cPanel of Plesk. De PHP-versie staat daar meestal bij de instellingen van je domein.

Vergelijk het nummer met de tabel hieronder. Let op één valkuil: Linux-distributies zoals Debian en Ubuntu repareren lekken soms in hun eigen pakketten zonder het versienummer te verhogen. Een server met een ouder nummer kan dus toch veilig zijn, en een site die volgens het nummer klopt, zegt nog niets over een server die na de update niet is herstart. Twijfel je, vraag je host dan rechtstreeks of de fix voor CVE-2026-109618 en CVE-2026-109619 is geïnstalleerd en PHP daarna opnieuw is gestart.

Zit je op PHP 8.2, plan dan nu al de volgende stap. Die versie krijgt na 31 december 2026 helemaal geen updates meer, ook geen beveiligingsupdates. Bij het volgende lek sta je dan in dezelfde positie als sites op 8.1 nu: zonder officiële fix.

Geeft je server zijn versienummer prijs in de headers, dan toont onze gratis veiligheidscheck welke versie er draait. Dat is meteen een verbeterpunt: als jij het kunt zien, kan een aanvaller het ook, en die weet dan precies welke lekken hij kan proberen.

Wat je nu moet doen

Voor de meeste ondernemers is dit een kwestie van één mail of één blik in het dashboard. Beheer je zelf een server, of is onduidelijk wie dat doet, loop dan deze stappen na. De volgorde is bewust: eerst het gat dichten, dan kijken of er iemand doorheen is gekomen.

Kun je niet direct bijwerken, bijvoorbeeld omdat een oude plugin niet werkt op een nieuwere PHP-versie, dan zijn er tijdelijke maatregelen. Sansec adviseert onder meer de instelling session.upload_progress.enabled uit te zetten en verzoeken van het type multipart/form-data tijdelijk te blokkeren. Dat laatste breekt wel bestandsuploads en soms je checkout, dus test daarna je formulieren en bestelproces. Zie dit als pleister, niet als oplossing: alleen een PHP-update dicht het lek echt.

Draaide je server een tijd zonder update terwijl de lekken al bekend waren? Eén van de twee fouten kan gegevens uit het geheugen van de server laten weglekken, zoals wachtwoorden en API-sleutels. Vervang bij twijfel het wachtwoord van je database en de sleutels van koppelingen met bijvoorbeeld je betaalprovider, boekhouding of mailpakket. En kijk of er iets is veranderd wat je niet zelf hebt gedaan.

• Controleer je PHP-versie in WordPress of je hostingpaneel, of mail je host
• Werk bij naar 8.2.35, 8.3.36, 8.4.27 of 8.5.12 of nieuwer
• Herstart PHP-FPM of Apache, anders blijft de oude code draaien
• Zit je op PHP 8.1 of ouder: plan de overstap naar 8.2 of nieuwer
• Zoek naar onbekende bestanden, nieuwe beheerdersaccounts en vreemde geplande taken
• Vervang bij twijfel database-wachtwoorden en API-sleutels
• Zet een recente back-up klaar van vóór 20 oktober

Waarom een WordPress-update hier niets oplost

Een website bestaat uit drie lagen. Bovenop staan je inhoud en je ontwerp. Daaronder zit het CMS met zijn plugins en thema's, zoals WordPress en WooCommerce. En onderin draait de server, met het besturingssysteem, de webserver en PHP. De meeste lekken van de afgelopen jaren zaten in de middelste laag, vooral in plugins. Daarom zijn onderhoudspakketten daar ook op gericht: wekelijkse updates van WordPress en plugins.

PHP2Shell zit in de onderste laag. Wie alleen op de knop Bijwerken in WordPress drukt, laat het gat gewoon openstaan. De vraag die dit lek eigenlijk stelt, is niet hoe veilig WordPress is, maar wie er verantwoordelijk is voor je server. Bij veel mkb-sites is het antwoord: niemand in het bijzonder. De site is ooit gebouwd, de hosting loopt door en niemand kijkt naar de PHP-versie tot er iets misgaat.

Wat dit zegt over het onderhoud van je site

Een goed onderhoudspakket dekt alle drie de lagen, of maakt duidelijk afgesproken wie welke laag doet. Bij een site op gedeelde of managed hosting doet de host de server en het onderhoudspakket de rest. Bij een eigen server moet iemand expliciet de taak hebben om het besturingssysteem en PHP bij te werken. Zet die afspraak op papier, ook als het gewoon een mailtje is.

Hoe je zelf de basis van je beveiliging naloopt, staat in is mijn website veilig. Voor WordPress-sites geven de zeven maatregelen om WordPress te beveiligen de volgorde op effect. Wil je dit niet zelf bijhouden: website-onderhoud van Volstoom kost vanaf €20 per maand en werkt op je eigen hosting, met wekelijkse updates, back-ups vóór elke update en hulp binnen één werkdag. Bij onze managed WordPress hosting vanaf €15 per maand zit het technische serverbeheer in de prijs, dus ook de PHP-versie.