PHP2Shell: wat je nu moet doen met je WordPress- of Laravel-site

Bijgewerkt 21 oktober 2026, 16:30 uur: de fix is uit. Update naar PHP 8.2.35, 8.3.36, 8.4.27 of 8.5.12. De commando's staan bij stap 3.

Op 20 oktober lekten twee kritieke beveiligingslekken in PHP uit, voordat er een fix klaar was. Ze heten PHP2Shell en hebben de nummers CVE-2026-109618 en CVE-2026-109619. Het securityteam van PHP zelf geeft ze een 9,2 op 10. Een aanvaller kan met één speciaal verzoek aan je website eigen code op je server uitvoeren, zonder wachtwoord. De eerste aanvallen zijn al gezien. De Tweede Kamer, het Nationaal Cyber Security Centrum en Tweakers haalden hun sites uit voorzorg offline.

Draait je website op PHP, dan gaat dit over jou. Dat geldt voor bijna elke WordPress- en WooCommerce-site, elke Laravel-app, en voor Magento, Shopware en Drupal. Dit is wat je doet, in deze volgorde.

Geen tijd, of geen developer bij de hand? Wij patchen je server vandaag nog: PHP updaten, dichtzetten wat niet open hoort te staan, controleren op een inbraak en een kort verslag. Vraag spoedhulp aan →

Wat er aan de hand is, in gewone taal

De lekken zitten in PHP zelf, in hoe het een webverzoek afhandelt: het ene treedt op als PHP geen geheugen meer heeft terwijl het een verzoek nog aan het inlezen is, het andere als gegevens van één verzoek blijven hangen in het volgende. Beide gebeuren voordat de code van je website draait. Daarom helpt het niet om WordPress of plugins te updaten. Elke opzet die webpagina's serveert is kwetsbaar: mod_php (het grootste risico), PHP-FPM, php-cgi, FrankenPHP en LiteSpeed. PHP ondersteunt alleen 8.2 en nieuwer; voor 8.1 en ouder heeft het PHP-team backport-patches gepubliceerd, geen nieuwe versies.

Jouw situatie	Wat je doet	Hoe dringend
Gedeelde of beheerde hosting (de meeste WordPress-sites)	Kijk op de statuspagina van je host; vraag wanneer ze patchen en welke PHP-versie je draait	Vandaag
Eigen server, VPS of cloudserver	Installeer de PHP-update zodra hij er is; bescherm de server tot die tijd (zie hieronder)	Vandaag
Docker of containers	Bouw het image opnieuw op de gepatchte PHP-basisimage en deploy opnieuw	Vandaag
PHP 8.1 of ouder	Upgrade naar PHP 8.2 of nieuwer; houd de site tot die tijd afgesloten	Vandaag, en plan de upgrade
Webshop of site met klantgegevens die je vandaag niet kunt patchen	Zet hem in onderhoudsmodus of sta alleen paginabezoek toe (GET-verzoeken)	Nu

Stap 1: maak nu een back-up

Maak een volledige back-up van je bestanden en database, en bewaar die ergens anders dan op de server zelf. Gaat er de komende uren iets mis, dan is een schone back-up van vóór die tijd de snelste weg terug.

Stap 2: bescherm de server tot de fix erop staat

Geen van deze stappen lost het lek op, maar ze maken een aanval wel lastiger:

• Gebruik de tijdelijke instellingen van PHP. Zet in php.ini of je FPM-pool (niet in .user.ini of met ini_set()) session.upload_progress.enabled = 0, memory_limit = -1, post_max_size = 8M (32M als je uploads nodig hebt) en upload_max_filesize = 4M. Op PHP 8.5 zet je ook fatal_error_backtraces = 0. Herstart daarna PHP-FPM of je webserver. Volgens PHP zelf verkleint dit het risico, maar maakt het een server niet veilig.
• Sluit de achterdeur. Gebruik je Cloudflare of een ander CDN, laat je server dan alleen verkeer van de IP-adressen van dat CDN accepteren. Hun firewallregels helpen alleen als aanvallers je server niet rechtstreeks kunnen bereiken.
• Blokkeer uploads waar je ze niet nodig hebt. Als je multipart/form-data-verzoeken weigert in nginx of Apache, stopt deze aanval, maar dan werken bestandsuploads en sommige formulieren en checkouts ook niet meer. Test dit eerst.
• Haal risicovolle sites offline. Voor een webshop of een site met klantgegevens die je vandaag niet kunt patchen, is een onderhoudspagina veiliger dan online blijven. Je kunt ook alleen GET- en HEAD-verzoeken toestaan, zodat pagina's nog laden.

