PHP2Shell: kritieke PHP-lekken CVE-2026-109618 en CVE-2026-109619 uitgelegd

Op 21 oktober 2026 heeft het PHP-project noodupdates uitgebracht voor twee kritieke kwetsbaarheden in de kern van PHP: CVE-2026-109618 en CVE-2026-109619. Samen staan ze bekend als PHP2Shell. Een aanvaller kan er een webserver mee overnemen zonder in te loggen en zonder dat de website zelf een fout bevat. Omdat PHP onder WordPress, Drupal, Joomla, Magento, Nextcloud en talloze andere systemen zit, is de impact groot.

Dit artikel zet op een rij wat er bekend is, voor wie het geldt en wat je als beheerder nu moet doen. Alle feiten komen uit de bronnen die onderaan staan, met voorop de officiële meldingen van het PHP-project.

Wat is er aan de hand?

Beide lekken zijn geheugenfouten (use-after-free) die ontstaan als PHP een verzoek halverwege afbreekt, bijvoorbeeld omdat het geheugen op is of omdat er een fatale fout optreedt.

Bronnen: PHP-advies GHSA-w8hw-w9fx-j79w en PHP-advies GHSA-6wmf-4rv5-p3rp.

De aanval gebruikt vaak een multipart/form-data-verzoek, het formaat van bestandsuploads. PHP verwerkt zo'n verzoek al voordat de code van de website draait. Daarom helpt het niet dat je eigen applicatie netjes geprogrammeerd is: volgens Wiz kan zelfs een simpele "Hello World"-pagina op een kwetsbare PHP-versie geraakt worden.

Wiz beschrijft vier onderliggende bugs onder deze twee CVE-nummers en koppelt ze iets anders aan de nummers dan het PHP-project. Ga voor de indeling uit van de officiële PHP-adviezen. Het advies blijft hoe dan ook hetzelfde: beide lekken dichten.

Welke versies en configuraties zijn kwetsbaar?

• Gepatcht: PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35 (aankondiging php.net, ChangeLog).
• Kwetsbaar: alle eerdere versies, volgens Wiz terug tot PHP 5.4.
• Geen officiële fix: PHP 8.1 en ouder zijn end-of-life. Het PHP-project heeft wel minimale backports voor 7.4, 8.0 en 8.1 gepubliceerd voor wie zelf compileert (Huntress). Vraag anders je Linux-distributie of hostingpartij om een gepatcht pakket.
• PHP 8.2 krijgt na 31 december 2026 helemaal geen beveiligingsupdates meer. Plan de overstap nu al.

Hoe groot het risico is, hangt af van hoe PHP draait (de SAPI):

Tijdlijn

Wordt het al misbruikt?

De bronnen spreken elkaar hier deels tegen. Dat is normaal in de eerste uren na zo'n lek.

• Cloudflare meldde op 21 oktober "early attacks emerging", al vóór de patch uit was (Tenable).
• watchTowr bevestigde op 20 oktober dat het CVE-2026-109618 kon reproduceren.
• Huntress zag op 21 oktober nog geen misbruik bij de eigen klanten (Huntress).
• Er gaat code rond die beweert een exploit te zijn. Die is niet geverifieerd en kan zelf malware bevatten. Draai zulke code nooit zomaar.

Ook overheden namen het serieus: het Verenigd Koninkrijk, Canada, Australië en CERT-EU adviseerden om sites offline te halen tot PHP is bijgewerkt. Volgens Cybersecurity Dive haalden de Finse overheid en de Tweede Kamer hun sites tijdelijk van het internet.

Hoe zijn de lekken gevonden?

Volgens OpenAI vonden onderzoekers van Calif de lekken met behulp van het model GPT-5.6 Sol. Wiz ontdekte ze onafhankelijk daarvan met Wiz Atlas, Gemini 4 Argon en GPT-5.6 Sol. Die modellen hielpen bij het vinden van de bugs, het ontwikkelen van de exploit en het controleren van de patch. De kwetsbare code zat al meer dan tien jaar in PHP. Onderzoekers en het PHP-team hebben de bevindingen gecontroleerd, een gecoördineerde patch gemaakt en die op 21 oktober uitgebracht.

