PHP2Shell: Zwei kritische PHP-Lücken — was jetzt zu tun ist

/01Was bekannt ist

Beide Fehler sitzen im Interpreter selbst, nicht in einem Framework oder Plugin. WordPress, Drupal, Magento, Laravel und Eigenentwicklungen sind deshalb gleichermaßen betroffen, sobald PHP Anfragen aus dem Internet verarbeitet. Das PHP-Projekt beschreibt die Lücken in zwei Sicherheitshinweisen:

• CVE-2026-109618 („RCE via OOM corruption“): Läuft PHP beim Einlesen einer Anfrage in einen Speichermangel, während die Anfragedaten erst halb aufgebaut sind, verarbeitet das Aufräumen am Ende ungültige Daten. Hauptweg ist das Zerlegen von Multipart-Formularen.
• CVE-2026-109619 („RCE via stale global state“): Nach einem fatalen Fehler kann globaler Zustand eines Worker-Prozesses auf bereits freigegebenen Speicher zeigen (Use-after-free). Eine spätere Anfrage an denselben Worker liest ihn — unter anderem über den Session-Upload-Fortschritt, der standardmäßig eingeschaltet ist.

Betroffen sind alle Versionen unterhalb der Fix-Stände. Am höchsten schätzt das PHP-Projekt das Risiko bei mod_php ein, also PHP als Apache-Modul: Dort ist ein Exploit vorgeführt worden, der greift, bevor überhaupt Anwendungscode läuft. PHP-FPM ist laut den Hinweisen für die zweite Lücke bestätigt anfällig, für die erste nach Code-Analyse. Kommandozeile, Cronjobs und Queue-Worker ohne HTTP-Eingang sind über die beschriebenen Wege nicht erreichbar.

Wird die Lücke schon ausgenutzt?

Die Angaben gehen auseinander. Das BSI meldet in seiner Warnung keine bestätigten Angriffe, aber unbestätigte Berichte über Exploits. Aikido schreibt, es werde Ausnutzung „in freier Wildbahn“ berichtet; Patchstack meldet laut hol.org aktive Angriffe bei mehreren Hosting-Partnern. JFrog und Huntress sahen bis zum Nachmittag dagegen keine breite Ausnutzung. Für die Entscheidung spielt das keine Rolle: Bei einer CVE dieser Schwere ohne Anmeldung wartet man nicht auf die Bestätigung.

/02Sofortmaßnahme: patchen

Das BSI empfiehlt, die Updates unverzüglich einzuspielen, und nennt keinen Workaround. Die Fix-Versionen je Zweig:

Wer PHP aus den Paketquellen der Distribution bezieht, sieht diese Nummern oft nicht. Debian, Ubuntu und Red Hat übernehmen Sicherheitskorrekturen in ihre eigene Paketversion, ohne die PHP-Versionsnummer zu ändern. Ubuntu etwa liefert den Fix für 24.04 als 8.3.6-0ubuntu0.24.04.13. Maßgeblich ist deshalb der Changelog des Pakets.

Prüfskript: welche Server betroffen sind

Für Linux-Server stellen wir ein freies Prüfskript bereit: php2shell.sh (MIT-Lizenz). Es findet alle PHP-Installationen samt PHP-FPM, mod_php, CGI und den PHP-Versionen gängiger Verwaltungsoberflächen (Plesk, cPanel, DirectAdmin u. a.), prüft den Fix über Versionsnummer und Paket-Changelog, erkennt Dienste, die nach einem Update noch nicht neu gestartet wurden, sieht in Docker- und Podman-Container und sucht nach typischen Spuren einer Kompromittierung. Der Modus check liest nur; die Übergangsmaßnahme setzt es erst nach Rückfrage und mit Sicherung, und sie lässt sich vollständig zurücknehmen.

# herunterladen und Prüfsumme vergleichen
curl -fsSLO https://www.hostspezial.de/downloads/php2shell.sh
sha256sum php2shell.sh
# 9181f974f6997582e534d59e17ce88f8e169890c70cf3df4f5d5fc410d408b78

# nur prüfen (ändert nichts)
sudo bash php2shell.sh check

# Übergangsmaßnahme erst ansehen, dann setzen – bzw. wieder entfernen
sudo bash php2shell.sh mitigate --dry-run
sudo bash php2shell.sh mitigate
sudo bash php2shell.sh rollback

Das Skript schließt die Lücke nicht. Es zeigt, wo sie offen ist, und überbrückt auf Wunsch die Zeit bis zum Update. Mit --json liefert es das Ergebnis maschinenlesbar für das Monitoring. Nutzung auf eigene Verantwortung.

Debian und Ubuntu

# Updates einspielen
apt update
apt list --upgradable 2>/dev/null | grep -i php
apt install --only-upgrade 'php*'

# Ist der Fix im installierten Paket? (Paketname an die eigene Version anpassen)
apt changelog php8.3-fpm 2>/dev/null | grep -E 'CVE-2026-10961[89]'

