PHP2Shell: het PHP-lek en wat je nu moet doen

Het korte antwoord

Draait je website op PHP? Update PHP dan naar 8.5.12, 8.4.27, 8.3.36 of 8.2.35 (of het gepatchte pakket van je Linux-distributie) en herstart het. Heb je managed hosting, vraag dan aan je hostingpartij of dit al is gebeurd. WordPress, plugins of thema’s updaten lost dit niet op: het probleem zit in PHP zelf.

Wat er gebeurde

Op 20 oktober lekten details van twee nog ongepatchte kwetsbaarheden in PHP uit, vóór de geplande gecoördineerde bekendmaking, samen met een exploittool met de naam PHP2Shell. Het PHP-securityteam kondigde een nood-release aan voor woensdag 21 oktober om 14.00 uur UTC.

In de uren voor de fix gingen verschillende organisaties uit voorzorg offline. In Nederland waren dat onder meer Tweakers, de Tweede Kamer en het NCSC, en volgens de NOS ook DigiD en MijnOverheid. Cloudflare meldde vroege aanvallen op PHP-sites te zien en zette firewallregels in. Andere securitybedrijven zagen op dat moment wel scans, maar nog geen bevestigde inbraken.

De gepatchte versies kwamen volgens planning uit. De officiële advisories staan op php.net en GitHub (zie de bronnen onderaan).

Wat PHP2Shell is en waar het misgaat

PHP2Shell is de naam van de gelekte exploit, niet van één bug. Het gaat om twee losse kwetsbaarheden in de PHP-engine. Beide krijgen de beoordeling Kritiek (CVSS v4.0 9.2) en beide kunnen leiden tot remote code execution: een aanvaller laat de server opdrachten naar keuze uitvoeren, met de rechten van de webserver.

CVE-2026-109618: geheugenfouten tijdens een verzoek

Als PHP geen geheugen meer heeft, springt het uit wat het op dat moment doet. Volgens de advisory kan dat gebeuren terwijl de gegevens van een verzoek pas half zijn opgebouwd, waarna de opruimstap die kapotte gegevens als geldig behandelt. Een aanvaller kan dat geheugentekort uitlokken met een speciaal gemaakt multipart-verzoek (het formaat van formulieren en uploads) dat onder de uploadlimiet van PHP blijft, maar veel meer geheugen kost om te verwerken. Op Apache met mod_php liet het PHP-team volledige remote code execution via HTTP zien met standaardinstellingen, nog voordat er applicatiecode draait.

CVE-2026-109619: restanten van een eerder verzoek

PHP-workers verwerken veel verzoeken achter elkaar. Door dit lek blijft interne informatie van het ene verzoek bestaan nadat het geheugen al is vrijgegeven, zodat een later verzoek op dezelfde worker die kan gebruiken voordat PHP hem opruimt. Dit heet een use-after-free. De advisory bevestigt twee manieren om er te komen: de voortgangsweergave van sessie-uploads en vroege configuratiewaarschuwingen (INI).

Simpel gezegd: de fout zit niet in de code, het thema of de plugins van je website. Hij zit in de laag daaronder, waar ze allemaal op draaien.

Wie risico loopt

Elke server die met PHP webpagina’s serveert op een versie ouder dan de gepatchte releases. Daaronder vallen:

• WordPress, WooCommerce, Drupal, Joomla, Magento, Laravel en andere PHP-applicaties
• Staging- en testomgevingen, oude subdomeinen en vergeten installaties
• Hostingpanelen en apparaten met hun eigen PHP, zoals cPanel en Plesk

Hoe groot het risico is, hangt af van hoe PHP op de server draait:

Sites die helemaal geen PHP gebruiken, zoals sites gebouwd met Framer, Astro of Next.js, zijn niet kwetsbaar voor deze twee lekken.

Wat je nu moet doen