Wat moet je nu doen?

1. Inventariseren

Zoek uit waar PHP draait. Denk niet alleen aan je eigen webservers, maar ook aan control panels (zoals Plesk), appliances, Windows-software en CMS-hosting. Controleer de versie per server:

php -v
php-fpm8.4 -v   # per geïnstalleerde FPM-versie

2. Patchen

Werk bij naar 8.5.12, 8.4.27, 8.3.36 of 8.2.35, of naar het gepatchte pakket van je distributie. Begin bij systemen die vanaf internet bereikbaar zijn. Herstart daarna alle PHP-workers, want een reload is niet genoeg. Let op: de veelgebruikte repository van Remi had op de releasedag nog geen gepatchte pakketten. Plesk publiceerde een eigen advies voor de PHP-versies die het meelevert.

3. Kun je nog niet patchen? Tijdelijke maatregelen

Deze maatregelen komen uit de PHP-adviezen en de uitgebreide gids van Mattias Geniar. Geen ervan is een volledige oplossing.

Multipart-verzoeken blokkeren op de webserver (breekt uploads, dus test daarna je formulieren). Een voorbeeld voor nginx:

# in http {}
map $http_content_type $block_multipart {
    default       0;
    "~*multipart" 1;
}

# in elke server {} die naar PHP doorstuurt
if ($block_multipart) {
    return 403;
}

En voor Caddy:

example.com {
    @multipart header_regexp Content-Type (?i)multipart
    respond @multipart 403
}

PHP-instellingen aanpassen in php.ini of de FPM-pool (dus niet via ini_set() of .user.ini, want die komen te laat):

session.upload_progress.enabled = 0
; alleen PHP 8.5:
fatal_error_backtraces = 0
; tijdelijk, en alleen in een container of cgroup met een eigen geheugenlimiet:
memory_limit = -1

Voor PHP-FPM kun je daarnaast pm.max_requests = 1 zetten, zodat elke worker na één verzoek stopt. Dat kost prestaties. Verplaats verder php_value en php_flag uit .htaccess en PHP_VALUE uit je nginx-config naar php.ini of de pool.

Wat níet helpt: display_errors uitzetten, file_uploads = Off (PHP leest de multipart-body toch), de onderhoudsmodus van je applicatie, CSRF-checks, RLIMIT_AS/RLIMIT_DATA (die veroorzaken juist de fout) en een WAF of CDN zolang de server ook rechtstreeks bereikbaar is.

Helemaal offline? Stop dan de webserver of laat die voor alles een 503 teruggeven. Zet niet alleen de PHP-handler uit, want dan kan de webserver je .php-broncode, inclusief wachtwoorden, als platte tekst tonen.

4. Controleren op misbruik

Let op deze signalen (Huntress, Wiz):

• ongebruikelijke multipart-verzoeken, gevolgd door memory-limit-fouten of reeksen HTTP 500-antwoorden;
• opvallend grote of rare PHPSESSID-cookies;
• PHP-workers die onverklaarbaar crashen of herstarten;
• PHP-processen (php-fpm, php-cgi, apache2, httpd) die een shell, curl, wget, nc, python of perl starten;
• commando's zoals whoami, id of uname -a vanaf de webserver.

Vind je sporen? Isoleer de server, bewaar de logs en zoek naar webshells, nieuwe cronjobs en nieuwe accounts. Wissel daarna wachtwoorden, tokens en sleutels. Een patch verwijdert niets wat een aanvaller al heeft achtergelaten.

Meer lezen

• PHP-beveiligingsadvies op php.net
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618) en GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• NVD: CVE-2026-109618 en CVE-2026-109619
• Wiz: PHP2Shell
• Mattias Geniar: maatregelen per webserver
• Tenable: veelgestelde vragen
• Huntress: detectie en tijdlijn
• Sansec: impact op webshops

Dit artikel is bijgewerkt tot 21 oktober 2026. De situatie verandert snel, dus controleer de officiële adviezen voor de laatste stand.