[Alert] PHP2Shell: Kritische PHP-RCEs – jetzt patchen und Angriffsspuren prüfen

22. Oktober 2026, 09:36 Uhr · Quelle: Pressebox

PHP schließt zwei kritische Sicherheitslücken, die Remote-Code-Execution ermöglichen. Betreiber sollten Systeme umgehend aktualisieren und auf Angriffsspuren prüfen.

Baar, 22.10.2026 (PresseBox) - Am Dienstagnachmittag hat das PHP-Projekt Notfall-Patches für zwei kritische Remote-Code-Execution-Schwachstellen veröffentlicht: CVE-2026-109618 und CVE-2026-109619 (je CVSS v4.0 9.2). Die wichtigsten Hintergründe und was Sie jetzt tun sollten, erfahren Sie in diesem Beitrag.

Kritische PHP-Schwachstellen bedrohen weltweit Webseiten

Die Lücken waren einen Tag vor dem Embargo geleakt worden. Cloudflare berichtet von Angriffsverkehr bereits vor dem Patch. Mit öffentlichen Advisories, Research-Writeups und Exploit-Tooling ist eine aktive Ausnutzung durchaus realistisch. Beide Fehler sitzen in der PHP-Engine, nicht in der Applikation. Somit können auch Anwendungen mit sicher programmiertem Code von den Schwachstellen betroffen sein.

Das Wichtigste auf einen Blick: Was Sie jetzt tun sollten

Inventarisieren: Jede PHP-Installation erfassen, inklusive Appliances, Windows-Bundles (php.exe / php-cgi.exe), Container und Hosting-Panels. Version, SAPI (mod_php, FPM, CGI usw.) und Erreichbarkeit aus dem Internet dokumentieren.
Patchen: Auf 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 aktualisieren (oder Distro-/Hosting-Backport einspielen) und alle PHP-Worker neu starten. Zuerst öffentlich erreichbare Systeme patchen. Apache mod_php weist laut PHP das höchste Risiko auf.
End-of-Life (≤ 8.1): Für diese Versionen gibt es keine offiziellen Sicherheitsupdates. Upgrade, Vendor-/LTS-Backport, minimale PHP-Source-Backports für 7.4/8.0/8.1 oder Systeme vom Internet nehmen.
Falls ein Patch heute nicht möglich ist: PHP-Zwischenmassnahmen umsetzen (memory_limit=-1 und session.upload_progress.enabled=0 administrativ setzen; bei PHP 8.5 zusätzlich fatal_error_backtraces=0), niedrige post_max_size- bzw. Proxy-Limits konfigurieren und Worker neu starten. Diese Massnahmen reduzieren die Angriffsfläche, ersetzen aber keinen Patch.
Sichtbarkeit sicherstellen: Alarme für Webserver- und PHP-Prozesse einrichten, die Shells, Interpreter oder Download-Tools starten. Ausgangszustand der Webroot-Verzeichnisse erfassen.
Bei Verdacht zuerst Beweise sichern: Patches und Neustarts können flüchtige Spuren zerstören.

php2shell: Was bisher bekannt ist

Dienstag, 20. Oktober 2026: Informationen zu den Schwachstellen werden auf Hacker News veröffentlicht (später gelöscht); watchTowr bestätigt die Lücken; PHP kündigt ein Security-Release an; CERT-EU veröffentlicht Advisory 2026-018.
Mittwoch, 21. Oktober 2026, früher Vormittag: Cloudflare veröffentlicht WAF-Regeln und berichtet von ersten Angriffsbeobachtungen.
Mittwoch, 21. Oktober 2026, 16:00 Uhr: PHP veröffentlicht die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 inklusive Security Advisory und zwei GitHub-Advisories.

Betroffen sind laut PHP alle Versionen unterhalb der genannten Fix-Releases. Cloudflare und Sansec datieren relevante Codepfade bis PHP 5.4.0 zurück. Gefährdet sind Installationen, die Web-Requests verarbeiten: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed. Forschende nennen unter anderem Magento, WordPress, Drupal, Joomla, Nextcloud, Laravel und Symfony als betroffene Anwendungen beziehungsweise Frameworks. Entscheidend ist: Auch eine fehlerfrei entwickelte Applikation kann betroffen sein.

