PHP2Shell: zo vindt, patcht en controleert u elke PHP-server

PHP2Shell is een paar kritieke kwetsbaarheden in de PHP-engine zelf, CVE-2026-109618 en CVE-2026-109619, gepubliceerd op 21 oktober 2026 met een CVSS-score van 9.2. Op een ongepatchte runtime kan een aanvaller zonder account code uitvoeren als de PHP-worker, of procesgeheugen uitlezen waarin wachtwoorden, sessietokens, API-sleutels en certificaten staan. Uw applicatiecode hoeft daarvoor geen fout te bevatten: volgens de onderzoekers kan zelfs een "Hello World"-pagina op een getroffen PHP-versie kwetsbaar zijn. De enige echte oplossing is een gecorrigeerde PHP-release, gevolgd door een herstart van elk proces dat PHP draait. Deze gids geeft u de commando’s.

Welke versies zijn opgelost

PHP 8.1, 8.0 en 7.x zijn end-of-life en krijgen geen fix. Draait u die nog, dan bestaat de patch uit een overstap naar een ondersteunde branch.

Linuxdistributies backporten beveiligingsfixes vaak naar hun eigen pakketten zonder over te stappen op het upstream-versienummer. Op die systemen zegt de versie alleen niet genoeg: zoek in de changelog van het pakket naar de twee CVE-nummers (stap 2).

Stap 1: vind elke PHP-runtime

Begin met de inventarisatie, want de runtime waar niemand meer aan dacht, is degene die geraakt wordt. Op elke server:

php -v
systemctl list-units --type=service --all 'php*' 'apache2*' 'httpd*'
ls /usr/sbin/php-fpm* /usr/bin/php[0-9]* 2>/dev/null

De eerste regel toont de CLI-versie, de tweede de actieve PHP-FPM-pools en webservers, en de derde elke PHP-versie die naast andere versies geïnstalleerd is (een veelvoorkomende bron van vergeten runtimes). Maak ook een lijst van de geïnstalleerde pakketten:

dpkg -l 'php*' | grep '^ii'      # Debian, Ubuntu
rpm -qa 'php*' 'ea-php*'         # RHEL, AlmaLinux, Rocky, cPanel

Controleer bij containers de PHP-versie in elke draaiende image:

docker ps --format '{{.Names}}' | while read c; do printf '%s: ' "$c"; docker exec "$c" php -r 'echo PHP_VERSION, PHP_EOL;' 2>/dev/null || echo 'no php'; done

Vergeet staging-, cron- en queueservers, build-agents en managed-hostingpakketten niet. Hebt u een hostingpakket, vraag de provider dan schriftelijk welke PHP-build u draait en wanneer die is gepatcht.

Stap 2: installeer de gecorrigeerde release

Debian en Ubuntu (vervang 8.3 door uw branch):

sudo apt update
sudo apt install --only-upgrade 'php8.3*'
apt changelog php8.3-fpm | grep -E 'CVE-2026-10961[89]'

RHEL, AlmaLinux, Rocky Linux:

sudo dnf upgrade 'php*'
rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]'

cPanel-servers met EasyApache 4-pakketten:

sudo dnf upgrade 'ea-php*'      # older systems: sudo yum update 'ea-php*'

Alpine Linux (pakketnamen bevatten de branch, bijvoorbeeld php83):

apk update && apk upgrade 'php83*'

Docker-images: pin de gecorrigeerde tag in de Dockerfile, bijvoorbeeld FROM php:8.3.36-fpm, bouw daarna opnieuw zonder cache en vervang de draaiende containers:

docker build --pull --no-cache -t myapp:php2shell .
docker compose up -d --build --force-recreate

Geeft de grep op de changelog niets terug, dan heeft uw distributie de fix nog niet uitgebracht. Blijf controleren, gebruik de officiële release van php.net waar u PHP zelf bouwt, en neem in de tussentijd de tijdelijke maatregelen hieronder.

