WordPress bijgewerkt, toch kwetsbaar: de PHP2Shell-lekken zitten een laag dieper

Of: waarom drie sloten op je deur niet helpen als het gat in de muur zit

Wie een website op WordPress heeft, kent de reflex: er is een lek, dus je klikt op “bijwerken”. Deze week werkt die reflex niet. De lekken zitten niet in WordPress, niet in een plug-in en niet in je thema. Ze zitten een laag dieper, in PHP, de taal waarin dat allemaal geschreven is. En die laag beheer je meestal niet zelf.

PHP2Shell: wat er aan de hand is

Twee lekken in de fundering

PHP is de programmeertaal waarop WordPress, Joomla, Drupal, PrestaShop en duizenden andere webtoepassingen draaien. Volgens W3Techs gebruikt 69,3 procent van de websites waarvan de servertaal bekend is PHP.

In die taal zaten twee kritieke lekken, CVE-2026-109618 en CVE-2026-109619, die samen PHP2Shell gedoopt werden. Het PHP-project geeft ze allebei een score van 9,2 op 10.¹ In grote lijnen:

• Het eerste lek zit in hoe PHP reageert als het geheugen opraakt. PHP kan dan onderbroken worden terwijl de gegevens van een verzoek nog maar half klaar zijn, en bij het opruimen worden die halve gegevens toch als geldig behandeld.
• Het tweede lek zit in gegevens die een verzoek achterlaat. Die kunnen blijven bestaan nadat het geheugen al vrijgegeven is, en een volgend verzoek kan ze gebruiken voor ze gewist zijn.

Het resultaat is in beide gevallen hetzelfde: een aanvaller kan zonder wachtwoord code uitvoeren op de server. Getroffen zijn volgens het PHP-project alle installaties die webverzoeken verwerken, of dat nu via PHP-FPM, mod_php van Apache, php-cgi, FrankenPHP of LiteSpeed gebeurt, met het grootste risico bij mod_php.

Het belangrijkste detail staat bij Help Net Security: één verzoek zonder aanmelding volstaat, en het lek wordt geraakt voor er ook maar een regel code van je toepassing draait. Je beveiligingsplug-in, je firewall in WordPress, je sterke wachtwoorden: ze komen niet eens aan de beurt. Het PHP-project is er ook duidelijk over: “Er bestaan geen volledige oplossingen zonder update. Bijwerken is de enige veilige keuze.”

Een rommelige week

De bekendmaking verliep niet volgens het boekje.

• 17 oktober: volgens Amazon registreerden zijn lokservers, die aanvallers moeten aantrekken, al een poging tot misbruik. Dat was vier dagen voor de bekendmaking. Hoe de aanvaller aan de details kwam, is niet bekend.
• 20 oktober: het PHP-project kondigt een kritieke update aan voor de volgende dag, 14 uur Universele Tijd. Dezelfde dag lekken details uit op het internet, voor de updates klaar zijn.
• 21 oktober: de updates verschijnen om 13.52 uur, acht minuten vroeger dan gepland. Volgens ITdaily zag Cloudflare die ochtend de eerste aanvallen. Patchstack kreeg volgens The Hacker News meldingen van misbruik van hostingpartners. De Britse beveiligingsautoriteit NCSC raadt aan om systemen die niet meteen bijgewerkt kunnen worden, offline te halen. Beveiligingsonderzoeker Kevin Beaumont noemt het “een van de grootste lekken in jaren”.
• 22 oktober: Palo Alto Networks meldt volgens Help Net Security dat alle versies van PAN-OS en Panorama, de software van zijn firewalls, getroffen zijn, zonder beschikbare oplossing. Het toont hoe diep PHP zit: ook in toestellen waar je het niet verwacht.

Nog een detail dat aansluit bij de verdubbeling van het aantal gemelde lekken: volgens onderzoekers van Wiz hebben de nieuwste AI-modellen “die drempel aanzienlijk verlaagd”, en zo van een fout die al lang bestond een bruikbare aanval gemaakt. Wat vroeger veel werk van een specialist was, gaat nu sneller, zo lijkt het.

In België

Het Centrum voor Cybersecurity België publiceerde een waarschuwing met een titel die weinig ruimte laat: “Patch immediately or take offline!” Het raadt aan om eerst een lijst te maken van alle PHP-installaties, ook die in toestellen van leveranciers, in Windows-toepassingen en in beheerpanelen zoals cPanel en Plesk, en te beginnen met wat vanaf het internet bereikbaar is.

