Kritiek, en al misbruikt
Beide lekken scoren 9,2 op de CVSS v4-schaal. Een aanvaller kan zonder account code uitvoeren met de rechten van de webserver. Securityonderzoekers zien sinds 21 oktober aanvallen in het wild.
Veilig vanaf deze versies
PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35, of nieuwer. Na de update moeten alle PHP-processen herstarten, anders draait de oude code door.
PHP 8.1 en ouder: geen update
Het PHP-project brengt voor 8.1, 8.0 en 7.4 alleen broncode-patches uit, geen kant-en-klare versies. Voor 7.3 en ouder komt helemaal niets.
Uw CMS bijwerken helpt niet
Het lek zit in PHP zelf, niet in Drupal of WordPress. Een module- of core-update lost het niet op. De PHP-versie op de server moet omhoog.
Tijdlijn, bijgewerkt 26 oktober 2026
- 0120 oktober: details uitgelekt
De details lekten twee dagen vóór de geplande bekendmaking uit. Het PHP-project kondigde dezelfde dag een noodrelease aan.
- 0221 oktober: patches uit
PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35 verschijnen. Dezelfde dag melden onderzoekers de eerste aanvallen.
- 0323 oktober: aanvullend advies
PHP adviseert session.upload_progress.enabled op 0 te zetten tot de volgende release, vanwege een verwant probleem (CVE-2026-115560).
- 0426 oktober: stand van zaken
Updates zijn er voor PHP 8.2 tot en met 8.5. Voor 8.1 en ouder alleen broncode-patches. Wij werken deze pagina bij zodra er nieuws is.
Patchen volstaat, of het is tijd om te migreren
- Geen officiële update van het PHP-project
- Alleen broncode-patches of een betaalde LTS-leverancier
- Een nieuwere PHP-versie breekt vaak het CMS of de modules
- Na dit lek komt het volgende, en dan staat u weer bloot
- Structureel: migreren naar Drupal 11, dat PHP 8.3 of hoger vereist
- Updaten naar 8.5.12, 8.4.27, 8.3.36 of 8.2.35
- Alle PHP-processen en webservers herstarten
- De versie controleren in het Drupal-statusrapport
- PHP 8.2 is op 31 december 2026 end of life: plan 8.3 of hoger
- Daarna bent u voor dit lek klaar
Wat is PHP2Shell?
PHP2Shell is de naam voor twee kritieke lekken in PHP zelf: CVE-2026-109618 en CVE-2026-109619. Bij beide kan een aanvaller via een gewoon webverzoek, zonder in te loggen, code uitvoeren op de server. Het PHP-project bracht op 21 oktober 2026 een noodupdate uit.
Is mijn Drupal-site kwetsbaar?
Dat hangt af van de PHP-versie op de server, niet van uw Drupal-versie. Draait de server een PHP-versie van vóór 8.5.12, 8.4.27, 8.3.36 of 8.2.35, dan bent u kwetsbaar. Het risico is het grootst bij Apache met mod_php, omdat de aanval daar slaagt voordat Drupal zelf ook maar één regel code draait.
Hoe controleer ik welke PHP-versie mijn site draait?
In Drupal staat de PHP-versie in het statusrapport onder Rapporten, op /admin/reports/status. Op de server zelf geeft php -v de versie, maar die kan afwijken van wat de webserver gebruikt. Bij twijfel: vraag het uw hostingpartij, of stuur ons uw domein.
Kan ik het oplossen met een instelling?
Niet volledig. Het PHP-project schrijft letterlijk dat geen enkele configuratiewijziging de lekken helemaal dicht. session.upload_progress.enabled op 0 zetten en alle PHP-processen herstarten verkleint het risico tot u kunt updaten. De enige echte oplossing is de update.
Mijn hoster doet de updates. Ben ik dan veilig?
Vaak wel, maar controleer het. Grote hostingpartijen en Linux-distributies kregen de patches vooraf. Vraag uw hoster om bevestiging dat uw site op een gepatchte versie draait. Kunt u bij uw pakket zelf een PHP-versie kiezen, kies dan 8.3 of hoger.
Onze site draait op PHP 7.4 en kan niet zomaar omhoog. Wat nu?
Op korte termijn: een LTS-leverancier of een eigen build met de broncode-patches van het PHP-project, en de site zo veel mogelijk afschermen. Structureel: dit is precies waarom oude Drupal 7-sites een risico zijn. Een migratie naar Drupal 11 brengt u op PHP 8.3 of hoger, een versie die wél updates krijgt.