PHP2Shell: twee kritieke PHP-lekken uitgelekt vóór de patch

21 oktober 2026 Kwetsbaarheden 8 min lezen

Op 20 oktober heeft het PHP-securityteam een buitengewone beveiligingsrelease aangekondigd voor twee kritieke kwetsbaarheden in PHP. De aanleiding was een lek: informatie over de kwetsbaarheden verscheen online terwijl ze nog onder embargo stonden. De patch staat gepland voor woensdag 21 oktober 2026 om 14:00 UTC, 16:00 uur Nederlandse tijd.

Dit artikel is geschreven op de ochtend van 21 oktober, dus vóór de release. Veel details zijn nog niet bekend en ik doe geen poging die in te vullen. Het gaat om wat je nu al kunt doen, zodat je om 16:00 uur alleen nog hoeft te patchen.

Wat bevestigd is

Volgens de aankondiging van PHP:

Er komt een beveiligingsrelease voor twee kritieke kwetsbaarheden, elk met CVSS v4.0 9.2.
De release is gepland op 21 oktober om 14:00 UTC. PHP behoudt zich het recht voor eerder te publiceren als details openbaar worden of als er misbruik in het wild opduikt.
Getroffen versies, fixversies en technische details volgen pas bij de release.

CERT-EU noemt de kwetsbaarheden CVE-2026-109618 en CVE-2026-109619 en wijst op een mogelijke remote code execution zonder authenticatie. Het advies van CERT-EU: breng in kaart welke applicaties op PHP draaien, bereid het patchen voor, en overweeg internet-facing applicaties los te koppelen als je niet direct kunt patchen.

Volgens de supported-versions-pagina worden op dit moment de branches 8.2, 8.3, 8.4 en 8.5 ondersteund. Alles daarvoor, dus 8.1, 8.0, 7.x en 5.x, is end-of-life en krijgt van PHP zelf geen fix.

Wat nog niet bevestigd is

Hier lopen de berichten uiteen. Dit is de stand van de openbare bronnen op het moment van schrijven:

Welke versies. Meerdere bronnen melden dat de kwetsbaarheden teruggaan tot PHP 5. PHP heeft dat niet bevestigd. Klopt het, dan blijven alle end-of-life-versies zonder officiële patch.
Welk onderdeel en welke voorwaarden. Root cause, component en aanvalspad zijn niet gepubliceerd. Het is onbekend of een gewoon webverzoek volstaat, of het alleen geldt voor een bepaalde SAPI (PHP-FPM, CGI, mod_php) en of er een specifieke configuratie nodig is.
Ernst. In het lek werd CVSS 10.0 genoemd. PHP houdt het op 9.2.
PoC. Een beveiligingsbedrijf zegt CVE-2026-109618 te hebben gereproduceerd, zonder details te delen. Op sociale media circuleren claims over proof-of-concepts en korte video’s, maar minstens één daarvan is door anderen getest en werkte niet. Ik heb geen bevestigde, werkende publieke exploit gevonden. Behandel zulke claims daarom voorzichtig, en draai nooit “PoC’s” van onbekende herkomst op je eigen systemen: nep-exploits met malware erin zijn bij elk groot lek een bekend verschijnsel.
Misbruik. De bronnen die ik heb geraadpleegd melden tot nu toe geen misbruik in het wild.

Mijn inschatting is dat dat snel verandert zodra de patch uit is. Een patch laat zien wat er is aangepast, en daarmee waar de bug zit. Bij CVE-2024-4577, de PHP-CGI-kwetsbaarheid uit 2024, zagen onderzoekers binnen een dag aanvalspogingen. Reken erop dat het hier minstens zo snel gaat.

Waarom dit breder is dan “de webserver”

PHP zit op meer plekken dan alleen de bekende webservers. Daarom is de inventarisatie het grootste werk:

Eigen webapplicaties en CMS’en: WordPress, Drupal, Joomla, Magento, Moodle, intranetten, wiki’s.
Beheertools en control panels: cPanel, Plesk, monitoring-dashboards, ticketsystemen, wachtwoordresets.
Software van leveranciers. Applicaties die als “kant-en-klaar” pakket zijn geïnstalleerd en een eigen PHP meenemen, op Windows vaak als php-cgi.exe achter IIS.
Appliances. Ook firewalls, VPN-portalen en andere apparaten gebruiken soms PHP in hun webinterface. Een oude advisory van Palo Alto Networks (CVE-2020-1993, een session fixation met lage ernst uit 2020) laat bijvoorbeeld zien dat de GlobalProtect-portal PHP gebruikt. Dat zegt niets over deze nieuwe kwetsbaarheden. Of een appliance geraakt wordt, kan alleen de leverancier vertellen. Patchen kun je daar niet zelf: je bent afhankelijk van een update van de leverancier.

Het laatste punt is het vervelende. Voor de eerste twee categorieën heb je de patch zelf in de hand. Voor software van leveranciers en appliances ben je afhankelijk van hun tempo, en dat is bij een lek zonder embargo een reden om die systemen extra af te schermen.

Wat je nu doet

1. Inventariseren

Op Linux:

# Welke PHP-versie draait er, en via welke SAPI?
php -v
ps -eo user,pid,cmd | grep -E 'php-fpm|php-cgi|httpd|apache2' | grep -v grep

# Geïnstalleerde pakketten (Debian/Ubuntu respectievelijk RHEL-familie)
dpkg -l | grep -i php
rpm -qa | grep -i php

Let op met distributiepakketten: Debian, Ubuntu en Red Hat backporten beveiligingsfixes vaak naar hun eigen versie. Het versienummer zegt dan weinig. Kijk in de security-advisories van je distributie of de fix in jouw pakketversie zit, niet alleen naar het PHP-versienummer.