# Laufende Prozesse neu starten, sonst läuft der alte Code weiter
systemctl restart php8.3-fpm      # bei PHP-FPM
systemctl restart apache2         # bei mod_php

RHEL, AlmaLinux, Rocky

Dieselben Befehle gelten für AlmaLinux und Rocky Linux.

# Betrifft das installierte System eine der beiden CVEs?
dnf updateinfo list --cve CVE-2026-109618
dnf updateinfo list --cve CVE-2026-109619

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

systemctl restart php-fpm
systemctl restart httpd           # bei mod_php

Zwei Stolpersteine aus den ersten Stunden: Das Remi-Repository hatte laut Aikido am Veröffentlichungstag noch keine Updates — wer daraus installiert, muss nachprüfen, statt sich auf dnf update zu verlassen. Und Container-Images: Auch dort kann ein korrigiertes Image die alte Versionsnummer im Tag tragen. Nach dem Neubau gehört der Container neu gestartet, nicht nur das Image gezogen.

/03Wenn der Patch nicht sofort geht

Für Systeme, die erst nach einem Test oder in einem Wartungsfenster aktualisiert werden können, kursieren Einstellungen, die die bekannten Angriffswege verengen. Das PHP-Projekt nennt sie selbst — mit dem ausdrücklichen Zusatz, dass sie die Angriffsfläche verkleinern, eine Installation aber nicht sicher machen. Sie sind eine Brücke für Stunden, kein Ersatz für den Patch.

; gegen CVE-2026-109619
session.upload_progress.enabled = 0
fatal_error_backtraces = 0        ; nur PHP 8.5

; gegen CVE-2026-109618
post_max_size = 8M                ; so niedrig, wie die Anwendung erlaubt
; memory_limit = -1               ; siehe Zielkonflikt unten

Dazu kommen Größenlimits am vorgeschalteten Webserver oder Proxy, etwa client_max_body_size bei nginx. Wer gar keine Datei-Uploads braucht, kann Multipart-Anfragen dort ganz abweisen — und zwar für alle HTTP-Methoden, denn PHP 8.4 liest Multipart-Daten auch außerhalb von POST.

In Community-Anleitungen taucht zusätzlich session.use_strict_mode = 1 auf. Die Einstellung ist ohnehin sinnvoll, steht aber nicht in den Sicherheitshinweisen des PHP-Projekts als Gegenmaßnahme.

Die Grenzen

• memory_limit = -1 nimmt dem Speichermangel den Auslöser, ist laut PHP-Projekt aber unvollständig, weil ein fehlgeschlagener Speicherabruf beim Betriebssystem denselben Fehlerpfad erreicht. Und es hebt jedes Speicherlimit auf: Eine einzige Anfrage kann dann den Server auslasten. Das tauscht eine Lücke gegen ein Ausfallrisiko.
• Umgehungen werden erwartet. JFrog prüfte am Veröffentlichungstag noch, ob die Einstellungen alle Wege abdecken; GMO Flatt hielt sie laut The Hacker News für unvollständig. PHP-Kernentwickler sagen dort ebenso deutlich: Der einzige echte Schutz ist das Update.
• Die Einstellung muss dort gelten, wo der Verkehr ankommt. Sie gehört in die php.ini der laufenden SAPI oder in den FPM-Pool, nicht in .user.ini und nicht per ini_set(). Die CLI-Konfiguration ist eine andere Datei.

# Welche Werte sieht PHP-FPM wirklich? (nicht php -i: das ist die CLI)
php-fpm8.3 -i | grep -E 'upload_progress.enabled|post_max_size|memory_limit'

# Im FPM-Pool erzwingen, z. B. /etc/php/8.3/fpm/pool.d/www.conf
php_admin_flag[session.upload_progress.enabled] = off

systemctl reload php8.3-fpm

Am sichersten prüft man im Web-Kontext selbst: eine phpinfo()-Seite kurz aufrufen und danach sofort wieder löschen.

/04Härtung: Folgeschäden begrenzen

Eine ehrliche Vorbemerkung: Keine der folgenden Maßnahmen verhindert eine Codeausführung, die aus einem Speicherfehler im Interpreter entsteht. Sie bestimmen, wie weit ein Angreifer danach kommt. Genau das entscheidet, ob aus einem Treffer eine verlorene Website oder ein verlorenes Netz wird. Diese Maßnahmen sind auf jedem Linux-Webserver unabhängig von PHP2Shell sinnvoll und gehören in jedes Patch-Management-Konzept.

Pro Website ein eigener Pool, ein eigener Benutzer

Jede Website läuft in einem eigenen FPM-Pool unter einem eigenen Systembenutzer mit minimalen Rechten. Der Code gehört einem anderen Benutzer und ist für den Webprozess nur lesbar; schreiben darf er nur in Upload- und Cache-Verzeichnisse. In Upload-Verzeichnissen wird PHP nicht ausgeführt.

