PHP2Shell-Schwachstellen vor öffentlicher Bekanntgabe ausgenutzt

Das Bedrohungsintelligenz-Team von Amazon entdeckte bereits am 17. Oktober 2026 aktive Ausnutzungsversuche gegen seine Honeypot-Infrastruktur, die sich auf kritische Schwachstellen im PHP-Kern richteten, bekannt als PHP2Shell. Diese Aktivitäten fanden fünf Tage vor der koordinierten öffentlichen Offenlegung der Fehler statt, was darauf hindeutet, dass Angreifer bereits Zugriff auf Exploit-Details hatten, während die Fixes noch unter Embargo standen.

Was passiert ist

Die Schwachstellen, verfolgt unter den Kennungen CVE-2026-109618 und CVE-2026-109619, tragen einen CVSS-Score von 9,2 und ermöglichen Remote Code Execution (RCE) ohne vorherige Authentifizierung. Forscher von Calif, OpenAI und Wiz entdeckten die Probleme, die jede PHP-Version in den Reihen 7.x und 8.x betreffen. Die PHP Foundation hatte die koordinierte Offenlegung ursprünglich für den 22. Oktober 2026 um 14:00 Uhr UTC geplant, verschob die Veröffentlichung jedoch um einen Tag nach vorne, nachdem Proof-of-Concept-Exploits und CVE-Identifier vorzeitig durchgesickert waren.

Amazon verzeichnete die früheste bekannte Erkundung von einer IP-Adresse, die mit einem kommerziellen Anonymisierungsnetzwerk assoziiert war und geografisch in Australien lokalisiert wurde. CJ Moses, CISO von Amazon Integrated Security, merkte an, dass zwar unklar bleibt, wie der Akteur die Informationen erhalten hat, die Nutzung anonymisierter Infrastruktur jedoch auf gezielte Bedrohungsaktivitäten statt auf zufälliges Scannen hindeutet. Nach dem Leak starteten mehrere andere Akteure innerhalb weniger Stunden nach der Patch-Veröffentlichung Angriffe mit variierenden Payloads von verschiedenen anonymisierten IPs.

Die vorzeitige Offenlegung wurde dadurch verschärft, dass Chainguard Container-Images veröffentlichte, die den Fix enthielten, bevor die offizielle Ankündigung erfolgte. Dies ermöglichte es Angreifern, den Binary-Diff zu analysieren und die Schwachstelle rückzuentwickeln, während die meisten Nutzer noch nicht über das Risiko informiert waren. Die PHP Foundation kritisierte diesen Schritt und erklärte, er habe wochenlange koordinierte Bemühungen missachtet und Angreifern einen Vorsprung bei der Entwicklung zuverlässiger Exploits gegeben.

Wie es funktioniert

Diese Fehler befinden sich in den Subsystemen für Speicherverwaltung und Fehlerbehandlung von PHP, Komponenten, die nahezu jede Anfrage verarbeiten. Da die Schwachstellen tief im Runtime-Kern liegen, sind sie nicht von bestimmten Content-Management-Systemen, Frameworks oder Plugins abhängig. Ein Angreifer kann Remote Code Execution auf jedem erreichbaren PHP-Endpunkt auslösen, einschließlich statischer Formulare, Login-Seiten und Health Checks, ohne sich authentifizieren oder eine Session stehlen zu müssen.

CrowdStrike hebt hervor, dass diese Angriffe minimale digitale Spuren hinterlassen. Da der Exploit ausgeführt wird, bevor Anwendungscode läuft, zeigen Webserver-Logs typischerweise normale HTTP-200-Antworten und stabile Worker-Prozesse. Der einzige potenzielle Indikator ist ein Fatal Error aufgrund eines Speicherlimits im Fehlerlog des Webservers, den Administratoren oft als routinemäßiges Rauschen abtun. Dieser Mangel an verwertbarer Telemetrie macht traditionelle Web Application Firewalls und Log-Monitoring für die Erkennung wirkungslos.

Wichtige Details

• Die Schwachstellen betreffen alle PHP-7.x- und 8.x-Releases und gefährden geschätzt 4,38 Millionen internetseitig exponierte Dienste.
• Ausnutzungsversuche wurden bereits am 17. Oktober 2026 erkannt, fünf Tage vor der öffentlichen Patch-Veröffentlichung.
• Angriffe hinterlassen kaum Spuren in Anwendungslogs; nur obskure serverseitige Speicherfehler dienen als potenzielle Indikatoren.
• Über 79 % der erkannten internetseitigen PHP-Dienste laufen auf nicht unterstützten Branches, was die allgemeine Angriffsfläche erhöht.
• Mehrere Bedrohungsakteure nutzten anonymisierte Netzwerke und mutierte Payloads, um anfängliche Sicherheitsvorkehrungen zu umgehen.
• Regierungsbehörden wie CISA, NCSC und NSA haben dringende Warnungen herausgegeben, um Patches einzuspielen oder Systeme offline zu nehmen.

Warum das wichtig ist

Für Software-Ingenieure und IT-Leiter stellt PHP2Shell eine schwere Herausforderung dar, da es viele Standardverteidigungsebenen umgeht. Da die Schwachstelle in der Runtime selbst existiert, bietet das Aktualisieren eines CMS-Plugins oder das Anpassen von Framework-Konfigurationen keinen Schutz. Die schiere Verbreitung von PHP, das fast 70 % aller Websites betreibt, bedeutet, dass selbst kleine, unscheinbare Dienste zu Einstiegspunkten für eine breitere Netzwerkkompromittierung werden können, wenn sie verwundbare PHP-Versionen nutzen.

Der Vorfall verdeutlicht auch eine sich verschiebende Dynamik bei der Offenlegung von Schwachstellen. Wie CJ Moses beobachtete, verkürzt KI-gestützte Analyse die Zeit zwischen Patch-Veröffentlichung und funktionierendem Exploit. Angreifer können nun schnell Binary-Diffs aus frühen Releases, wie denen von Chainguard, analysieren, um Waffen zu entwickeln, bevor die Mehrheit der Nutzer Updates installiert hat. Dies reduziert das Sicherheitsfenster, das traditionell durch koordinierte Offenlegung geboten wird, und erfordert schnellere interne Remediation-Zyklen.

Was Sie tun können

• Aktualisieren Sie sofort alle PHP-Instanzen auf die neuesten gepatchten Versionen und priorisieren Sie dabei internetseitige Server.
• Auditiere Sie Ihre Infrastruktur, um PHP-Dienste zu identifizieren, die auf End-of-Life-Branches wie 5.x, 7.4 oder 8.1 laufen.
• Implementieren Sie Prozess-Monitoring-Funktionen, um unerwartete Shell-Launches oder Datei-Downloads durch PHP-Worker zu erkennen.
• Prüfen Sie Webserver-Fehlerlogs spezifisch auf Fatal Errors aufgrund von Speicherlimits, die auf Ausnutzungsversuche hinweisen könnten.
• Verwenden Sie Tools wie den Codex-Skill von OpenAI oder hersteller-spezifische Scanner, um lokale Binaries und Websites auf Verwundbarkeit zu prüfen.
• Erwägen Sie, nicht-kritische PHP-Dienste vorübergehend offline zu nehmen, falls eine sofortige Patchung aufgrund von Kompatibilitätsrestriktionen nicht möglich ist.