Op Windows-servers zoek je naar meegeleverde PHP-installaties:

# PHP-binaries op lokale schijven, met versie-informatie
Get-PSDrive -PSProvider FileSystem | ForEach-Object {
    Get-ChildItem -Path $_.Root -Include php.exe, php-cgi.exe -Recurse -ErrorAction SilentlyContinue
} | Select-Object FullName, @{n='Versie';e={$_.VersionInfo.ProductVersion}}, LastWriteTime

Met Microsoft Defender for Endpoint kun je dat breed doen, via de processen die de laatste maand zijn gestart:

DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName in~ ("php.exe", "php-cgi.exe", "php-fpm", "php", "php-cgi")
     or FileName matches regex @"^php-fpm\d"
| summarize LaatstGezien = max(Timestamp), Paden = make_set(FolderPath, 10)
    by DeviceName, FileName
| order by DeviceName asc

Vergeet niet de systemen die niet in je EDR zitten, zoals appliances en de webserver bij een externe hostingpartij. Vraag bij je leveranciers en hostingpartijen actief na of zij geraakt worden en wanneer ze patchen.

2. Prioriteren en patchen

Internet-facing eerst. Een PHP-applicatie die vanaf internet bereikbaar is, patch je vanmiddag. Interne systemen volgen daarna.
Zorg dat je om 16:00 uur klaar staat. Change gereed, back-up of snapshot gemaakt, testomgeving beschikbaar, en iemand die de applicatie na de update controleert.
End-of-life-versies krijgen naar verwachting geen fix. Opties zijn upgraden naar een ondersteunde branch, een backport van je distributie of hostingpartij, of het systeem van internet halen of achter een VPN zetten. Dit is het moment om dat lijstje oude PHP-installaties eindelijk weg te werken.
Kun je niet direct patchen? Volg het advies van CERT-EU en koppel de applicatie los van internet, of beperk de toegang tot bekende IP-adressen.

Er circuleren tijdelijke maatregelen, zoals het uitzetten van session.upload_progress.enabled. Die zijn gebaseerd op een vermoeden over de oorzaak. Op sociale media claimt een onderzoeker dat het om use-after-free-fouten gaat in de afhandeling van upload progress in de sessie-extensie, en dat zijn proof-of-concept niet zonder meer breed inzetbaar is. Ook dat is niet door PHP bevestigd. Het is een instelling die je zelden nodig hebt, dus uitzetten kan meestal geen kwaad, maar reken er niet op dat het je beschermt. Voor end-of-life-versies, die geen patch krijgen, is het wel een van de weinige knoppen die je hebt. Doe je het, herstart dan PHP-FPM of de webserver, en controleer de waarde in de configuratie van de SAPI die je webserver echt gebruikt. php -i op de command-line laat de CLI-configuratie zien, en die is vaak een ander php.ini-bestand dan dat van PHP-FPM. Hetzelfde geldt voor WAF-regels: die zijn bij een geheugenfout in de runtime vaak niet afdoende.

3. Kijken wat PHP opstart

Een PHP-proces dat een shell start, is bijna altijd verdacht. Zo is RCE via een webapplicatie het makkelijkst te herkennen: de PHP-worker start sh, bash, cmd.exe of powershell.exe, of tools als curl, wget en certutil. Die detectie kun je nu al inregelen, los van de details van deze kwetsbaarheden:

DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("php.exe", "php-cgi.exe", "php-fpm", "php", "php-cgi", "httpd", "apache2", "w3wp.exe")
     or InitiatingProcessFileName matches regex @"^php-fpm\d"
| where FileName in~ ("sh", "bash", "dash", "cmd.exe", "powershell.exe", "pwsh.exe",
                      "python", "python3", "perl", "curl", "wget", "nc", "ncat",
                      "certutil.exe", "whoami", "whoami.exe", "id", "uname")
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, AccountName
| order by Timestamp desc

Draai deze query vóór 16:00 uur ook al een keer. Dan weet je wat normaal is: sommige applicaties starten legitiem een externe tool, zoals ImageMagick of een PDF-converter. Die wil je als uitzondering kennen voordat je moet beoordelen of een treffer echt is.

Heb je op Linux-webservers geen EDR, kijk dan in elk geval naar nieuwe of gewijzigde .php-bestanden in de webroot (webshells), nieuwe cronjobs en nieuwe accounts. Op Linux kun je ook met auditd de execve-aanroepen van de webserveruser vastleggen.

4. Bij een treffer

Isoleer de server, bewaar de web- en PHP-logs vóór je iets opschoont, en zoek naar persistentie: webshells, cronjobs of geplande taken, nieuwe accounts, SSH-sleutels. Een server waarop code is uitgevoerd onder de webserveruser, behandel je als gecompromitteerd. Roteer dan ook de geheimen die de applicatie gebruikt, zoals databasewachtwoorden en API-sleutels. In mijn artikel over NetScaler staat waarom alleen patchen na een mogelijke inbraak niet genoeg is.

Wat ik eruit meeneem

Er is nog maar weinig bekend, en dat is precies de les. Bij een uitgelekte kwetsbaarheid verschuift het werk naar voren: je hebt geen tijd om na de release nog uit te zoeken wáár PHP draait. Organisaties die een actuele lijst van hun software en versies hebben, hoeven vanmiddag alleen te patchen. De rest is vanmiddag nog aan het zoeken.

Na de release volgen de echte details: getroffen versies, fixversies en waarschijnlijk ook technische analyses. Controleer dan de aankondiging op php.net en de advisories van je distributie en leveranciers. Wat in dit artikel als onbevestigd staat, kan dan anders blijken.