PHP-kwetsbaarheid: de PHP2Shell-patch en je PHP-versie controleren (WordPress)

PHP2Shell is de naam van twee PHP-kwetsbaarheden (CVE-2026-109618 · CVE-2026-109619) waarvoor op 21 oktober 2026 patches zijn uitgebracht. Het zijn lekken voor het uitvoeren van code op afstand, waardoor zelfs een verzoek zonder inloggen code op de server kan uitvoeren. Controleer dus eerst welke PHP-versie je site gebruikt en werk die bij naar een gepatchte versie. Op een Nginx + Apache-server met WordPress 7.1.3 heb ik de PHP-versie in Sitediagnose gecontroleerd, alleen de php-pakketten bijgewerkt naar de gepatchte versie en daarna opnieuw gecontroleerd.

1️⃣ De PHP-kwetsbaarheid PHP2Shell: hoe de lekken werken en wie er last van heeft

De lekken zitten in de PHP-engine, die het verzoek leest voordat er WordPress-code wordt uitgevoerd. Ze blijven dus bestaan, ook als je plugins en thema's up-to-date houdt, zolang je PHP niet bijwerkt. Volgens de waarschuwing van CERT-EU hebben beide een CVSS-score van 9,2; de technische details zijn openbaar en worden besproken, en er circuleert al vroege proof-of-conceptcode.

CVE-2026-109618 is een lek waarbij het opruimproces half geïnitialiseerde verzoekgegevens als geldige gegevens behandelt wanneer een verzoek de geheugenlimiet (memory_limit) overschrijdt en wordt afgebroken. CVE-2026-109619 is een lek waarbij de toestand van geheugen dat na een fatale fout is vrijgegeven blijft hangen en bij het volgende verzoek van dezelfde worker vóór de initialisatie opnieuw wordt gebruikt.

Volgens de aankondiging van php.net is elke PHP-installatie die webverzoeken verwerkt kwetsbaar, en geldt Apache mod_php als de gevaarlijkste configuratie. Op mod_php is namelijk gedemonstreerd dat één verzoek zonder inloggen de aanval al start voordat er applicatiecode wordt uitgevoerd.

De gecorrigeerde versies zijn 8.2.35, 8.3.36, 8.4.27 en 8.5.12, en alle lagere versies van de reeksen 8.2 tot en met 8.5 zijn kwetsbaar. PHP 8.1 en ouder zijn reeksen die het PHP-project niet meer ondersteunt; daarvoor is er geen officiële gepatchte versie, maar oplossingen die distributies en hostingproviders overnemen (backports).

Toen CISA op 21 oktober zijn melding publiceerde, was er nog geen daadwerkelijk misbruik bevestigd, maar CISA vond het gevaarlijk om systemen ongepatcht te laten en adviseerde direct te patchen, te beginnen met systemen die vanaf internet bereikbaar zijn. CERT-EU concludeerde dezelfde dag in zijn waarschuwing dat de kans groter is geworden dat aanvallers de lekken al misbruiken, nu er proof-of-conceptcode begint te circuleren.

2️⃣ De PHP-versie controleren: Sitediagnose › Informatie › Server

Zelfs als je de lekken kent, weet je pas wat je moet doen als je weet met welke PHP-versie je site draait. Open in het beheerscherm [Tools › Sitediagnose] en klap op het tabblad [Informatie] de sectie [Server] uit: in de regel [PHP versie] staat de PHP-versie die de verzoeken van je site echt verwerkt.

De regel [PHP SAPI] direct onder [PHP versie] laat zien hoe PHP draait; fpm-fcgi betekent een PHP-FPM-configuratie. Hier kijk je alleen naar de twee regels [PHP versie] en [PHP SAPI] in de sectie [Server].

De aanval begint met een verzoek zonder inloggen. In de fase waarin PHP het speciaal geprepareerde verzoek vóór de WordPress-code leest, raakt het verzoek een van de twee lekken, wat leidt tot code-uitvoering op de server. De gecorrigeerde versies blokkeren dit verloop, dus het werk is om de PHP van je site minstens naar een gecorrigeerde versie te brengen.

[php -v] in de terminal toont alleen de versie van de standaard-PHP op de opdrachtregel. Bij configuraties met meerdere PHP-versies op één server, zoals EA-PHP van cPanel of alt-php van CloudLinux, kan die afwijken van de versie die je site gebruikt. Daarom is de waarde [PHP versie] in Sitediagnose de maatstaf.