Volgens ITdaily nam DPG Media uit voorzorg meerdere sites offline, en waren ook de sites van de VUB en van enkele ziekenhuizen even onbereikbaar. Het CCB zette volgens ITdaily ook zijn eigen site tijdelijk in onderhoudsmodus. Dat is, eerlijk gezegd, consequent.

Het gat in de muur

Denk aan je website als een appartement in een groot gebouw. WordPress, je thema en je plug-ins zijn je eigen voordeur. Die heb je mooi op slot: drie sloten, een ketting, alles bijgewerkt.

PHP is de muur van het gebouw. En in die muur zit nu een gat, vlak naast je deur. Je kunt nog tien sloten bijzetten, niemand neemt nog de deur.

Bij gedeelde hosting is die muur niet van jou. Ze is van de syndicus: je hostingbedrijf. Jij kunt het gat niet dichtmetselen. Jij kunt wel de syndicus bellen, en vragen wanneer het gebeurt. Heb je een eigen server of VPS, dan ben jij de syndicus, en dan is het gat jouw werk.

En er is een pijnlijk detail. Volgens W3Techs draait 26,9 procent van de PHP-websites nog op PHP 7, en 7,7 procent op PHP 5. Die versies krijgen van het PHP-project al jaren geen updates meer. Het PHP-project publiceerde voor PHP 7.4, 8.0 en 8.1 wel minimale correcties in broncode, voor wie zelf PHP bouwt, maar geen kant-en-klare versies. Voor zulke sites is dit lek het moment waarop een uitgestelde verhuizing dringend wordt.

Kmo-Kristof: Ik heb onze WordPress-site gisteren helemaal bijgewerkt. Alle plug-ins ook.

Security-Sofie: Goed. Welke PHP-versie draait er?

Kmo-Kristof: Geen idee. Is dat een plug-in?

Security-Sofie: Het is waar WordPress op draait. Het lek zit daar.

Kmo-Kristof: Dan werk ik dat ook bij.

Security-Sofie: Dat kun je niet. Dat doet je hostingbedrijf.

Kmo-Kristof: Ik heb gebeld. Ze zeggen dat we op PHP 7.4 draaien.

Security-Sofie: Die versie krijgt sinds eind 2022 geen gewone updates meer.

Kmo-Kristof: Dus we moeten nu ook naar een nieuwere versie. En kijken of onze oude plug-ins dat overleven.

Security-Sofie: Ja.

Kmo-Kristof: Dat klinkt als een tweede probleem.

Security-Sofie: Het is hetzelfde probleem. Je hebt het alleen drie jaar uitgesteld.

In een korte video van Keek op Tech leggen we het in een minuut uit:

Wat je vandaag doet

• Ken je PHP-versie. In WordPress staat ze in het dashboard bij de gezondheid van je site (Site Health), onder het tabblad met informatie over de server. Ook het beheerpaneel van je hostingbedrijf toont ze meestal.
• Gedeelde hosting: vraag het na, schriftelijk. Vraag je hostingbedrijf of PHP bijgewerkt is naar 8.5.12, 8.4.27, 8.3.36 of 8.2.35, of naar een gecorrigeerde versie van de Linux-distributie. Veel hostingbedrijven doen dit centraal, maar een bevestiging is beter dan een vermoeden.
• Eigen server of VPS: werk PHP bij via je distributie en herstart daarna de webserver of PHP-FPM, anders blijft de oude versie draaien. Distributies zoals AlmaLinux publiceerden op 21 oktober al bijgewerkte pakketten.
• Oude PHP-versie: plan de overstap nu. Draait je site op PHP 8.1 of ouder, vraag dan je hostingbedrijf of leverancier naar een gecorrigeerde versie en een planning om over te stappen. Kan je site niet beschermd worden, dan is tijdelijk offline halen, zoals het CCB en het NCSC aanraden, geen overdreven reactie.
• Denk breder dan je website. Een webshop, een intranet, een ticketsysteem, een beheerpaneel of een firewall kunnen ook PHP bevatten. Maak de lijst die het CCB vraagt, en vraag je leveranciers of hun toestellen getroffen zijn.
• Reken niet op een webfirewall alleen. Cloudflare zette regels in voor de bekende aanvallen, ook voor gratis klanten. Dat helpt, maar volgens het PHP-project is bijwerken de enige volledige oplossing.

De muur

De meeste beveiligingsadviezen voor kleine websites gaan over de deur: updates, plug-ins, wachtwoorden. Dat blijft belangrijk. Maar deze week bleek nog eens dat een website op meer lagen rust dan de laag die je in het dashboard ziet.

Je kunt drie sloten op je deur hebben. Als het gat in de muur zit, bel je beter de syndicus.