Technischer Hintergrund: So funktionieren die Schwachstellen

Beide CVEs entstehen, weil PHP nach einem Fatal Error, häufig aufgrund von Speichererschöpfung (OOM), einen Request nicht sicher bereinigt:

CVE-2026-109618 («OOM corruption»): Beim Erreichen des Memory-Limits bricht PHP abrupt ab. Nur teilweise initialisierte Request-Daten werden während des Shutdowns als gültig behandelt. Das Parsing von Multipart-Bodys kann einen Request in einen OOM-Zustand versetzen, obwohl er innerhalb der konfigurierten Limits zu liegen scheint. Unter mod_php geschieht dies bereits beim Request-Start, bevor Anwendungscode ausgeführt wird.
CVE-2026-109619 («stale global state»): Globale Worker-Zustände verweisen weiterhin auf Speicher des vorherigen Requests. Nach einem Fatal Error oder einer Warnung ohne korrektes Zurücksetzen entsteht ein Use-after-free über mehrere Requests hinweg. Bestätigte Angriffspfade sind Session-Upload-Progress (standardmässig aktiv, auch ohne session_start()) und bei PHP 8.5 Fatal-Error-Backtraces. Auch frühe Warnungen durch Request-spezifische INI-Einstellungen (.htaccess php_value, PHP_VALUE bei FPM) können dazu beitragen.

Auswirkungen laut PHP: Nicht authentifizierte Angreifer können Code im Kontext des Web-Workers ausführen und Speicherinhalte auslesen (Memory Disclosure). Auf eine detaillierte Beschreibung der Exploit-Mechanik verzichten wir bewusst.

Priorisierung: Zuerst mod_php, danach FrankenPHP, FPM, LiteSpeed und php-cgi. Alles, was multipart/form-data verarbeitet, stellt eine potenzielle Angriffsfläche dar. Das Deaktivieren von Upload-Progress allein reicht nicht aus, da dies nur einen der Angriffspfade von CVE-2026-109619 betrifft.

Patches und Übergangsmassnahmen: So schützen Sie Ihre Systeme

Unterstützte PHP-Versionen: Auf die vier korrigierten Versionen aktualisieren oder entsprechende Distributions-Backports einspielen. Dabei die CVE-IDs im Changelog prüfen, da Backports häufig die ursprüngliche Versionsnummer beibehalten.
Remi-Repository: PHP weist darauf hin, dass rpms.remirepo.net zum Zeitpunkt der Veröffentlichung noch keine Updates bereitstellt. Gegebenenfalls auf Distributionspakete oder den Quellcode ausweichen.
End-of-Life-Versionen: Betroffene Systeme isolieren oder aktualisieren. WAF-Regeln lediglich als vorübergehende Schutzmassnahme einsetzen. Cloudflare weist darauf hin, dass der Request allein für eine zuverlässige Erkennung häufig nicht ausreicht.
Offizielle PHP-Zwischenmassnahmen: Diese reduzieren die Angriffsfläche, beheben aber nicht die Schwachstellen. memory_limit=-1 administrativ und nicht überschreibbar setzen, session.upload_progress.enabled=0 konfigurieren, bei PHP 8.5 zusätzlich fatal_error_backtraces=0 setzen, post_max_size niedrig halten und gegebenenfalls Multipart-Requests am Proxy blockieren. Veraltete Request-spezifische PHP-Einstellungen entfernen. RLIMIT_AS und RLIMIT_DATA nicht als Speicherbegrenzung verwenden, da dies laut PHP den verwundbaren Codepfad auslösen kann. Anschliessend alle Worker neu starten.
Ohne Patch oder wirksame Übergangsmassnahmen: Öffentlich erreichbare Anwendungen vorübergehend offline nehmen, wie CERT-EU empfiehlt. Ein Application-Maintenance-Mode reicht nicht aus, da PHP den Request bereits zuvor verarbeitet.

Threat Hunting: Angriffsspuren und Hinweise auf eine Kompromittierung

