Kritieke PHP-kwetsbaarheden: wat WordPress-site-eigenaren moeten weten

English version: Critical PHP Vulnerabilities: What WordPress Site Owners Need to Know

PHP heeft op 21 oktober 2026 patches uitgebracht voor twee kritieke beveiligingslekken. Het bijwerken van WordPress of plugins lost deze problemen niet op. Lees hoe u kunt controleren of uw hostingomgeving getroffen is en welke stappen u moet ondernemen.

In het kort: wat er gebeurde

Op 21 oktober 2026 heeft het PHP-project patches uitgebracht voor twee kritieke kwetsbaarheden in de PHP-runtime, CVE-2026-109618 en CVE-2026-109619, beide met een score van 9,2 volgens CVSS v4.0. Onder bepaalde omstandigheden stellen deze kwetsbaarheden een niet-geauthenticeerde aanvaller in staat om code uit te voeren op de webserver. Dit zijn kwetsbaarheden in PHP zelf, niet in de WordPress-kern, thema's of plugins, dus de oplossing moet afkomstig zijn van een gepatchte PHP-build die op de server is geïnstalleerd.

Aanbevolen actie: Vraag uw hostingprovider te bevestigen dat de PHP-versie die uw site host, is gepatcht tegen beide beveiligingslekken. Als u de server zelf beheert, installeer dan een gepatcht PHP-pakket en herstart PHP.

De beveiligingswaarschuwingen van het PHP-project noemen deze kwetsbaarheden RCE via OOM-corruptie (CVE-2026-109618) en RCE via verouderde globale status (CVE-2026-109619). In beide gevallen kan een verzoek dat op het verkeerde moment mislukt, interne gegevens in een ongeldige staat achterlaten die PHP later gebruikt.

Een succesvolle aanval voert code uit met de rechten van het account waaronder PHP draait. Afhankelijk van de serverconfiguratie kan een aanvaller hierdoor wp-config.php en de daarin opgenomen databasegegevens lezen, toegang krijgen tot de database of deze wijzigen, of de bestanden en inhoud van de website aanpassen. Een gecompromitteerde PHP-worker geeft de aanvaller niet automatisch root-toegang tot de server.

Exploitatiestatus (per 21 oktober 2026)

De PHP Foundation verklaarde dat haar beveiligingsteam geen functionele exploit had gevonden in de proof-of-concept (PoC)-code die vóór de release verscheen, maar dat de PoC-ontwikkeling was versneld. Op 21 oktober meldde Cloudflare, dat de kwetsbaarheden aanduidt als "php2shell", dat het aanvalsverkeer gericht op haar klanten had waargenomen en dat aanvallers hun payloads aanpasten om te proberen de beveiliging te omzeilen. Geen van beide bronnen meldt een bevestigde succesvolle inbreuk. Aanvalsverkeer laat zien dat aanvallers actief bezig zijn, maar dat bewijst op zichzelf niet dat er daadwerkelijk een site is gehackt. We zullen dit gedeelte bijwerken naarmate de situatie zich ontwikkelt.

Wie wordt er mogelijk door getroffen?

Potentieel kan elke website die draait op een niet-gepatchte PHP-build getroffen worden, ongeacht welke versies van WordPress, thema's en plug-ins er gebruikt worden. Het advies van het PHP-project is van toepassing op alle PHP-installaties die webverzoeken verwerken, waaronder PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed.

Het PHP-project acht het risico het grootst voor mod_php, waar een kwetsbaarheid is aangetoond die kan worden geactiveerd door een niet-geauthenticeerd verzoek voordat er applicatiecode wordt uitgevoerd. Dit betekent niet dat andere configuraties veilig zijn. Elke PHP-installatie die webverzoeken verwerkt, heeft deze oplossing nodig.

Hoe controleer je je PHP-versie en patchstatus?

Ga in het WordPress-dashboard naar Tools → Site Health → Info en vouw het gedeelte Server uit. Hier zie je de PHP-versie en de PHP SAPI (server-API) die je website hosten. De meeste hostingcontrolepanelen tonen dezelfde informatie. Als je WP Cerber gebruikt, vind je de PHP-versie en de server-API ook via WP Cerber → Tools → Diagnostic .

