newsonline24

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

1. 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.
2. 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.
3. 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.
4. 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.
5. Sichtbarkeit sicherstellen: Alarme für Webserver- und PHP-Prozesse einrichten, die Shells, Interpreter oder Download-Tools starten. Ausgangszustand der Webroot-Verzeichnisse erfassen.
6. 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

1. System isolieren und Beweismittel sichern: Netzwerkverbindungen unterbrechen, ohne potenzielle Spuren vorschnell zu zerstören. Nicht einfach «patchen und hoffen».
2. Flüchtige Daten zuerst sichern: Prozessbaum inklusive Kommandozeilen, offene Netzwerkverbindungen und Speicherabbild erfassen. Anschliessend Logs sichern (Access, Error, FPM, Journal, WAF/CDN).
3. Webroot sichern: Dateien inklusive Hash-Werten erfassen, einschliesslich Upload-Verzeichnissen, /tmp und /dev/shm. Mit dem letzten Deployment beziehungsweise Git-Stand vergleichen.
4. 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.
5. 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.
6. 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

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