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.

BranchAnfälligBehoben in
8.5< 8.5.128.5.12
8.4< 8.4.278.4.27
8.3< 8.3.368.3.36
8.2< 8.2.358.2.35
8.1 · 8.0 · 7.4alleNur Quellcode-Backport
5.4 – 7.3alleKein 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.

shell
# 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'
done

Prü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.

shell
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.

shell
# 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 workers

4. Aus Sicht des Webservers prüfen

shell
# 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/$F

Neues 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.

  1. 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).
  2. 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.
  3. 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.
  4. Ä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 = 1 oder memory_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