; FPM-Pool je Website
user = kunde1
group = kunde1
php_admin_value[open_basedir] = /var/www/kunde1/:/tmp/
php_admin_value[disable_functions] = exec,shell_exec,system,passthru,popen,proc_open,pcntl_exec
php_admin_flag[allow_url_include] = off

# nginx: keine PHP-Ausführung im Upload-Verzeichnis
location ~* ^/uploads/.*\.php$ { deny all; }

disable_functions bremst einfache Webshells, die Systembefehle absetzen. Wer nativen Code im Prozess ausführt, umgeht die Sperre. Vor dem Setzen prüfen, ob die Anwendung eine der Funktionen braucht — Vorschaubilder über ffmpeg, Bild- oder Backup-Plugins tun das häufig. Die Einstellung greift nur in der php.ini oder per php_admin_value im Pool. In der php.ini außerdem expose_php = Off.

Den Dienst selbst einsperren

systemd kann PHP-FPM ohne Codeänderung einschränken. Die Werte vor dem Ausrollen testen, manche Anwendungen schreiben an unerwartete Orte.

# systemctl edit php8.3-fpm
[Service]
ProtectSystem=full
ProtectHome=true
PrivateTmp=true
NoNewPrivileges=true

Wo verfügbar, ergänzen AppArmor oder SELinux das Profil. Ebenso wirksam ist Egress-Filterung: Ein Webserver braucht selten beliebige ausgehende Verbindungen. Wer nur die nötigen Ziele erlaubt, erschwert Reverse Shells und das Nachladen von Werkzeugen.

WAF und Überwachung

Eine Web Application Firewall oder ein Reverse Proxy mit Regeln gegen die bekannten Muster ist eine zusätzliche Schicht. Cloudflare hat Notfallregeln ausgerollt; der eigene CTO nennt sie eine Überbrückung, keine Lösung. Wichtiger ist, dass ein Treffer auffällt: Kindprozesse wie sh, bash, curl oder wget unter php-fpm oder apache2 sind im Normalbetrieb selten, und neue .php-Dateien im Webverzeichnis ebenso. Beides lässt sich in einem SIEM als Alarm abbilden und von einem SOC rund um die Uhr auswerten; ein EDR-Agent auf dem Server erkennt solche Prozessketten ebenfalls.

/05Kompromittierung prüfen

War ein System vor dem Patch erreichbar, lohnt ein Blick, ob jemand schneller war. Die folgenden Prüfungen sind ein Anfang, kein Nachweis der Sauberkeit.

# Neue oder geänderte PHP-Dateien seit dem 20.10.2026
find /var/www -name '*.php' -newermt '2026-10-20' -ls

# Shells oder Downloader unter dem Webbenutzer
ps -eo pid,ppid,user,etime,cmd --forest | grep -E -B2 'sh -c|bash|curl|wget' | grep -E 'www-data|apache|nginx|php'

# Cronjobs des Webbenutzers
crontab -l -u www-data 2>/dev/null

# Häufungen von Speicherfehlern und 500ern im Log
grep -c 'Allowed memory size' /var/log/php*-fpm.log 2>/dev/null

Aikido nennt weitere Hinweise: auffällige Multipart-Anfragen, kurz darauf Speicherfehler oder Fehler 500, übergroße PHPSESSID-Cookies und Worker-Prozesse, die ohne erkennbaren Grund neu starten. Im CMS gehören neu angelegte Administratorkonten auf die Liste.

Eine Webshell auf einem Webserver ist oft nur der erste Schritt — der Weg ins interne Netz und zu Ransomware ist von dort nicht weit. Bei einem begründeten Verdacht gilt das System als kompromittiert. Es wird isoliert, nicht nur gepatcht. Zugangsdaten, die auf ihm lagen — Datenbank, API-Schlüssel, SMTP, Deploy-Schlüssel — werden gewechselt. Für die ersten Schritte hilft ein vorbereiteter Incident-Response-Ablauf.

/06Checkliste zum Abhaken

• Alle Server mit PHP-Webanwendungen erfasst, auch Test- und Altsysteme
• Prüfskript php2shell.sh check auf jedem Linux-Server ausgeführt, Gesamturteil notiert
• PHP-Version und Paketquelle je Server bekannt (Distribution, Remi, Container, selbst gebaut)
• Update eingespielt; Fix im Paket-Changelog über die CVE-Nummern nachgewiesen
• PHP-FPM bzw. Apache neu gestartet, Container neu ausgerollt
• Wo der Patch warten muss: Übergangseinstellungen in der richtigen SAPI gesetzt und im Web-Kontext geprüft
• Systeme mit PHP 8.1 und älter: Upgrade-Termin festgelegt; PHP 8.2 bis Ende 2026 eingeplant
• Neue PHP-Dateien, Prozesse und Cronjobs des Webbenutzers geprüft
• Bei Verdacht: System isoliert, Zugangsdaten gewechselt
• Härtung (eigene Pools, Upload-Verzeichnisse, Egress, Überwachung) als Aufgabe für die nächsten Wochen eingeplant

/07Häufige Fragen