1. 01Zoek uit op welke PHP-versie je site draait. Meestal staat dat in je hostingdashboard, of vraag het aan je hostingpartij. Developers kunnen php -v op de server uitvoeren.
2. 02Update PHP naar 8.5.12, 8.4.27, 8.3.36 of 8.2.35, of installeer het gepatchte pakket van je Linux-distributie. Distributies en leveranciers van langdurige ondersteuning kregen de patches vooraf.
3. 03Herstart PHP (PHP-FPM of Apache), zodat elke worker de nieuwe versie gebruikt.
4. 04Controleer elke installatie, niet alleen de hoofdsite: staging, oude subdomeinen, interne tools en alles met een eigen PHP-versie.
5. 05Heb je managed hosting, vraag je hostingpartij dan wanneer PHP is bijgewerkt. Hosts patchen op serverniveau, dus meestal kun je het niet zelf doen.
6. 06Draai je op PHP 8.1 of ouder, dan is er geen officiële fix. Vraag je host of leverancier naar backports en plan een upgrade. PHP 8.2 krijgt nog securityfixes tot 31 december 2026.

Kun je vandaag niet updaten? Tijdelijke maatregelen

De PHP-advisories noemen een paar instellingen die de bekende aanvalsroutes moeilijker maken. Ze verkleinen het risico, maar maken een server niet veilig, en sommige breken uploads of voortgangsbalken. Test ze eerst en zie ze als overbrugging tot de update.

• Zet session.upload_progress.enabled op 0 en herstart alle PHP-workers.
• Zet op PHP 8.5 ook fatal_error_backtraces op 0.
• Houd post_max_size laag (bijvoorbeeld 8M als de site geen grote uploads ontvangt) en blokkeer multipart-verzoeken op de webserver voor adressen die geen formulieren of uploads verwerken.
• De advisory noemt ook memory_limit op -1 voor servers die nog niet kunnen updaten. Doe dit alleen samen met je host of developer: het haalt de eigen geheugenlimiet van PHP weg.
• Achter Cloudflare blokkeren de beheerde firewallregels bekende exploitpatronen, maar alleen als je server uitsluitend verkeer van Cloudflare accepteert.

Voor een site met een hoog risico die niet snel gepatcht kan worden, is een tijdelijke onderhoudspagina een redelijke keuze. Dat deden ook verschillende Nederlandse organisaties.

Zo zie je of je site is getroffen

Er zijn nog geen officiële indicators of compromise. Securitybedrijven verwachten dat een geslaagde aanval zichtbaar wordt doordat het PHP-proces andere programma’s start. Signalen om op te letten:

• PHP- of webserverprocessen (php-fpm, php-cgi, apache2, httpd) die shells, scripts of downloadtools starten
• Nieuwe of gewijzigde PHP-bestanden in de webroot die niemand heeft geüpload, zoals webshells
• Nieuwe cronjobs, geplande taken of beheerdersaccounts
• Uitgaande verbindingen vanaf de webserver die je niet kunt verklaren

Vermoed je een inbraak, haal de server dan van het internet, bewaar de logs van de webserver en PHP, en schakel hulp in voordat je gaat opruimen. Een PHP-update dicht het lek, maar verwijdert niets wat een aanvaller al heeft achtergelaten.

Waar het echte risico zit

Drie dingen maken PHP2Shell ernstiger dan een gemiddelde pluginbug:

• Geen login nodig. De aanval werkt met een gewoon webverzoek. Op mod_php gebeurt dat nog vóór je applicatiecode, dus securityplugins en CMS-instellingen helpen niet.
• Toegang tot de server als webgebruiker. De code draait met de rechten van de webserver, die meestal configuratiebestanden met databasewachtwoorden kan lezen en daarmee ook klantgegevens.
• Oude PHP-versies blijven open. PHP 8.1 en ouder krijgen geen officiële updates meer, en veel publieke servers draaien er nog op.

Vergeten installaties zijn vaak het zwakste punt: een oude campagnesite, een stagingkopie of een tool die niemand meer onderhoudt, op dezelfde server als de hoofdsite.

Zijn sites van Visinex getroffen?

Nee. De sites die wij bouwen draaien op Framer, Astro of Next.js. Geen daarvan gebruikt PHP, dus deze twee kwetsbaarheden zijn er niet op van toepassing. Weet je niet waar je eigen site op draait? Stuur ons een bericht, dan kijken we met je mee.

Veelgestelde vragen

Bronnen: PHP-securityreleases, advisory CVE-2026-109618, advisory CVE-2026-109619, Sansec, Huntress en Patchstack. Geschreven op 21 oktober 2026; details kunnen nog veranderen.