Stap 3: herstart alles wat de oude PHP heeft geladen

Een nieuw pakket verandert niets aan processen die al draaien. Herstart ze:

sudo systemctl restart php8.3-fpm     # Debian, Ubuntu (one per installed version)
sudo systemctl restart php-fpm        # RHEL family
sudo systemctl restart apache2        # Apache with mod_php (httpd on RHEL)
sudo supervisorctl restart all        # long-running workers under Supervisor
php artisan queue:restart             # Laravel queue workers

Op Debian en Ubuntu toont sudo needrestart -r l welke services nog oude bibliotheken gebruiken.

Stap 4: controleer

Controleer elke runtime opnieuw, deze keer de runtime die de webserver gebruikt, niet alleen de CLI:

php-fpm8.3 -v                         # or: php-fpm -v
systemctl status php8.3-fpm | grep Active

De versie moet gelijk zijn aan of hoger zijn dan de gecorrigeerde release (of de changelog van het pakket moet beide CVE’s noemen), en het tijdstip bij "Active: since" moet na de update liggen. In WordPress kunt u de versie ook aflezen onder Gereedschap, Sitediagnose, Info, Server. Zet geen phpinfo()-pagina online om dit te controleren: die onthult precies waar aanvallers naar zoeken.

Als de update moet wachten

Deze instellingen van de onderzoekers verkleinen het risico terwijl u de update voorbereidt. Ze zijn geen oplossing:

; php.ini
post_max_size = 8M                  ; as low as your uploads allow
max_input_nesting_level = 32        ; as low as your forms allow
session.upload_progress.enabled = 0
fatal_error_backtraces = 0          ; where your PHP version supports it

; PHP-FPM pool: recycle workers more often (costs performance)
pm.max_requests = 100

De waarden zijn voorbeelden; test ze met uw applicatie. memory_limit = -1 blokkeert sommige aanvalspaden, maar gebruik dit alleen samen met een limiet op besturingssysteemniveau zoals memory.max van cgroup v2, en vervang die limiet nooit door RLIMIT_AS of RLIMIT_DATA. WAF- en CDN-regels van uw provider helpen als overbrugging, niet als vervanging van de update.

Zoek naar tekenen van een aanval

Er is niet één detectieregel. Deze commando’s brengen de signalen naar boven die de onderzoekers beschrijven:

grep -E 'Allowed memory size of [0-9]+ bytes exhausted' /var/log/php*-fpm.log /var/log/apache2/error.log
grep -E 'exited on signal (6|11)' /var/log/php*-fpm.log
awk '$9 == 500' /var/log/nginx/access.log | wc -l

Fouten over de geheugenlimiet na ongebruikelijke multipart-verzoeken, pieken in HTTP 500-antwoorden, PHP-workers die crashen op signalen en ongewoon grote PHPSESSID-cookies in antwoorden verdienen een nadere blik. Geen van deze signalen bewijst een aanval, en hun afwezigheid bewijst niet dat u niet getroffen bent. Vindt u ze, bewaar dan de logs, patch en vervang de geheimen die in het PHP-geheugen stonden: databasewachtwoorden, applicatiesleutels en API-tokens. Ons incidentresponsteam kan het onderzoek overnemen, en onze beheerde beveiliging kan uw servers na de patch in de gaten houden.

Waar u begint

1. Voer de inventarisatiecommando’s uit op elke server en in elke container en noteer elke PHP-versie.
2. Werk bij met uw pakketbeheerder of bouw uw images opnieuw op een gecorrigeerde tag.
3. Herstart PHP-FPM, Apache en elke PHP-worker.
4. Controleer de versie en het herstarttijdstip, en bewaar de uitvoer als bewijs.
5. Doorzoek uw logs met grep op de signalen hierboven en vervang de geheimen op elk systeem waar ze opduiken.

Details: PHP2Shell-advieswebsite, aankondiging van de PHP Foundation, Wiz Research.