De volgende upstream-releases van het PHP-project bevatten de correcties:

PHP-tak	Upstream vaste release
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35
8.1, 8.0	Geen officiële release beschikbaar. Neem contact op met uw leverancier voor een gepatchte versie of upgrade.
7.4	Geen officiële release. Er bestaan wel aangepaste versies van leveranciers, bijvoorbeeld Ubuntu 20.04 LTS met Ubuntu Pro (7.4.3-4ubuntu2.29+esm5) en, op systemen die al gebruikmaken van de Remi-repository, Remi 7.4.33-31 (RHEL 8, 9, 10 en compatibel). Controleer uw leverancier of voer een upgrade uit.

Belangrijk: dit zijn upstream-versies, geen universele minimumversietest. Linux-distributies en commerciële LTS-leveranciers (Long-Term Support) kunnen de fixes terugporteren naar builds die een eerder versienummer behouden, inclusief builds van de ondersteunde 8.2-, 8.3- en 8.4-branches. Ubuntu 24.04 LTS onderhoudt bijvoorbeeld zijn PHP 8.3-pakketten onder een op 8.3.6 gebaseerde versieaanduiding en levert beide fixes in pakketversie 8.3.6-0ubuntu0.24.04.13. Site Health kan op zichzelf niet vaststellen of een build van een leverancier beide fixes bevat. Controleer het beveiligingsadvies of de changelog van het pakket van de leverancier, of vraag het na bij uw hostingprovider. Stap niet over naar een PHP-pakketrepository van een derde partij alleen omdat uw versienummer lager is dan de upstream-release met de fixes.

PHP 7.4, 8.0 en 8.1. Gepatchte builds van deze branches, gebaseerd op de backports van de PHP-broncode, verhelpen beide kwetsbaarheden met een minimale oplossing voor versies die niet langer worden ondersteund. Deze oplossing is minder uitgebreid dan de volledige fix die in versie 8.2 en later is uitgebracht. Met deze oplossing wordt een PHP-proces dat geen geheugen meer heeft, onmiddellijk beëindigd. Hierdoor kan een website die de geheugenlimiet overschrijdt een algemene serverfout weergeven in plaats van het kritieke WordPress-foutscherm. Op dergelijke builds kan Site Health hetzelfde versienummer weergeven vóór en na de update. Controleer daarom de oplossing bij uw hostingprovider of in de changelog van het pakket. Upgraden naar een ondersteunde branch blijft de aanbeveling.

De ondersteuning voor PHP 8.2 eindigt binnenkort. De beveiligingsondersteuning van het PHP-project voor PHP 8.2 eindigt op 31 december 2026. Als u upgradet van PHP 7.4, 8.0 of 8.1, kies dan voor PHP 8.3 of hoger, maak eerst een back-up van uw website en controleer of uw thema en plug-ins compatibel zijn. U kunt ook uw hostingprovider vragen om een gepatchte versie van uw huidige branch.

Waarom de oplossing op de server moet worden toegepast

De kwetsbare code maakt deel uit van de PHP-runtime die WordPress uitvoert, en niet van WordPress zelf.

Het bijwerken van WordPress verhelpt deze PHP-kwetsbaarheden niet. Het bijwerken van de WordPress-kern, thema's of plug-ins verandert niets aan de PHP-runtime.

Beveiligingsplugins kunnen de runtime niet repareren. Sommige aanvalspaden kunnen worden uitgevoerd voordat WordPress laadt, waardoor geen enkele plugin de kans krijgt om het verzoek te inspecteren. Webapplicatiefirewallregels (WAF-regels) op hosting- of netwerkniveau kunnen bepaalde aanvalspaden beperken, maar ze zijn geen volledige vervanging voor het installeren van patches.

Instellingen die binnen de site zelf worden gewijzigd, bieden geen betrouwbare oplossing. Het PHP-project waarschuwt ervoor om niet te vertrouwen op ini_set() of FPM .user.ini -bestanden om de configuratiemaatregelen toe te passen, en hetzelfde geldt voor PHP-instellingen die worden gewijzigd in wp-config.php of door een plugin. Zelfs de maatregelen op serverniveau die in het advies worden beschreven, verminderen slechts de blootstelling aan specifieke aanvalspaden en maken een installatie niet veilig.