Mögliche Hinweise auf php2shell-Angriffsversuche (gemäss Advisories und Research; einzeln betrachtet häufig wenig aussagekräftig, deshalb nach Client-IP und Zeit korrelieren):

Multipart-POST-Requests, gefolgt von Memory-Limit-Fehlern («Allowed memory size … exhausted») oder gehäuften HTTP-500-Fehlern
Ungewöhnlich grosse oder fehlerhaft formatierte PHPSESSID-Cookies in Responses (Hinweis auf Memory Disclosure, auch ohne RCE)
Ungewöhnlich häufige Worker-Neustarts oder -Abstürze: php-fpm-Child-Prozesse beenden sich, Apache-Segfaults (AH00052)
Deprecation-Warnungen oder andere Warnmeldungen, bevor Anwendungsskripte ausgeführt werden (Request-spezifische INI-Einstellungen)

Schwachstellenunabhängige Hinweise auf eine erfolgreiche Kompromittierung (besonders aussagekräftige Signale laut Praxis und Threat Hunting/Florian Roth):

PHP- oder Webserver-Prozesse starten sh, bash, cmd, powershell, curl, wget, nc oder andere Interpreter und Download-Tools
Neue oder veränderte .php-Dateien in Upload-Verzeichnissen und Webroots
Unerwartete ausgehende Verbindungen vom PHP-Benutzerkonto
Hinweise auf Persistenz über Cron, systemd, authorized_keys, auto_prepend_file oder Windows Tasks/Services

Nutzen Sie Ihre vorhandenen EDR-/SIEM-Abfragen für das Szenario «Web-Worker startet Shell» unter Windows und Linux. Keine Treffer sind jedoch kein Sicherheitsbeweis: PHP weist darauf hin, dass Fehler auftreten können, bevor eine Protokollierung erfolgt.

Kompromittierungsverdacht: So gehen Sie vor

System isolieren und Beweismittel sichern: Netzwerkverbindungen unterbrechen, ohne potenzielle Spuren vorschnell zu zerstören. Nicht einfach «patchen und hoffen».
Flüchtige Daten zuerst sichern: Prozessbaum inklusive Kommandozeilen, offene Netzwerkverbindungen und Speicherabbild erfassen. Anschliessend Logs sichern (Access, Error, FPM, Journal, WAF/CDN).
Webroot sichern: Dateien inklusive Hash-Werten erfassen, einschliesslich Upload-Verzeichnissen, /tmp und /dev/shm. Mit dem letzten Deployment beziehungsweise Git-Stand vergleichen.
Umfang der Kompromittierung bestimmen: Den Zeitpunkt der ersten erkennbaren bösartigen Aktivität so weit zurückverfolgen, wie es die verfügbaren Logs erlauben. Nicht erst ab dem Leak-Datum suchen.
Zugangsdaten und Secrets rotieren: Alle Zugangsdaten erneuern, auf die der PHP-Prozess zugreifen konnte (Datenbank, API, SMTP, APP_KEY, Cloud-Credentials). Dies gilt auch bei Memory Disclosure ohne eindeutigen RCE-Nachweis.
Systeme vertrauenswürdig wiederherstellen: Einen Neuaufbau aus einem nachweislich vertrauenswürdigen Image beziehungsweise Codebestand bevorzugen. Daten aus Backups wiederherstellen, Anwendungscode hingegen aus einer vertrauenswürdigen Quelle beziehen.

Fazit: Jetzt patchen und gezielt nach Angriffsspuren suchen

php2shell zeigt einmal mehr, welche Risiken durch unvollständige Systeminventare, veraltete PHP-Versionen und mangelnde Sichtbarkeit auf Webservern entstehen.

Patchen Sie Ihre betroffenen Systeme umgehend und prüfen Sie anschliessend gezielt auf mögliche Angriffsspuren. Dokumentieren Sie dabei auch bisher unbekannte oder übersehene PHP-Installationen.

Bei Verdacht auf eine Kompromittierung steht Ihnen das erfahrene Incident-Response-Team von InfoGuard 24/7 zur Verfügung. Wir sind gerne für Sie da!

Incident melden