Linux, Security

PHP2Shell: update nu naar de gepatchte PHP-versie

De patch voor PHP2Shell is uit. Sinds woensdag 21 oktober 2026, 16:00 uur Nederlandse tijd, zijn PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35 beschikbaar. Ze dichten twee kritieke lekken waarmee een aanvaller zonder inlog code op je server kan uitvoeren. Het PHP-team is duidelijk: alleen updaten maakt je veilig, en dat moet nu.

PHP2Shell: is jullie website al gepatcht?

De details lagen al een dag op straat en securitybedrijf Sansec verwachtte massale aanvallen binnen een kwartier na de release. Elk uur dat een server ongepatcht blijft, telt.

In dit artikel lees je wat er precies lek is, naar welke versie je moet, hoe je veilig bijwerkt, wat je doet als updaten vandaag niet lukt en hoe je controleert of er al iemand binnen is geweest.

Bijgewerkt op 21 oktober 2026 na de officiële release van PHP.

Wat is PHP2Shell?

PHP2Shell is de bijnaam voor twee kwetsbaarheden in PHP zelf, allebei met een score van 9,2 op 10 (CVSS v4.0). De naam komt van een exploit-tool die in een gelekte screenshot opdook. PHP heeft nu bevestigd wat er aan de hand is:

CVEWat er misgaat
CVE-2026-109618 — RCE via geheugentekortAls PHP zonder geheugen komt terwijl het een verzoek opbouwt, kan het halverwege worden onderbroken. Bij het opruimen behandelt PHP die half-gevulde gegevens daarna als geldig.
CVE-2026-109619 — RCE via achtergebleven toestandInterne gegevens van een verzoek blijven bestaan nadat het geheugen al is vrijgegeven. Een volgend verzoek in dezelfde worker kan die gegevens gebruiken voordat ze netjes worden gereset.

Wie loopt risico?

Volgens PHP: elke PHP-installatie die webverzoeken afhandelt. Dat geldt voor PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed. Het risico is het grootst bij mod_php: daar is aangetoond dat één verzoek zonder inlog de aanval start voordat er ook maar één regel applicatiecode draait.

Het lek zit dus in PHP, niet in WordPress, Laravel, WooCommerce of een plugin. Je CMS bijwerken lost dit niet op, en een site zonder uploadformulier is net zo kwetsbaar.

Naar welke versie moet je?

Jouw PHP-versieUpdate naarOpmerking
8.58.5.12Officiële release van php.net
8.48.4.27Officiële release van php.net
8.38.3.36Officiële release van php.net
8.28.2.35Officiële release; 8.2 is end-of-life op 31 december 2026, plan nu je upgrade
8.1, 8.0, 7.4 en ouderUpgraden naar 8.2 of hogerGeen release van php.net. Sommige distributies en LTS-leveranciers leveren een backport; PHP heeft ook minimale bronpatches voor 7.4, 8.0 en 8.1 gepubliceerd voor wie zelf compileert

Gebruik je pakketten van een Linux-distributie, dan hoef je niet naar dit versienummer te kijken. Distributies kregen de fixes vooraf en passen ze vaak toe op hun eigen versie (backport). Hoe je dat controleert, lees je hieronder.

Let op als je PHP uit de vrijwillig onderhouden Remi-repository (rpms.remirepo.net) haalt: die krijgt vandaag geen updates. PHP raadt aan over te stappen op distributiepakketten of zelf te compileren.

Stap 1: breng in kaart wat je moet patchen

Werk eerst je servers bij die vanaf internet bereikbaar zijn, mod_php-servers voorop. Bewaar vóór je begint een kopie van je webserver- en PHP-logs vanaf 20 oktober: die heb je nodig in stap 3, en een deploy of logrotatie kan ze wissen.

Weet wat je moet patchen

Vergeet geen staging-omgevingen, oude campagnesites, beheertools als phpMyAdmin en containers. Op een Debian- of Ubuntu-server:

# Welke PHP-versies zijn geïnstalleerd?
ls /etc/php

# Welke PHP-processen draaien er (FPM, Apache mod_php, LiteSpeed)?
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'

php -v op de commandoregel zegt niets over de versie die je website bedient: FPM-pools en Apache kunnen een andere PHP laden. Zet nooit een publieke phpinfo()-pagina online om dit te checken.

