Wil je jouw Linux Server updaten? Klik dan op onderstaande blogartikel:
“Draai je websites of applicaties op PHP, update dan vandaag nog. Op woensdag 21 oktober 2026 om 16:00 uur Nederlandse tijd (14:00 UTC) brengt het PHP-team een noodupdate uit voor twee kritieke lekken die bekendstaan als PHP2Shell. De details lagen al op straat voordat de patch klaar was, dus aanvallers hebben een voorsprong.
In dit artikel lees je wat PHP2Shell is, hoe je je server tot de patch tijdelijk afschermt, hoe je daarna veilig bijwerkt en hoe je controleert of er al iemand binnen is geweest.
Dit artikel is bijgewerkt tot woensdagochtend 21 oktober. Zodra PHP de officiële lijst met getroffen en gepatchte versies publiceert, werken we het bij.
Wat is PHP2Shell?
PHP2Shell is de bijnaam voor twee kwetsbaarheden in PHP zelf: CVE-2026-109618 en CVE-2026-109619. Het PHP-team geeft beide een score van 9,2 op 10 (CVSS v4.0). Volgens onder meer CERT-EU kan een aanvaller er zonder inlog eigen code mee uitvoeren op je server (remote code execution).
De naam komt van een exploit-tool die in een gelekte screenshot opdook. Op dinsdagmiddag 20 oktober verschenen de eerste details online, ruim voor de geplande bekendmaking. Securitybedrijf Sansec verwacht massale aanvallen binnen een kwartier na het uitkomen van de patch, omdat aanvallers dan kunnen zien wat er precies is gerepareerd.
Waar zit het lek?
PHP heeft de technische oorzaak nog niet bevestigd. Onafhankelijke onderzoekers wijzen naar de manier waarop PHP multipart-verzoeken verwerkt: het formaat waarmee een browser formulieren met bestanden verstuurt. Het gaat volgens hen om een geheugenfout (use-after-free) in de functie session upload progress, die bijhoudt hoe ver een upload is. Die functie staat standaard aan.
Het belangrijkste om te onthouden: het lek zit in PHP zelf, niet in WordPress, Laravel of een plugin. PHP verwerkt het verzoek al voordat je applicatie ook maar één regel code uitvoert. Een site zonder uploadformulier is dus niet automatisch veilig, en WordPress bijwerken lost dit niet op.
Ben jij kwetsbaar?
Ga ervan uit van wel als je PHP gebruikt. De officiële lijst met getroffen versies volgt pas met de release, maar de signalen zijn duidelijk:
| PHP-versie | Status | Wat te doen |
|---|---|---|
| 8.2, 8.3, 8.4, 8.5 | Ondersteund, krijgt een patch | Vandaag tijdelijke maatregelen, na 16:00 uur bijwerken |
| 8.1 en ouder | End-of-life, krijgt naar verwachting géén patch | Tijdelijke maatregelen laten staan en zo snel mogelijk upgraden |
| Onbekend | Inventariseren | Eerst uitzoeken welke PHP je site écht bedient (stap 1) |
watchTowr en CERT-EU houden er rekening mee dat versies vanaf PHP 5 geraakt zijn. Draai je nog op Ubuntu 20.04 met PHP uit de PPA van Ondřej Surý, dan komt er voor jou waarschijnlijk geen bijgewerkt pakket: die PPA levert alleen nog voor Ubuntu 22.04 en 24.04.
Stap 1: breng al je PHP in kaart
Je kunt alleen patchen wat je kent. Maak een lijst van elke server en elke site die PHP draait, ook staging-omgevingen, oude campagnesites, beheertools als phpMyAdmin en containers. Noteer per host welke PHP-versies er staan, waar PHP vandaan komt (distributiepakketten, PPA, Docker-image, hostingpanel) en of de host vanaf internet bereikbaar is.
Op een Debian- of Ubuntu-server kom je een heel eind met:
# Welke PHP-versies zijn geïnstalleerd?
ls /etc/php
# Welke PHP-processen draaien er?
ps -eo pid,comm,args | grep -E '[p]hp-fpm|[a]pache2|[h]ttpd|[l]sphp'
# Welke sites geven verzoeken door aan PHP?
sudo nginx -T | grep -E 'server_name|fastcgi_pass'
# Luistert PHP ergens rechtstreeks op een poort?
sudo ss -tlnpLet op: php -v op de commandoregel zegt niets over de versie die je website bedient. PHP-FPM, Apache mod_php en losse FPM-pools kunnen elk een andere versie en een ander php.ini laden. Zet ook nooit een publieke phpinfo()-pagina online om dit te checken.
Stap 2: tijdelijke maatregelen tot de patch
De enige echte oplossing is PHP bijwerken. Een PHP-kernontwikkelaar zei dat ook letterlijk: patchen is de enige mitigatie. De twee maatregelen hieronder zijn niet officieel van PHP, maar verkleinen het risico flink voor de uren tot de update. Doe ze allebei.
A. Zet session upload progress uit
In de php.ini van je webserver (niet alleen die van de CLI):
session.upload_progress.enabled = OffGebruik je PHP-FPM, zet de instelling dan ook vast in élke pool, zodat een .user.ini in een webmap hem niet stilletjes weer aan kan zetten. Op Debian/Ubuntu staan de pools in /etc/php/<versie>/fpm/pool.d/:
php_admin_flag[session.upload_progress.enabled] = offHerstart daarna PHP-FPM voor elke versie, bijvoorbeeld sudo systemctl restart php8.3-fpm. Het enige wat je merkt: voortgangsbalken die op deze PHP-functie leunen werken niet meer.
Shared hosting? Zet de regel hierboven in een .user.ini-bestand naast je index.php (bij PHP-FPM; kan tot 5 minuten duren voor het actief is). Draait PHP als Apache-module, gebruik dan in .htaccess: php_flag session.upload_progress.enabled off. Krijg je daarna een 500-fout, haal de regel dan weer weg en vraag je hoster om hulp.
B. Blokkeer multipart-verzoeken op de webserver
Dit is de sterkste tijdelijke maatregel: weiger elk verzoek met “multipart” in de Content-Type-header, vóórdat het PHP bereikt. Doe dit voor álle HTTP-methoden (PHP 8.4 kan multipart ook bij PUT en PATCH verwerken) en in élke server block of virtual host die naar PHP doorstuurt, inclusief de default/catch-all. Aanvallers sturen verzoeken ook rechtstreeks naar je IP-adres.
Nginx — in de http-context, bijvoorbeeld in /etc/nginx/conf.d/block-multipart.conf:
map $http_content_type $block_multipart {
default 0;
"~*multipart" 1;
}En bovenaan elke server block die naar PHP doorstuurt:
if ($block_multipart) {
return 403;
}Controleer met sudo nginx -t en herlaad nginx.
Apache 2.4 — in de virtual host of bovenaan .htaccess (boven de WordPress-regels):
<If "req('Content-Type') =~ /multipart/i">
Require all denied
</If>Gebruik hier echt req('Content-Type') en niet %{CONTENT_TYPE}: die laatste kijkt naar het antwoord in plaats van het verzoek, waardoor de blokkade niets doet.
LiteSpeed — bovenaan .htaccess, buiten het WordPress-blok, en herstart daarna LiteSpeed:
RewriteEngine On
RewriteCond %{HTTP:Content-Type} multipart [NC]
RewriteRule ^ - [F]Cloudflare (aanvulling, geen vervanging) — een Custom Rule met actie Block en de expressie:
any(lower(http.request.headers["content-type"][*])[*] contains "multipart")Cloudflare beschermt alleen verkeer dat via Cloudflare loopt. Zet de blokkade dus óók op de server zelf, of laat poort 80 en 443 alleen verkeer van de Cloudflare-IP-ranges toe.
Testen — vanaf een andere machine, zowel via je domein als rechtstreeks naar je server-IP:
curl -sS -o /dev/null -w '%{http_code}\n' -F test=1 https://jouwdomein.nl/
curl -sS -o /dev/null -w '%{http_code}\n' -X PUT -F test=1 https://jouwdomein.nl/index.php
curl -sS -o /dev/null -w '%{http_code}\n' -F test=1 --resolve jouwdomein.nl:443:<server-ip> https://jouwdomein.nl/Je wilt overal een 403 zien. Let op: ook een WordPress-beveiligingsplugin kan een 403 geven, maar die draait pas nadat PHP het verzoek al heeft verwerkt. Kijk dus of de 403-pagina van je webserver komt.
Bijwerkingen: zolang de blokkade staat werken bestandsuploads niet. Denk aan de WordPress-mediabibliotheek, formulieren met bijlagen, Livewire- en Filament-uploads. Contact Form 7 verstuurt ook gewone formulieren als multipart, dus test je belangrijkste formulieren. Normale pagina’s, inloggen en JSON-API’s blijven gewoon werken.
C. Verklein je aanvalsoppervlak
- Haal staging-sites en PHP-applicaties die je vandaag niet nodig hebt offline tot ze gepatcht zijn.
- Beperk beheertools zoals phpMyAdmin tot je eigen IP-adres (
allow+deny all;in nginx). - Zorg dat je server niet buiten je CDN of WAF om bereikbaar is.
Wat níet helpt
Alles wat pas draait nadat PHP het verzoek heeft ingelezen, komt te laat. Reken dus niet op:
- WordPress of plugins bijwerken. Het lek zit in PHP, niet in je CMS.
- Beveiligingsplugins zoals Wordfence. Ook de firewall van Wordfence (via
auto_prepend_file) draait pas als PHP het multipart-verzoek al heeft verwerkt. file_uploads = Off. PHP leest het multipart-verzoek dan nog steeds in; het slaat alleen de bestanden over.disable_functions. Het blokkeren van functies alssystem()raakt de fout in de verwerking niet.- Een kleine
post_max_size. Er is geen veilige grens bekend. - Alleen een WAF of CDN. Die helpt alleen als je server niet rechtstreeks via zijn IP-adres bereikbaar is.
- Laravel-maintenance-mode of een 419-melding. Die komen pas nadat PHP het verzoek al heeft verwerkt.
Stap 3: bijwerken zodra de patch er is
Houd vanaf 16:00 uur php.net, de php.announce-mailinglijst en de advisories van je distributie in de gaten. PHP kan ook eerder uitbrengen als er actieve aanvallen worden gezien. Werk eerst je internet-facing servers bij, daarna de rest.
Bewaar vóór je begint een kopie van je webserver- en PHP-logs vanaf 20 oktober. Die heb je straks nodig in stap 4, en een deploy of logrotatie kan ze wissen.
Debian en Ubuntu
sudo apt update
# Staat er een pakket op 'hold'? Dan doet de update stilletjes niets.
apt-mark showhold
# Welke versie staat er en welke is beschikbaar?
apt-cache policy php8.3-fpm
sudo apt upgradeWerk elke geïnstalleerde PHP-versie bij, niet alleen de versie waar het php-commando naar wijst. Distributies als Debian en Ubuntu passen beveiligingsfixes vaak toe op de bestaande versie (backport). Het versienummer kan er dan oud uitzien terwijl de fix er wél in zit. Controleer dat in het changelog:
zcat /usr/share/doc/php8.3-fpm/changelog.Debian.gz | head -20Zit je ver achter op updates, houd er dan rekening mee dat je ook andere wijzigingen binnenhaalt. Klik daarna je site even door.
Herstarten, en dan écht alles
- Herstart PHP-FPM voor elke versie, of Apache als PHP als module draait.
- Herstart langlopende PHP-processen: queue workers, Laravel Horizon, schedulers, Reverb, Octane. Die blijven anders de oude PHP gebruiken.
- Zoek processen die nog op de oude, inmiddels vervangen PHP-binary draaien:
ls -l /proc/*/exe 2>/dev/null | grep -i 'php.*deleted'Docker, hosting en panels
- Docker: een bijgewerkte host repareert de PHP in je containers niet. Haal het gepatchte base-image op, bouw opnieuw en deploy. Controleer met
docker run --rm jouw-image php -v. - FrankenPHP: PHP zit in de binary zelf, dus je hebt een nieuwe FrankenPHP-build nodig.
- Shared of managed hosting, cPanel, Plesk, DirectAdmin: vraag je hoster om te bevestigen welke gepatchte PHP-build jouw domein bedient. Overschakelen naar een andere PHP-versie in het panel zegt niets over de vraag of die build gepatcht is.
- PHP 8.1 of ouder: laat de tijdelijke maatregelen staan of houd de site offline tot je hebt geüpgraded.
Stap 4: controleer of er al iemand binnen is
Patchen sluit de deur, maar zegt niets over wie er al doorheen is gelopen. Kijk terug tot dinsdag 20 oktober rond 17:00 uur Nederlandse tijd, kort voor de eerste publieke berichten over het lek.
- Zoek in je webserver- en PHP-logs naar ongebruikelijke multipart-verzoeken en crashes van PHP-FPM-workers.
- Zoek naar nieuwe of gewijzigde bestanden in webroots, uploadmappen, plugins en mu-plugins:
find /var/www -type f -newermt '2026-10-20 15:00 UTC'(reken op ruis van caches en logs). - Controleer
.user.ini-bestanden en de instellingauto_prepend_fileop wijzigingen. - Loop cron, systemd-units en Supervisor na op nieuwe taken, en kijk naar nieuwe SSH-sleutels.
- Let op PHP-processen die een shell, Python of curl/wget opstarten, en op onverwachte uitgaande verbindingen van de PHP-gebruiker.
- Kijk in je applicaties of er nieuwe beheerdersaccounts zijn bijgekomen.
Vind je iets? Isoleer de server en bewaar de logs. Wijst het bewijs op een inbraak, bouw de server dan opnieuw op en wijzig elk geheim waar de PHP-gebruiker bij kon: .env-bestanden, databasewachtwoorden, API-sleutels en app keys. Een schone controle is geen garantie, maar wel een goed teken.
Na de patch: tijdelijke maatregelen opruimen
Draait de gepatchte PHP-versie aantoonbaar op je site? Haal dan de multipart-blokkade weg van je webserver en uit Cloudflare. Test daarna een bestandsupload en de formulieren die tijdelijk niet werkten. Session upload progress mag gewoon uit blijven, tenzij je applicatie die functie gebruikt.
Hulp nodig?
Klanten met serverbeheer hoeven niets te doen: wij hebben de tijdelijke maatregelen al doorgevoerd en patchen zodra de update beschikbaar is.
Heb je geen beheercontract, of weet je niet zeker of jouw server goed is afgeschermd? Neem contact op met Servermeister via [email protected] of 020 895 0045. We kijken vandaag nog met je mee.
Block "serverbeheer-aanbod-content" not found