Installeer geen onofficiële 'fix'-plugins en plak geen codefragmenten van forums. Die kunnen het erger maken.

Stap 3: installeer de PHP-update

De gepatchte versies zijn sinds 21 oktober 2026 beschikbaar:

Je draait	Update naar minstens
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35 (ondersteuning stopt op 31 december 2026, plan dus een upgrade)
PHP 8.1 of ouder	Geen nieuwe versie: upgrade naar 8.2 of nieuwer, of vraag je leverancier om een gepatcht pakket

• Ubuntu of Debian: sudo apt update && sudo apt upgrade, daarna sudo systemctl restart php8.3-fpm (met jouw versie) of sudo systemctl restart apache2 bij mod_php. Distributies verwerken de fix in hun eigen pakketversies, dus het nummer kan afwijken: kijk naar de beveiligingsmelding van je distributie in plaats van naar php -v. Op de ondrej/sury-repository komen de versienummers overeen met de tabel.
• RHEL, AlmaLinux of Rocky: sudo dnf upgrade 'php*', daarna PHP-FPM of Apache herstarten.
• Docker: bouw opnieuw met de nieuwste officiële image, bijvoorbeeld docker build --pull . op php:8.4-fpm, en deploy elke container opnieuw.
• Beheerde of gedeelde hosting: je host installeert de update. Vraag om de datum en de versie te bevestigen, en controleer of je site op 8.2 of nieuwer draait.

Herstart na de update alle PHP-workers: oude workers blijven anders de kwetsbare code draaien. Controleer daarna met php -v op de commandoregel en met een phpinfo()-pagina die je meteen weer verwijdert.

Stap 4: controleer of iemand binnen is geweest

De lekken waren vanaf 20 oktober openbaar, dus een server die online en ongepatcht was, kan al geraakt zijn. Controleer na het patchen:

• Nieuwe of gewijzigde .php-bestanden in uploadmappen: wp-content/uploads bij WordPress, storage/ en public/ bij Laravel.
• Beheerders die je niet kent, in WordPress of in je hostingpaneel.
• Nieuwe cronjobs of geplande taken.
• WordPress-kernbestanden die onlangs zijn gewijzigd, en doorverwijzingen naar sites die je niet kent.

Iets gevonden? Verwijder niet alleen de vreemde bestanden. Zet een schone back-up van vóór 20 oktober terug, patch, en wijzig alle wachtwoorden: beheer, hosting, database, SFTP en API-sleutels. Gebruik je UpdraftCentral, verwijder dan ook de dashboardsleutels: aanvallers gebruiken uitgelekte sleutels om achterdeurtjes te plaatsen. Dat is een apart probleem, dat nu ook speelt.

Na deze week

• Houd PHP op een ondersteunde versie (8.2 of nieuwer) en update het als onderdeel van gewoon onderhoud, niet alleen tijdens een crisis.
• Zorg dat je server alleen webverkeer accepteert op poort 80 en 443. Databases en beheerpoorten horen nooit open te staan voor het hele internet.
• Bewaar dagelijkse back-ups buiten je hostingaccount, en test één keer of terugzetten werkt.
• Schrijf op wie je site host, welke PHP-versie hij draait en wie kan inloggen. Deze week liet zien hoeveel tijd dat scheelt.

Vandaag hulp nodig?

Stuur ons het adres van je website en we beginnen vandaag. Een senior developer kijkt op welke PHP-versie je site draait, installeert de fix of zet de site dicht tot hij gepatcht kan worden, en controleert op een inbraak. Je krijgt een kort verslag van wat we vonden en wat we hebben aangepast. Hostingpartij, bureau of eigen server: we werken met wat je hebt.

Vraag spoedhulp aan → of neem contact op.

Bronnen: Sansec, Patchstack, CERT-EU via The Next Web, NL Times.