Stap 2: zo update je PHP op Linux

Hoe je PHP bijwerkt, hangt af van waar je PHP vandaan komt. Kijk dat eerst na, want daar komt ook je fix vandaan:

BronHerkenbaar aanWaar komt de fix vandaan
Debian- of Ubuntu-pakkettenapt-cache policy toont deb.debian.org, security.debian.orgof security.ubuntu.comSecurity-repository van je distributie (backport)
PPA / repo van Ondřej Surýapt-cache policy toont ppa.launchpadcontent.net/ondrej of packages.sury.orgNieuwe upstream-versie in de PPA
RHEL, AlmaLinux, Rockydnf info php-fpm toont appstreamRed Hat / Alma / Rocky (backport)
Remi-repositoryPakketnamen als php83-php-fpm of repo remi-*Vandaag géén update
AlpinePakketnamen als php83-fpmAlpine-repository
Controlepaneel (cPanel, DirectAdmin, Plesk)PHP onder /opt/cpanel/, /usr/local/php* of /opt/plesk/php/Updatemechanisme van het panel

Maak vóór je begint een snapshot of back-up van de server. Een security-update is meestal probleemloos, maar als je ver achterloopt haal je ook andere wijzigingen binnen.

Debian en Ubuntu

# 1. Pakketlijsten verversen
sudo apt update

# 2. Staat er een PHP-pakket op 'hold'? Dan wordt het stilletjes overgeslagen.
apt-mark showhold
# eventueel: sudo apt-mark unhold php8.3-fpm

# 3. Welke versie staat er en welke is beschikbaar? (doe dit per PHP-versie)
apt-cache policy php8.3-fpm

# 4. Alleen PHP bijwerken
sudo apt install --only-upgrade 'php8.3*'

# of gewoon alles bijwerken
sudo apt upgrade

Herhaal stap 3 en 4 voor elke versie in /etc/php, niet alleen voor de versie waar het php-commando naar wijst.

Gebruik je de distributiepakketten? Dan verandert het upstream-versienummer vaak niet: Debian en Ubuntu passen de fix toe op hun eigen versie. Het pakketnummer en het changelog vertellen of de fix erin zit:

dpkg -l | grep php8.3-fpm
zcat /usr/share/doc/php8.3-fpm/changelog.Debian.gz | grep -m3 -E 'CVE-2026-10961[89]'

Krijg je geen treffer, dan is de fix nog niet binnen. Check dan het security-advies van je distributie (Debian, Ubuntu) en houd de noodmaatregelen aan tot het pakket er is.

Gebruik je de PPA van Ondřej Surý? Dan moet apt-cache policy na de update de nieuwe upstream-versie tonen, bijvoorbeeld 8.3.36. De PPA bouwt alleen voor ondersteunde Ubuntu-versies (22.04 en 24.04). Draai je nog op Ubuntu 20.04 of ouder, dan komt er via deze weg niets meer: plan een migratie naar een nieuwe server.

RHEL, AlmaLinux en Rocky Linux

# 1. Welke PHP-pakketten en welke bron?
dnf list installed 'php*'
dnf module list php        # welke PHP-stream staat aan (bijv. 8.2)?

# 2. Zijn er updates?
sudo dnf check-update 'php*'

# 3. Bijwerken
sudo dnf upgrade 'php*'

# 4. Zit de fix erin?
rpm -q --changelog php-fpm | grep -m3 -E 'CVE-2026-10961[89]'

Ook Red Hat, AlmaLinux en Rocky backporten: het versienummer blijft dan gelijk, het pakketnummer (de release) loopt op. Het changelog is leidend. Staat de fix er nog niet in, volg dan de security-meldingen van je distributie en houd de noodmaatregelen aan.

Gebruik je de Remi-repository? PHP waarschuwt dat rpms.remirepo.net vandaag geen updates heeft. Je kunt dan:

  • de noodmaatregelen doorvoeren en de Remi-updates in de gaten houden (sudo dnf check-update --enablerepo='remi*');
  • overstappen op de PHP-stream van je distributie (dnf module reset php en dnf module enable php:8.2), mits je applicatie met die versie werkt;
  • of PHP zelf compileren (zie hieronder).

