PHP2Shell: Befehle zum Finden, Patchen und Prüfen aller PHP-Server

PHP2Shell bezeichnet zwei kritische Schwachstellen in der PHP-Engine selbst, CVE-2026-109618 und CVE-2026-109619, veröffentlicht am 21. Oktober 2026 mit einem Schweregrad von CVSS 9.2. Auf einer ungepatchten Laufzeitumgebung kann ein Angreifer ohne Konto Code als PHP-Worker ausführen oder Prozessspeicher auslesen, in dem Passwörter, Session-Tokens, API-Schlüssel und Zertifikate liegen. Ihr Anwendungscode muss dafür keinen Fehler enthalten: Laut den Forschern kann schon eine „Hello World“-Seite auf einer betroffenen PHP-Version angreifbar sein. Die einzige echte Abhilfe ist ein korrigiertes PHP-Release, gefolgt von einem Neustart jedes Prozesses, der PHP ausführt. Dieser Leitfaden liefert Ihnen die Befehle.

Welche Versionen behoben sind

PHP 8.1, 8.0 und 7.x haben das Ende ihres Lebenszyklus erreicht und erhalten keinen Fix. Wenn Sie diese Versionen noch betreiben, besteht der Patch im Wechsel auf einen unterstützten Zweig.

Linux-Distributionen portieren Sicherheitskorrekturen oft in ihre eigenen Pakete zurück, ohne die Upstream-Versionsnummer zu übernehmen. Auf solchen Systemen sagt die Version allein nicht genug aus: Suchen Sie im Changelog des Pakets nach den beiden CVE-Nummern (Schritt 2).

Schritt 1: jede PHP-Laufzeit finden

Beginnen Sie mit der Bestandsaufnahme, denn getroffen wird die Laufzeit, an die sich niemand erinnert hat. Auf jedem 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

Die erste Zeile zeigt die CLI-Version, die zweite die laufenden PHP-FPM-Pools und Webserver und die dritte jede parallel installierte PHP-Version (eine häufige Quelle vergessener Laufzeiten). Listen Sie auch die installierten Pakete auf:

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

Prüfen Sie bei Containern die PHP-Version in jedem laufenden 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

Vergessen Sie Staging-, Cron- und Queue-Server, Build-Agents und Managed-Hosting-Tarife nicht. Fragen Sie bei einem Hosting-Tarif den Anbieter schriftlich, welchen PHP-Build Sie nutzen und wann er gepatcht wurde.

Schritt 2: das korrigierte Release installieren

Debian und Ubuntu (ersetzen Sie 8.3 durch Ihren Zweig):

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-Server mit EasyApache-4-Paketen:

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

Alpine Linux (die Paketnamen enthalten den Zweig, z. B. php83):

apk update && apk upgrade 'php83*'

Docker-Images: Pinnen Sie das korrigierte Tag im Dockerfile, zum Beispiel FROM php:8.3.36-fpm, bauen Sie dann ohne Cache neu und ersetzen Sie die laufenden Container:

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

Gibt der grep auf das Changelog nichts aus, hat Ihre Distribution den Fix noch nicht ausgeliefert. Prüfen Sie weiter, verwenden Sie dort, wo Sie PHP selbst bauen, das offizielle Release von php.net, und setzen Sie in der Zwischenzeit die Übergangsmaßnahmen weiter unten um.

Schritt 3: alles neu starten, was das alte PHP geladen hat

Ein neues Paket ändert nichts an Prozessen, die bereits laufen. Starten Sie sie neu:

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

Unter Debian und Ubuntu listet sudo needrestart -r l die Dienste auf, die noch alte Bibliotheken verwenden.

Schritt 4: prüfen

Prüfen Sie jede Laufzeit erneut, diesmal die, die der Webserver nutzt, nicht nur die CLI:

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

Die Version muss mindestens dem korrigierten Release entsprechen (oder das Paket-Changelog muss beide CVEs aufführen), und der Zeitpunkt bei „Active: since“ muss nach dem Update liegen. Unter WordPress können Sie die Version auch unter Werkzeuge, Website-Zustand, Bericht, Server ablesen. Stellen Sie zum Prüfen keine phpinfo()-Seite online: Sie verrät genau das, wonach Angreifer suchen.

Wenn das Update warten muss

Diese Einstellungen der Forscher verringern die Angriffsfläche, während Sie das Update vorbereiten. Sie sind kein Fix:

; 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

Die Werte sind Beispiele; testen Sie sie mit Ihrer Anwendung. memory_limit = -1 blockiert einige Angriffspfade, verwenden Sie es aber nur zusammen mit einem Limit auf Betriebssystemebene wie memory.max in cgroup v2, und ersetzen Sie dieses Limit niemals durch RLIMIT_AS oder RLIMIT_DATA. WAF- und CDN-Regeln Ihres Anbieters helfen als Überbrückung, nicht als Ersatz für das Update.

Nach Anzeichen eines Angriffs suchen

Es gibt keine einzelne Erkennungsregel. Diese Befehle bringen die Signale zutage, die die Forscher beschreiben:

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

Speicherlimit-Fehler nach ungewöhnlichen Multipart-Anfragen, gehäufte HTTP-500-Antworten, PHP-Worker, die durch Signale abstürzen, und ungewöhnlich große PHPSESSID-Cookies in Antworten verdienen einen genaueren Blick. Keines dieser Anzeichen beweist einen Angriff, und ihr Fehlen beweist nicht, dass Sie nicht betroffen waren. Wenn Sie sie finden, sichern Sie die Logs, patchen Sie und tauschen Sie die Geheimnisse aus, die im PHP-Speicher lagen: Datenbankpasswörter, Anwendungsschlüssel und API-Tokens. Unser Incident-Response-Team kann die Untersuchung übernehmen, und unser Managed-Security-Service kann Ihre Server nach dem Patch überwachen.

Wo Sie anfangen

1. Führen Sie die Inventarbefehle auf jedem Server und in jedem Container aus und notieren Sie jede PHP-Version.
2. Aktualisieren Sie mit Ihrem Paketmanager oder bauen Sie Ihre Images auf einem korrigierten Tag neu.
3. Starten Sie PHP-FPM, Apache und jeden PHP-Worker neu.
4. Prüfen Sie Version und Neustartzeit und bewahren Sie die Ausgabe als Nachweis auf.
5. Durchsuchen Sie Ihre Logs per grep nach den oben genannten Anzeichen und tauschen Sie auf jedem System, das sie zeigt, die Geheimnisse aus.

Details: PHP2Shell-Advisory-Website, Ankündigung der PHP Foundation, Wiz Research.