php -v

PHP 8.3.xx (cli) (built: Jun  3 2025 17:17:57) (NTS gcc x86_64)

3️⃣ Lager dan PHP 8.2: vraag je host naar een backport en vraag er een aan als die er niet is

Staat [PHP versie] in Sitediagnose lager dan 8.2 (7.x, 8.0 of 8.1), dan is er geen officiële gepatchte versie van php.net. Volgens de tabel met ondersteunde versies van php.net (gecontroleerd op 22 oktober 2026) worden alleen de vier reeksen 8.2, 8.3, 8.4 en 8.5 ondersteund, en voor officiële versies 8.1 en ouder verschijnen geen beveiligingspatches.

In plaats daarvan brengen distributies en hostingproviders soms pakketten uit die het versienummer houden en alleen de oplossing overnemen (backports). De pakketten 7.4.33, 8.0.30 en 8.1.34 op een testserver van een managed hostingprovider zijn een voorbeeld. In hun changelog stond de regel [Backported from 8.2.35 — CVE-2026-109618, CVE-2026-109619].

Ook als het versienummer gelijk is, controleer je of de oplossing erin zit door in de changelog van het pakket het CVE-nummer te zoeken. Op Debian en Ubuntu zoek je bijvoorbeeld met [zcat /usr/share/doc/php8.2-cli/changelog.Debian.gz | grep 109618]. Op RPM-systemen is het [rpm -q --changelog php-common | grep 109618]; stem het versienummer in de pakketnaam af op de versie die je site gebruikt.

Zit je onder 8.2, vraag dan eerst je hostingprovider of er een backport is toegepast. Is dat niet zo of kan dat niet worden bevestigd, vraag dan om een upgrade naar een ondersteunde versie (8.2 of hoger). Controleer na de upgrade opnieuw de waarde [PHP versie] in Sitediagnose.

CISA adviseerde organisaties die 8.1 of ouder gebruiken en niet direct kunnen bijwerken, hun op PHP gebaseerde systemen offline te houden tot ze gepatcht of geüpgraded zijn.

Beheer je de server zelf en gebruik je 8.1 of ouder, dan kun je de backportpakketten van je distributie installeren of de bronpatches voor 7.4, 8.0 en 8.1 van het PHP-beveiligingsteam toepassen. Toch zijn dit reeksen zonder ondersteuning, dus de echte oplossing is overstappen naar een ondersteunde versie.

4️⃣ PHP 8.2 of hoger: bijwerken naar de gepatchte versie en opnieuw controleren

Zit je op 8.2 of hoger, maar onder de gepatchte versie, werk dan PHP zelf bij. Bij managed en shared hosting voert de provider de patch voor de hele server door. Controleer dus via zijn aankondigingen of support of die is toegepast en welke build er draait, en kijk of [PHP versie] in Sitediagnose is veranderd. Volgens de statuspagina begon Cloudways op 21 oktober om 22:19 UTC met het patchen van alle PHP-versies die het ondersteunt (5.6 tot en met 8.4). Op 22 oktober om 10:11 UTC meldde Cloudways dat het klaar was.

Op een server die je zelf beheert, werk je bij met pakketten uit de repository van je distributie of van een LTS-leverancier, zoals de aankondiging van php.net aangeeft. Bekijk vóór de update in een voorbeeld de lijst met pakketten die veranderen, controleer of alleen pakketten die met php beginnen worden bijgewerkt en er geen andere meekomen, en meng het niet met andere updates van het besturingssysteem.

dnf upgrade --assumeno 'php*'

Dependencies resolved.
================================================================================
 Package       Architecture  Version         Repository  Size
================================================================================
Upgrading:
 php           x86_64  8.3.xx-1.…        …       1.9 M
 php-cli       x86_64  8.3.xx-1.…        …       5.6 M
 php-common    x86_64  8.3.xx-1.…        …       1.3 M
 php-fpm       x86_64  8.3.xx-1.…        …       1.9 M
 (regels voor extensiepakketten zoals php-gd · php-intl weggelaten)

Transaction Summary
================================================================================
Upgrade  xx Packages

dnf upgrade 'php*'

