PHP2Shell: kritiek PHP-lek (CVE-2026-109618) en wat je nu doet

Op 21 oktober 2026 bracht het PHP-team spoedupdates uit voor twee kritieke lekken in PHP zelf, samen bekend als PHP2Shell. Via deze lekken kan een aanvaller zonder in te loggen code uitvoeren op je webserver. Draait je website of webshop op PHP, en dat geldt voor WordPress, WooCommerce, Magento en de meeste andere systemen, update dan vandaag naar PHP 8.5.12, 8.4.27, 8.3.36 of 8.2.35.

Wat is er aan de hand?

Op 20 oktober 2026 kondigde het PHP-beveiligingsteam aan dat er een kritieke update aankwam voor twee lekken, allebei met een CVSS v4.0-score van 9,2 op een schaal van 10. Een dag later, op 21 oktober om 14:00 UTC (16:00 uur Nederlandse tijd), verschenen de gepatchte versies. Inmiddels zijn de technische details en een aanvalstool openbaar.

Het gaat om twee kwetsbaarheden:

• CVE-2026-109618, "RCE via OOM corruption": als PHP tijdens het verwerken van een verzoek zonder geheugen komt te zitten, kan interne verzoekdata half opgebouwd achterblijven. Bij het opruimen behandelt PHP die ongeldige data daarna als geldig.
• CVE-2026-109619, "RCE via stale global state": interne gegevens van een verzoek kunnen blijven bestaan nadat het bijbehorende geheugen al is vrijgegeven. Een volgend verzoek op hetzelfde PHP-proces kan die verouderde gegevens dan gebruiken.

In gewone taal: met een speciaal gemaakt verzoek kan een aanvaller de controle over je webserver overnemen, zonder wachtwoord en zonder dat je website zelf een fout bevat. De naam PHP2Shell verwijst naar een aanvalstool die beide lekken combineert.

Wie loopt risico?

Volgens het officiële advies van PHP loopt elke PHP-installatie die webverzoeken verwerkt risico. Dat geldt voor alle gangbare manieren waarop PHP draait: PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed. Het risico is het grootst bij mod_php. Daar is aangetoond dat een verzoek zonder inloggen de aanval kan starten voordat er ook maar één regel van je website-code draait.

Omdat het lek in PHP zelf zit, maakt het niet uit welk systeem je gebruikt. Beveiligingsbedrijf Sansec meldt dat onderzoekers aanvallen zonder inloggen hebben bevestigd op onder meer:

• WordPress en WooCommerce
• Magento, Shopware en andere webshops
• Joomla en Drupal
• Laravel en Symfony
• Nextcloud, phpMyAdmin, Roundcube (webmail) en MediaWiki

Ook als je eigen website-code helemaal in orde is, ben je dus kwetsbaar zolang de PHP-versie op de server niet is bijgewerkt.

Welke PHP-versies zijn kwetsbaar?

Hier spreken de bronnen elkaar deels tegen. PHP levert oplossingen voor alle ondersteunde versies. Het Europese CERT-EU schrijft dat mogelijk alle versies vanaf PHP 5 geraakt zijn, en Sansec noemt PHP 5.4 en nieuwer. Ga er dus van uit dat elke oudere PHP-versie kwetsbaar is.

Gebruik je PHP-pakketten van een Linux-distributie zoals Debian, Ubuntu of Red Hat, dan kan het versienummer anders zijn dan in de tabel. Volgens PHP hebben distributies en LTS-leveranciers de patches vooraf ontvangen. Controleer in de changelog van je pakket of CVE-2026-109618 en CVE-2026-109619 genoemd worden.

Wordt het lek al misbruikt?

Daarover zijn de signalen nog niet eenduidig. Cloudflare meldde op 21 oktober, nog vóór de officiële release, dat het de eerste aanvallen op PHP-sites zag. Het bedrijf heeft regels in zijn webfirewall (WAF) gezet die alle klanten beschermen, ook die met een gratis abonnement, maar noemt dat zelf een noodoplossing. Andere onderzoekers hadden op dat moment nog geen bevestigd misbruik gezien.

Duidelijk is wel dat de technische details en een aanvalstool inmiddels openbaar zijn. Sansec verwacht daarom dat er op grote schaal geautomatiseerd gescand en aangevallen gaat worden. Wacht dus niet af tot er "echt" iets gebeurt.

Wat moet je nu doen?

