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.
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.
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.
Beide CVEs entstehen, weil PHP nach einem Fatal Error, häufig aufgrund von Speichererschöpfung (OOM), einen Request nicht sicher bereinigt:
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.
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.
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.
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.
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!
Quellen:
• PHP Security Advisory & Releases 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 (21.10.2026): https://www.php.net/
• GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp
• CERT-EU Security Advisory 2026-018: https://cert.europa.eu/publications/security-advisories/2026-018
• Huntress – php2shell: https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities
• Sansec – php2shell: https://sansec.io/research/php2shell
• Cloudflare – Early attack traffic / WAF (via öffentliche Berichte vom 21.10.2026)
• Englischer Deep-Dive (Mathias Fuchs): https://medium.com/@mathias.fuchs/brace-for-impact-php2shell-114912dedeb4
Bildlegende: mit KI generiertes Bild