Upgraded:
  php-8.3.xx-1.….x86_64
  php-cli-8.3.xx-1.….x86_64
  php-common-8.3.xx-1.….x86_64
  php-fpm-8.3.xx-1.….x86_64
  (regels voor extensiepakketten weggelaten)

Complete!

Bij deze test werden alleen de pakketten die met php beginnen bijgewerkt naar de gepatchte versie, en php-fpm herstartte vanzelf toen de installatie van de pakketten klaar was. De gecorrigeerde versie werkt pas als de php-fpm-workers herstarten, dus voer in een omgeving zonder automatische herstart zelf [systemctl restart php-fpm] uit.

Controleer na de upgrade of [php -v] en de regel [PHP versie] op het tabblad [Informatie] van Sitediagnose allebei minstens de gepatchte versie tonen, en kijk ook naar de status van de php-fpm-dienst en de reactie van de site. Is alleen de waarde op de opdrachtregel veranderd en blijft [PHP versie] gelijk, herstart dan php-fpm en controleer opnieuw.

Klap ook na de update op hetzelfde scherm [Tools › Sitediagnose] op het tabblad [Informatie] de sectie [Server] uit en kijk naar de regel [PHP versie]. Is deze waarde veranderd in de versie waarnaar je hebt bijgewerkt, dan draaien ook de php-fpm-workers op de nieuwe versie.

php -v

PHP 8.3.xx (cli) (built: Oct 19 2026 14:00:34) (NTS gcc x86_64)

systemctl is-active php-fpm

active

curl -s -o /dev/null -w '%{http_code}\n' 'https://example.com/?r=1'

200

Bij pakketten waarvan het versienummer zelf omhooggaat, herken je de patch aan het nieuwe versienummer; bij backportpakketten die het versienummer houden aan het CVE-nummer in de changelog. Deze server hoorde bij de eerste groep: in [rpm -q --changelog php-common] stond geen regel met het CVE-nummer, en ik heb de patch gecontroleerd aan het nieuwe versienummer op de eerste regel van de changelog.

5️⃣ Als je niet meteen kunt bijwerken: de tijdelijke maatregelen van php.net

Voor servers die niet meteen kunnen worden bijgewerkt, noemt php.net de onderstaande instellingen als tijdelijke maatregelen, maar het zegt er duidelijk bij dat ze alleen bepaalde aanvalspaden beperken en een installatie niet veilig maken. Ook staat er dat je de geheugenlimiet niet in plaats daarvan via RLIMIT_AS of RLIMIT_DATA moet instellen, omdat dat juist de kwetsbare mislukte geheugentoewijzingen kan veroorzaken.

php_admin_value is een instelling aan de serverkant die de applicatie niet kan terugzetten. Gebruikers van shared hosting kunnen die daarom vaak niet zelf wijzigen en moeten zich ook dan tot hun hostingprovider wenden. php.net raadt daarnaast aan om ook op het niveau van de webserver of proxy limieten te zetten op de grootte van de request body, het aantal invoervelden, het aantal multipart-delen, het aantal headers en de nestingdiepte.

🔢 FAQ & aanbevolen content

🔗 Aanbevolen content

Beveiliging WP-beveiliging: beveiliging van wp-admin Instellingen die het beheerscherm beschermen door de login-URL te wijzigen, inlogpogingen te beperken en XML-RPC te blokkeren. Bericht lezen →

Beveiliging Beveiligingslekken in wp-config.php Zo voorkom je dat het bestand wp-config.php zichtbaar wordt en versterk je de beveiligingsinstellingen. Beveiliging WordPress XML-RPC Zo herken je xmlrpc.php-aanvallen in de logs, plus drie manieren om het uit te schakelen. Server php-fpm max_children-waarschuwing Een praktijktest die de oorzaak van de waarschuwing in de logs vindt voordat je workers bijzet.

ℹ️ Affiliatemelding
De content van deze site bevat affiliatelinks. Koopt een bezoeker via een van deze links een product of dienst, dan ontvangt deze site een commissie van de verkoper. Het bedrag dat de koper betaalt ^{(bij acties gaat het omlaag ↓)} wordt daardoor niet hoger. De vermelde prijzen, kortingen en voorraad gelden op het moment van schrijven en kunnen afwijken; controleer ze daarom vóór je aankoop bij de verkoper. Producten worden gekozen en beoordeeld volgens onze eigen criteria, en commissies hebben geen invloed op de volgorde of de inhoud van de beoordelingen.