Een belangrijke mededeling voor WP Cerber-gebruikers: WP Cerber draait binnen WordPress. Het kan PHP niet patchen en kan geen verzoek inspecteren dat een van deze kwetsbaarheden activeert voordat WordPress laadt. Om diezelfde reden is het mogelijk dat de logbestanden van WP Cerber een dergelijke poging niet registreren. Een logbestand zonder verdachte vermeldingen bewijst dus niet dat de site niet het doelwit was. WP Cerber beschermt WordPress nog steeds op applicatieniveau, maar is geen vervanging voor het bijwerken van PHP.

Wat moet ik nu doen?

Als u de server niet beheert

Dit geldt voor shared hosting en managed hosting, waarbij uw provider verantwoordelijk is voor het onderhoud van de PHP-runtime. Vraag hen te bevestigen dat de PHP-versie die uw website host, oplossingen bevat voor beide beveiligingslekken. U kunt deze vraag zo versturen:

Is de PHP-build die mijn website host, gepatcht tegen CVE-2026-109618 en CVE-2026-109619? Zijn de relevante PHP-workers opnieuw opgestart om de gepatchte build te laden?

Als u een VPS of dedicated server beheert

Update PHP. Installeer de upstream-versie met de patches, of een distributie- of leverancierspakket waarvan het advies of de changelog bevestigt dat het beide oplossingen bevat.

PHP opnieuw opstarten. Start of herlaad PHP-FPM, Apache of elke andere service die PHP voor uw sites uitvoert. Actieve workers blijven de oude binaire versie gebruiken totdat ze opnieuw worden opgestart.

Controleer. Controleer in Site Health of de verwachte PHP-versie nu elke site bedient. Controleer vervolgens afzonderlijk, in het advies van de leverancier of het wijzigingslogboek van het pakket, of het geïnstalleerde pakket beide oplossingen bevat. Site Health toont de actieve versie, maar kan niet bewijzen dat een backport is opgenomen. De opdracht php -v kan een andere PHP-installatie rapporteren dan degene die uw website bedient, dus vertrouw er niet volledig op.

In welke situatie u zich ook bevindt, zorg ervoor dat u een recente back-up hebt die u kunt herstellen. Als u vermoedt dat de site is gehackt voordat PHP werd gepatcht, houd er dan rekening mee dat het updaten van PHP geen malware of backdoors verwijdert. Neem in dat geval eerst contact op met uw hostingprovider, omdat toegang via PHP mogelijk niet beperkt is tot WordPress-bestanden. Voor het opschonen van de WordPress-installatie zelf, raadpleeg onze handleiding Wat te doen als uw WordPress-site is gehackt .

Veelgestelde vragen

Loop mijn computer of browser risico wanneer ik een getroffen website bezoek?

Niet direct. De kwetsbaarheden zitten in PHP op de webserver, niet in de apparaten of browsers van bezoekers. Een website die via deze kwetsbaarheden is gecompromitteerd, kan echter wel worden aangepast om schadelijke inhoud te verspreiden, waardoor bezoekers indirecte risico's lopen.

Moet ik WordPress opnieuw installeren?

Nee, niet om deze kwetsbaarheden aan te pakken. Ze worden verholpen door PHP op de server bij te werken, en het opnieuw installeren van WordPress verandert niets aan PHP. Een herinstallatie kan echter nog steeds onderdeel zijn van het opschonen van een gecompromitteerde website.

Kan ik dit zelf oplossen, zonder hulp van mijn hostingprovider?

Dat hangt ervan af of je de PHP-runtime beheert. Op een VPS of dedicated server kun je de gepatchte pakketten zelf installeren. Bij shared of managed hosting beheert de host de PHP-versie. Veel controlepanelen laten je een site overschakelen naar een andere PHP-versie, maar of die versie ook gepatcht is, hangt nog steeds af van de host.