1. Breng in kaart waar PHP draait. Denk niet alleen aan je website, maar ook aan je webshop, een intranet, een klantportaal, webmail (Roundcube), Nextcloud, phpMyAdmin en apparaten of Docker-images waar PHP in zit.
2. Controleer de PHP-versie. Bij hosting met Plesk of DirectAdmin zie je de versie in het configuratiescherm van je domein. Op een eigen server gebruik je php -v, maar let op: de webserver kan een andere PHP-versie gebruiken dan de command line.
3. Update PHP.
   • Heb je gedeelde hosting, vraag je hostingpartij dan of de update al is uitgevoerd en laat het schriftelijk bevestigen.
   • Op een eigen server installeer je de bijgewerkte pakketten van je distributie.
   • Gebruik je de populaire Remi-repository op Red Hat-achtige servers? Die had op 21 oktober nog geen update, schrijft PHP. Stap dan over op de pakketten van je distributie of bouw PHP zelf.
   • Bij Docker moet je images opnieuw bouwen met een bijgewerkte basisimage. Alleen de host bijwerken is niet genoeg.
4. Herstart alle PHP-processen. Herstart PHP-FPM en de webserver, zodat er geen oude PHP-processen meer draaien.
5. Controleer of er al is ingebroken. Kijk naar onbekende PHP-bestanden (vooral in uploadmappen), nieuwe beheerders, onbekende cronjobs en vreemde POST-verzoeken in de logs rond 20 en 21 oktober. Is er iets verdachts, wijzig dan wachtwoorden en API-sleutels en zoek de oorzaak uit voordat je verdergaat.

Kun je niet direct updaten?

PHP is duidelijk: alleen een update lost het echt op. Lukt dat niet meteen, dan kun je het risico tijdelijk verkleinen met de maatregelen die PHP zelf adviseert. Ze beschermen tegen bekende aanvalsroutes, maar maken een server níet veilig.

• Zet session.upload_progress.enabled=0 in php.ini of in de PHP-FPM-pool en herstart alle processen. Instellen via ini_set() of .user.ini helpt niet.
• Zet memory_limit=-1 op serverniveau (bijvoorbeeld met php_admin_value), zodat websites het niet kunnen overschrijven.
• Beperk post_max_size: 8M voor sites zonder uploads, 32M als uploads nodig zijn. Houd upload_max_filesize daaronder.
• Op PHP 8.5: zet fatal_error_backtraces=0 en herstart alle processen.
• Stel in je webserver of proxy limieten in voor de grootte van verzoeken en het aantal onderdelen in uploads. Sansec adviseert om uploadverzoeken (multipart/form-data) helemaal te blokkeren waar je site geen uploads nodig heeft.
• Gebruik een webfirewall met regels tegen PHP2Shell, zoals die van Cloudflare.

Kan geen van deze stappen op korte termijn? Dan adviseert CERT-EU om websites die via internet bereikbaar zijn tijdelijk af te schermen totdat de update is uitgevoerd.

Wat betekent dit voor jouw hosting en beheer?

PHP2Shell laat zien hoe belangrijk het is dat iemand de server onder je website actief bijhoudt. Bij veel bedrijven staat de website bij een hostingpartij en gaat iedereen ervan uit dat updates "vanzelf" gebeuren. Vaak klopt dat, maar niet altijd: oudere PHP-versies blijven soms jaren draaien omdat een website of plugin niet compatibel is met een nieuwere versie.

Een paar vragen om jezelf, of je hostingpartij, nu te stellen:

• Op welke PHP-versie draait elke website en webshop van ons?
• Wie is verantwoordelijk voor PHP-updates: de hostingpartij, de webbouwer of wijzelf?
• Hoe snel worden kritieke updates doorgevoerd, en krijgen we daar bericht van?
• Hebben we een recente, geteste backup als het toch misgaat? Lees ook onze backup strategie voor het MKB.

Een lek als dit is precies waarom we in onze cybersecurity checklist voor het MKB updates en patchbeheer bovenaan zetten.

Hulp nodig bij PHP2Shell?

Weet je niet zeker of je website veilig is, of heb je geen tijd om het uit te zoeken? Looman IT controleert voor bedrijven in Eindhoven en omgeving welke PHP-versies er draaien, voert de update uit of zet je hostingpartij aan het werk, en kijkt of er al sporen van een inbraak zijn. Ook bij een oudere website die niet zomaar naar een nieuwe PHP-versie kan, zoeken we samen een veilige route. Neem contact op of bel direct. Bekijk ook wat we doen op het gebied van informatiebeveiliging en websites.

Bronnen

• PHP: Security advisory, Critical remote code execution vulnerabilities (21 oktober 2026)
• CERT-EU: Security Advisory 2026-018, Critical Vulnerabilities in PHP
• NCSC-NL: operationele informatie over de php2shell-kwetsbaarheden
• Sansec: PHP2Shell, Critical PHP RCE
• Cloudflare: bescherming tegen de php2shell-kwetsbaarheid