Alpine Linux

sudo apk update
sudo apk upgrade 'php83*'      # vervang 83 door jouw versie
php83 -v

Controlepanelen

Op servers met een controlepaneel komt PHP van het panel, niet van je distributie. Werk het bij via het panel:

  • cPanel/WHM (EasyApache): sudo dnf upgrade 'ea-php*' (op oudere systemen yum), of via WHM → EasyApache. Werk elke ea-phpXX bij die geïnstalleerd is.
  • DirectAdmin (CustomBuild): da build update en daarna da build php.
  • Plesk: via Tools & Settings → Updates de PHP-componenten bijwerken.

Controleer daarna per domein welke PHP-versie actief is en of dat de gepatchte build is. Wie op shared hosting zit, kan dit niet zelf: vraag je hoster om bevestiging.

Zelf compileren

Als er geen pakket is, bijvoorbeeld bij Remi of een maatwerkinstallatie, kun je PHP uit de bron bouwen. Doe dit alleen als je weet hoe je huidige PHP is gebouwd:

# Hoe is de huidige PHP gecompileerd?
php -i | grep 'Configure Command'

# Broncode van php.net halen (pas de versie aan)
wget https://www.php.net/distributions/php-8.3.36.tar.gz
tar xzf php-8.3.36.tar.gz && cd php-8.3.36

# Met dezelfde opties bouwen en installeren
./configure <opties van hierboven>
make -j"$(nproc)"
sudo make install

Controleer de download met de handtekeningen op de downloadpagina van php.net. Voor PHP 7.4, 8.0 en 8.1 heeft het PHP-team aparte bronpatches gepubliceerd; die staan gelinkt in het security advisory.

Controleer welke PHP je website écht draait

Na de update en de herstart (zie hieronder) wil je zeker weten dat je site op de gepatchte build draait, niet alleen de commandoregel.

# Versie van de geïnstalleerde FPM-binary
php-fpm8.3 -v

# Is de service ná de update gestart? Kijk naar 'Active: … since'
systemctl status php8.3-fpm

Wil je het vanuit de webserver zelf zien, zet dan tijdelijk een bestand met een willekeurige naam in de webroot, open het één keer in je browser en verwijder het direct weer:

<?php echo PHP_VERSION, ' ', PHP_SAPI;

Bij een upstream-versie zie je hier 8.5.12, 8.4.27, 8.3.36 of 8.2.35. Bij distributiepakketten met een backport kan het oude versienummer blijven staan; dan is het changelog-commando hierboven je bewijs.

Herstarten, en dan écht alles

CVE-2026-109619 draait om gegevens die in een worker achterblijven. Een update zonder herstart doet dus niets.

  • Herstart PHP-FPM voor elke versie, bijvoorbeeld sudo systemctl restart php8.3-fpm, of Apache als PHP als module draait.
  • Herstart langlopende PHP-processen: queue workers, Laravel Horizon, schedulers, Reverb, Octane.
  • Zoek processen die nog op de oude PHP-binary draaien:
ls -l /proc/*/exe 2>/dev/null | grep -i 'php.*deleted'

Docker, FrankenPHP en hosting

  • 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 dat jouw domein op een gepatchte build draait. Overschakelen naar een andere PHP-versie in het panel zegt daar niets over.
  • PHP 8.1 of ouder: vraag je distributie of LTS-leverancier naar een backport, of upgrade. Tot dan: de maatregelen hieronder, of de site offline.

Lukt updaten vandaag niet?

PHP somt een aantal maatregelen op die de bekende aanvalsroutes kleiner maken. Ze maken je installatie uitdrukkelijk niet veilig; zie ze als overbrugging van uren, niet van weken. Zet ze in php.ini, de FPM-pool (php_admin_value / php_admin_flag) of de Apache-configuratie, niet via ini_set() of een .user.ini, en herstart daarna alle workers.

Tegen CVE-2026-109619 (achtergebleven toestand)

; in php.ini, of per FPM-pool:
; php_admin_flag[session.upload_progress.enabled] = off
session.upload_progress.enabled = 0

; alleen op PHP 8.5:
fatal_error_backtraces = 0

Daarnaast adviseert PHP:

  • Verwijder ongeldige of verouderde PHP-instellingen die per verzoek een melding geven. Meldingen verbergen met error_reporting, display_errors of @ helpt niet.
  • Los fatale fouten en time-outs op die een aanvaller kan uitlokken, bijvoorbeeld in upload-, import- of opruimcode.

Tegen CVE-2026-109618 (geheugentekort)

  • Zet memory_limit = -1 via php_admin_value en controleer dat geen enkele pool, map of applicatie weer een limiet instelt. Vang het geheugengebruik dan op met een container- of cgroup-limiet die alleen de betrokken worker stopt. Gebruik daarvoor geen RLIMIT_AS of RLIMIT_DATA: die kunnen juist de kwetsbare fout veroorzaken.
  • Verlaag post_max_size: 8M als je geen uploads nodig hebt, 32M als dat wel moet. Houd upload_max_filesize daaronder.
  • Begrens op webserver- of proxyniveau ook de grootte van verzoeken, het aantal velden, multipart-delen en headers, ook voor verzoeken zonder geldige Content-Length.
; per FPM-pool, bijvoorbeeld /etc/php/8.3/fpm/pool.d/www.conf
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off

Extra laag: multipart-verzoeken blokkeren

Dit is geen officieel PHP-advies, maar wel een maatregel die veel beheerders gisteren al doorvoerden. Wie geen uploads nodig heeft, kan multipart-verzoeken weigeren voordat ze PHP bereiken. Doe het in élke server block of virtual host die naar PHP doorstuurt, ook de catch-all.

Nginx (in de http-context, plus de if bovenaan elke server block):

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

# in elke server block:
if ($block_multipart) { return 403; }

Apache 2.4 (virtual host of bovenaan .htaccess):

<If "req('Content-Type') =~ /multipart/i">
    Require all denied
</If>

Zolang dit staat werken bestandsuploads, formulieren met bijlagen en sommige formulierplugins (zoals Contact Form 7) niet.

Verklein je aanvalsoppervlak

  • Haal staging-sites en PHP-applicaties die je niet direct nodig hebt offline tot ze gepatcht zijn. CERT-EU adviseert kwetsbare internet-facing applicaties desnoods te isoleren.
  • Beperk beheertools zoals phpMyAdmin tot je eigen IP-adres.
  • Zorg dat je server niet buiten je CDN of WAF om bereikbaar is.

Shared hosting? Daar kun je deze instellingen meestal niet betrouwbaar zelf zetten. Vraag je hoster wanneer jouw domein op een gepatchte PHP draait.

Wat níet helpt

  • WordPress, Laravel of plugins bijwerken. Het lek zit in PHP, niet in je applicatie.
  • Beveiligingsplugins zoals Wordfence. Die draaien pas nadat PHP het verzoek al heeft verwerkt.
  • Instellingen via ini_set() of een FPM-.user.ini. Die komen te laat; PHP noemt dit expliciet.
  • Foutmeldingen verbergen met error_reporting, display_errors of @.
  • RLIMIT_AS of RLIMIT_DATA als geheugengrens. Die kunnen de kwetsbare fout juist uitlokken.
  • Alleen een WAF of CDN. Die helpt alleen als je server niet rechtstreeks via zijn IP-adres bereikbaar is.
  • Updaten zonder workers te herstarten. Draaiende processen gebruiken tot een herstart de oude PHP.

Stap 3: controleer of er al iemand binnen is

Patchen sluit de deur, maar zegt niets over wie er al doorheen is gelopen. De details lekten op dinsdag 20 oktober rond 17:20 uur Nederlandse tijd; kijk vanaf 17:00 uur die dag terug tot het moment dat je patchte.

  • 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 instelling auto_prepend_file op 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 update: tijdelijke maatregelen opruimen

Draait de gepatchte PHP aantoonbaar op al je sites en zijn alle workers herstart? Draai dan de noodmaatregelen terug:

  • Zet memory_limit terug naar een normale waarde. Zonder limiet kan één ontspoord script de hele server laten vastlopen.
  • Zet post_max_size en upload_max_filesize terug als je sites grotere uploads nodig hebben.
  • Haal een eventuele multipart-blokkade weg op je webserver en in je CDN, en test daarna een bestandsupload en je belangrijkste formulieren.

session.upload_progress.enabled mag 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