PHP2Shell beheben · Patch-Anleitung
PHP2Shell beheben
Die Lösung ist ein PHP-Update plus Neustart. Keine Konfigurationsänderung, kein Plugin-Update und keine WAF-Regel ersetzt das. Befehle für jede gängige Plattform und wie Sie nachweisen, dass der Patch wirklich greift.
Zuletzt geprüft 2026-10-22
Zielversionen
8.5.12, 8.4.27, 8.3.36, 8.2.35 oder neuer — oder ein Paket Ihres OS-Herstellers, dessen Changelog CVE-2026-109618 und CVE-2026-109619 nennt. PHP 8.1 und älter erhalten kein neues Release — siehe unten.
| Branch | Anfällig | Behoben in |
|---|---|---|
| 8.5 | < 8.5.12 | 8.5.12 |
| 8.4 | < 8.4.27 | 8.4.27 |
| 8.3 | < 8.3.36 | 8.3.36 |
| 8.2 | < 8.2.35 | 8.2.35 |
| 8.1 · 8.0 · 7.4 | alle | Nur Quellcode-Backport |
| 5.4 – 7.3 | alle | Kein Fix |
1. Jede PHP-Laufzeit finden
Übersehene Laufzeiten sind der häufigste Grund, warum eine Serverflotte exponiert bleibt. Führen Sie das auf jedem Host aus.
# PHP processes running right now, and when they started
ps -eo pid,lstart,cmd | grep -E '[p]hp-fpm|[h]ttpd|[a]pache2|[f]rankenphp|[l]sphp'
# CLI and FPM can be different builds — check both
php -v
ls /usr/sbin/php-fpm* 2>/dev/null && for f in /usr/sbin/php-fpm*; do "$f" -v | head -1; done
# Is Apache running PHP in-process (mod_php)? That is the highest-risk setup.
apachectl -M 2>/dev/null | grep -i php
# PHP version inside every running container
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'
donePrüfen Sie auch Base-Images in Ihrer Registry, CI-Runner, Staging- und Preview-Umgebungen, Appliances mit eingebautem PHP und alte Server, für die sich niemand mehr zuständig fühlt. Von außen verrät curl -sI https://site | grep -i x-powered-by manchmal die Version, die meisten Seiten verbergen sie aber. Nutzen Sie die NCSC-NL-Produktübersicht für eingebettetes PHP; bestätigen Sie den Status beim Hersteller.
2. Das gepatchte Release installieren
Gilt für OS-Pakete sowie Ondřej Surýs PPA / packages.sury.org. Standardpakete von Debian/Ubuntu behalten ihre alte Upstream-Nummer und portieren den Fix zurück — entscheidend ist daher die Prüfung des Changelogs.
sudo apt update
# Upgrade only the PHP packages that are installed
sudo apt install --only-upgrade $(dpkg-query -W -f='${db:Status-Abbrev} ${binary:Package}\n' 'php*' | awk '$1=="ii"{print $2}')
# Proof the fix is in: the changelog should mention the CVE
# (replace 8.3 with your version)
apt changelog php8.3-common 2>/dev/null | grep -m1 -E 'CVE-2026-10961[89]' || echo 'NOT FIXED in this package yet'3. Alles neu starten, was PHP ausführt
Ein Paket zu installieren ersetzt Dateien auf der Platte. Laufende Prozesse führen den alten, anfälligen Code weiter aus, bis sie neu starten.
# Debian / Ubuntu (adjust the version)
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2 # if using mod_php
# RHEL family
sudo systemctl restart php-fpm httpd
# Anything still mapped to the old, deleted PHP binary needs a restart
sudo grep -l -E '(php|libphp)[^ ]* \(deleted\)' /proc/[0-9]*/maps 2>/dev/null
sudo needrestart -r l # Debian/Ubuntu helper, if installed
# Long-running PHP workers
php artisan queue:restart # Laravel queues
php artisan octane:reload # Octane (Swoole / RoadRunner / FrankenPHP)
sudo supervisorctl restart all # supervisor-managed workers4. Aus Sicht des Webservers prüfen
# Version of the FPM binary that actually serves traffic
php-fpm8.3 -v 2>/dev/null || php-fpm -v
# Compare process start times with when you upgraded
ps -o pid,lstart,cmd -C php-fpm8.3,php-fpm,apache2,httpd
# Ask the web server itself (use a random name, delete straight after)
F="v-$(openssl rand -hex 8).php"
echo '<?php echo PHP_VERSION;' | sudo tee /var/www/html/$F >/dev/null
curl -s https://your-site.example/$F; echo
sudo rm /var/www/html/$FNeues Verhalten nach dem Patch
Der Fix ersetzt den Abbruch bei OOM durch ein weiches Limit, das an einem sicheren Punkt geprüft wird, plus ein zweites, höheres hartes Speicherlimit, das den Prozess sofort per _exit() beendet. Wird das harte Limit erreicht, laufen Shutdown-Funktionen und Destruktoren nicht. Erledigt Ihre Anwendung Arbeit in register_shutdown_function (Logging, Aufräumen), testen Sie nach dem Update speicherintensive Pfade.
Auf PHP 8.1, 8.0, 7.4 oder älter?
Diese Branches sind End-of-Life. Das PHP-Projekt liefert für sie keine Releases mehr, hat wegen der Schwere aber minimale Quellcode-Backports veröffentlicht.
- Am besten: auf PHP 8.4 oder 8.5 migrieren. Muss es schnell gehen, ist 8.3 ein kleinerer Sprung von 8.1 (8.2 verliert Ende 2026 den Support).
- OS-Paket: Ubuntu (inkl. Ubuntu Pro / ESM), Debian LTS, RHEL und andere LTS-Anbieter erhielten die Patches vorab. Prüfen Sie wie oben das Changelog Ihres Pakets auf die CVE.
- Aus dem Quellcode bauen: die Backport-Branches des PHP-Teams — PHP 8.1, PHP 8.0, PHP 7.4. Sie beheben nur diese beiden CVEs; der Branch bleibt ohne Support.
- Ältere Zweige: unterhalb dieses Bereichs ist kein Quellcode-Backport des PHP-Projekts aufgeführt. Distributoren können dennoch Fixes liefern: Ubuntu bestätigt gepatchte Pakete, auch für ältere Zweige über Pro / ESM. Prüfen Sie beide CVEs und starten Sie Worker neu; ohne gepatchten Build den Host isolieren und migrieren.
5. Danach
- Entfernen Sie temporäre Workarounds, die die Leistung bremsen, etwa
pm.max_requests = 1odermemory_limit = -1, und kehren Sie zu sinnvollen Limits zurück. - Suchen Sie nach Spuren früherer Ausnutzung: Erkennungs-Anleitung. Ein Patch macht eine Kompromittierung nicht rückgängig.
- Auf PHP 8.2? Der Security-Support endet am 2026-12-31. Planen Sie den Wechsel auf 8.4 oder 8.5 jetzt, solange der Update-Weg frisch ist.
Verwandte Seiten
- Versions-CheckerPHP2Shell-Versionsprüfung: Ausgabe von php -v oder Versionsliste einfügen und anfällige, gepatchte oder veraltete PHP-Builds und Backports erkennen.
- WorkaroundsTemporäre PHP2Shell-Workarounds: Speicher- und Upload-Limits, Upload-Progress, Backtraces und cgroups. Wirkung, Grenzen und Nebenwirkungen.
- Hosting-AnbieterPHP2Shell bei Shared- und Managed-Hosting: PHP-Versionen in cPanel oder Plesk prüfen und wechseln, Anbieter-Updates und Fragen an Ihren Hoster.
- ErkennungPHP2Shell-Angriffe erkennen: Warnsignale, Log-Suchen, Herstellererkennungen und nächste Schritte bei Hinweisen auf eine Kompromittierung.
- Cloudflare WAFCloudflare WAF gegen PHP2Shell: Regel-IDs für Free- und Bezahlpläne, aktive Sperren prüfen und warum PHP weiterhin gepatcht werden muss.
- session.upload_progressStoppt das Abschalten von session.upload_progress PHP2Shell? Erfahren Sie, was es abwehrt, wo Sie es setzen, prüfen und welche Dienste neu starten.