Das neueste Update​​ 

Die Insikt Group hat eine TTP-Instanz für PHP2Shell veröffentlicht, die öffentliche Proof-of-Concept (PoC)-Exploits, beobachtete Exploit-Aktivitäten und empfohlene Minderungsmaßnahmen abdeckt. Stand 19 Uhr UTC am 21. Oktober 2026:​​ 

• Patch-Status: PHP veröffentlichte am 21. Oktober 2026 korrigierte Versionen: PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12.​​ 
• Ausbeutungsstatus: Obwohl es einige Berichte über neue Ausbeutungsversuche gibt, die auf PHP2Shell abzielen, stellt die verfügbare Berichterstattung nicht das volle Ausmaß der erfolgreichen Ausbeutung oder bestätigte Kompromiss fest (1, 2).​​ 
• PoC-Status: Öffentlich verfügbare Repositories behaupten, PHP2Shell-Proof-of-Concept (PoC)-Exploits bereitzustellen, wobei deren Effektivität und Beziehung zur bestätigten Sicherheitslücke variieren. Zum Beispiel veröffentlichte der Sicherheitsforscher J4ck3LSyN zwei angebliche PoCs, widerlegte jedoch anschließend die Theorie des gecachteten Zeiger-UAFs, die ihren vorgeschlagenen Ausnutzungssequenzen zugrunde lag.​​ 

Wie es begann​​ 

Am 20. Oktober 2026 kündigte das PHP-Sicherheitsteam eine Out-of-Band-Sicherheitsversion für den 21. Oktober um 14:00 UTC an, um zwei kritische Sicherheitslücken zu beheben, beide mit einer Bewertung von 9,2 unter CVSS v4.0. PHP hielt zunächst technische Details und betroffene Versionen zurück, bis eine koordinierte Offenlegung erfolgte, und warnte, dass die Veröffentlichung beschleunigt werden könnte, falls Sicherheitslücke-Details durchsickern oder eine Ausnutzung ans Licht kommen.​​ 

Vor der geplanten Veröffentlichung berichtete watchTowr, CVE-2026-109618 reproduziert zu haben, und bewertete, dass beide Sicherheitslücken die Fernausführung von Code (RCE) ermöglichen könnten. Technische Informationen wurden anschließend vor koordinierter Offenlegung durchgesickert, was die Besorgnis über eine mögliche Ausnutzung verstärkte. PHP veröffentlichte die Fixes am 21. Oktober, zusammen mit einem Beitrag der PHP Foundation über die Veröffentlichung, der die Notfallversion und Verbesserungen der PHP-Sicherheitsprozesse behandelte.​​ 

Der Name "PHP2Shell" stammt von Wiz Research, die die Schwächen von Calif und OpenAI entdeckt und im August an PHP gemeldet haben. Wiz' Bericht behandelt die Entdeckung und die Ursache ausführlich.​​ 

Die Sicherheitslücke​​ 

Beide CVEs sind speichersichere Sicherheitslücke, bei der PHP während der Initialisierung, Fehlerbehandlung und Bereinigung der Anfragespeicher behandelt wird. Laut Wiz können Out-of-Memory-(OOM)-Fehler und ein veralteter interner Zustand freigegebenen oder teilweise initialisierten Speicher offenlegen, was möglicherweise die Speicheroffenbarung, Speicherbeschädigung und Remote Code Execution (RCE) ermöglicht.​​ 

• CVE-2026-109618: Eine OOM-bezogene Sicherheitslücke mit teilweise initialisiertem Anforderungsspeicher. Wiz identifizierte einen Use-after-Free (UAF) im Session-Upload-Progress-Unserializer und einen damit verbundenen Fehler, der PHP-Arbeitsspeicher offenbaren kann. Wiz demonstrierte unauthentifizierte RCE gegen WordPress, Drupal und Joomla.​​ 
• CVE-2026-109619: Eine veraltete Sicherheitslücke mit PHP-Globals, die Verweise auf freigegebenen Anfragespeicher behalten. Wiz identifizierte ein UAF mit fatalen Fehler-Backtraces und einem separaten OPcache-Typverwirrungsfehler. Wiz demonstrierte unauthentifizierte RCE gegen Drupal und WordPress.​​ 

Die Sicherheitslücke wirkt sich auf PHP selbst aus, nicht auf eine bestimmte Website-Anwendung. Einige Ausnutzungspfade beinhalten die Session-Upload-Progress-Funktionalität von PHP, die laut VirusTotal seit PHP 5.4.0 existiert und standardmäßig aktiviert ist. Da die Exploitation von der PHP-Laufzeit, der Serverkonfiguration und erreichbaren Ausführungspfaden abhängt, können selbst Websites mit sicherem Anwendungscode verwundbar sein.​​ 

PHP identifizierte die folgenden betroffenen und gepatchten Versionen. Ältere, nicht unterstützte PHP-Zweige werden von diesen versionsspezifischen Korrekturen nicht abgedeckt und sollten nicht als unberührt angesehen werden.​​ 

Berichte über aktive Ausbeutung​​ 

Nach der Offenlegung der PHP2Shell Sicherheitslücke meldeten mehrere Quellen von Ausbeutungsaktivitäten in freier Wildbahn:​​ 

• Patchstack erhielt Berichte über mehrere aktive Ausnutzungen Vorfall durch Hosting-Partner bis 07:34 UTC am 21. Oktober, vor der Sicherheitsveröffentlichung von PHP.​​ 
• Cloudflare CTO Dane Knecht berichtete , frühe Angriffe auf die Sicherheitslücke beobachtet zu haben. Cloudflare setzte anschließend den Web Application Firewall (WAF) Schutz gegen bekannte Exploit-Vektoren ein.​​ 

Obwohl diese Berichte auf frühe Ausbeutungsaktivitäten hinweisen, reichen öffentlich verfügbare Beweise nicht aus, um das Ausmaß erfolgreicher Kompromiss festzustellen oder die bei beobachteten Angriffen verwendeten TTPs zu charakterisieren.​​ 

Öffentliche Proof-of-Concept-Exploits​​ 

Zahlreiche öffentliche GitHub-Repositories sind rund um PHP2Shell entstanden, darunter Projekte, die Proof-of-Concept-(PoC)-Exploits, Sicherheitslücke-Testtools und Verteidigungsressourcen bewerben. Mehrere behaupten, CVE-2026-109618 und CVE-2026-109619 durch Speicherbeschädigung TTPs darauf abzielen, verwundbare Server abzustürzen oder Remote Code Execution (RCE) zu erreichen. Einige stützen sich jedoch auf ungültige Ausnutzungstheorien, und die Existenz öffentlich zugänglichen Codes beweist nicht, dass er eine der beiden Sicherheitslücken erfolgreich ausnutzt.​​ 

Die TTP-Instanz der Insikt Group untersucht zwei PoC-Skripte, die vom Sicherheitsforscher J4ck3LSyN veröffentlicht wurden:​​ 

• poc0_109618.py: Ursprünglich vorgesehen, CVE-2026-109618 über die Sitzungs-Upload-Progress-Funktionalität von PHP auszunutzen, wobei eine vorgeschlagene Speicherbeschädigungs- TTPs verwendet wird, um Befehle auf einem verwundbaren Server auszuführen.​​ 
• poc1_109619.py: Ursprünglich vorgesehen, CVE-2026-109619 über eine verwandte TTPs aufeinanderfolgende Abschnitte einer hochgeladenen Datei auszunutzen, um ähnlich die Fernausführung von Code zu erreichen.​​ 

J4ck3LSyN widerlegte anschließend die zwischengespeicherte Pointer-Sicherheitslücke-Theorie, die diesen vorgeschlagenen Ausnutzungen zugrunde lag, TTPs jedoch separat berichtete, ein weiteres Speichersicherheitsproblem zu reproduzieren, ohne RCE nachzuweisen.​​ 

Andere öffentlich zugängliche Repositories werben mit PHP2Shell-Exploits, Sicherheitslücke-Testskripten und Demonstrationsumgebungen. Einige beschreiben weiterhin den ungültigen zwischengespeicherten Zeiger TTPs, während andere behaupten, andere andere Exploitation-Methoden zu verwenden. Zum Zeitpunkt dieser Veröffentlichung hat die Insikt Group die PoCs von J4ck3LSyN oder andere öffentlich zugängliche PoCs nicht unabhängig auf Genauigkeit oder Wirksamkeit getestet.​​ 

Maßstab und Auslegung​​ 

Zwei unabhängige Internetscans zeigen, wie viel PHP freigesetzt ist, zählen aber unterschiedlich. Modat zählt PHP-Dienste, die eine lesbare Version melden und in den 10 Tagen vor dem 20. Oktober gesehen wurden. VirusTotal zählt IP-Adressen zum 21. Oktober, einschließlich PHP-Servern, die es über Signale außer einer Versionszeichenkette identifiziert, wie die Anwendung, Session-Cookies und Framework-Header.​​ 

• Modat: 4.384.302 PHP-Dienste auf 1.886.612 einzigartigen Hosts. Etwa 79 % der Dienste mit einer lesbaren Version betreiben eine Zweigstelle, die PHP nicht mehr unterstützt, und PHP 7.4, das seit 2022 am Lebensende liegt, macht 878.761 Dienste aus, mehr als jede andere unterstützte Zweigstelle.​​ 
• VirusTotal: Etwa 5,1 Millionen IP-Adressen, die PHP ausführen, von denen nur etwa 1,1 Millionen eine Version offenlegen, sodass etwa vier von fünf diese Version verbergen. Unter denen, die ihre Version offenlegen, betreiben etwa 758.000 einen End-of-Life-Branch von 5.4 bis 8.1, verglichen mit etwa 272.000 auf einem unterstützten Branch, und allein PHP 7.4 macht etwa 187.000 aus.​​ 

Keiner der Scans zählt bestätigte verwundbare Hosts, aber beide zeigen denselben Weg: Die meisten exponierten PHP laufen auf End-of-Life-Zweigen, die keine offizielle Lösung erhalten. Scans, die auf Versionsfolgen angewiesen sind, verfehlen den Großteil der freiliegenden Oberfläche, und die neueste Version bot keinen Schutz: VirusTotal zählte etwa 85.000 IP-Adressen bei den Veröffentlichungen vom 24. September, den neuesten verfügbaren vor der Korrektur.​​ 

Warum das wichtig ist​​ 

• Millionen von Servern könnten exponiert werden: VirusTotal identifizierte etwa 5,1 Millionen IP-Adressen mit PHP, was die potenziell weitreichende Reichweite dieser Sicherheitslücke unterstreicht.​​ 
• Sogar sichere PHP-Anwendungen sind gefährdet: Die Schwachstellen können eine nicht authentifizierte Ferncodeausführung in PHP selbst ermöglichen, selbst wenn die darauf laufende Anwendung keine Sicherheitslücke hat.​​ 
• Geheimnisse können ohne Codeausführung durchsickern: Wiz zeigte, dass der Speicher-Offenlegungsfehler Passwörter, Authentifizierungstoken, API-Schlüssel und Zertifikate aus anderen Anfragen offenlegen kann.​​ 
• Das Patch-Fenster ist zusammengebrochen: Details sind Stunden vor der Veröffentlichung durchgesickert, und Sicherheitsforscher berichteten von Exploiting-Versuchen, bevor behobene Versionen verfügbar waren (1, 2).​​ 
• Viele Server laufen mit veralteten PHP-Versionen: VirusTotal stellte fest, dass die meisten PHP-Server, die ihre Versionen offenlegten, End-of-Life-Branches betrieben, die keine regelmäßigen Upstream-Sicherheitsupdates mehr erhalten.​​ 
• Kompromiss kann sich über den Webserver hinaus ausbreiten: VirusTotal fand etwa 394.000 PHP-Hosts, die auch Secure Shell (SSH) offenlegen, etwa 233.000, die MySQL bereitstellen, und etwa 68.000, die das Remote Desktop Protocol (RDP) bereitstellen.​​ 
• Logs zeigen möglicherweise wenig: Die Ausnutzung erfolgt unterhalb der Anwendungsschicht, sodass Anwendungsprotokolle begrenzten Kontext aufzeichnen können.​​ 

Zeitleiste der Ereignisse​​ 

Die Offenlegung der PHP2Shell Sicherheitslücke erstreckte sich über mehrere Wochen, beginnend mit ihrer Entdeckung im August 2026 und gipfelnd in einer Notfall-Sicherheitsfreigabe am 21. Oktober 2026. Sicherheitslücke-Details wurden jedoch vor der koordinierten Veröffentlichung öffentlich zugänglich, was zu Verteidigungsvorbereitungen und Berichten über Ausnutzungsaktivitäten führte, bevor Patches verfügbar wurden.​​ 

Die folgende Zeitleiste zeigt die wichtigsten Entwicklungen im Zusammenhang mit der Entdeckung, koordinierte Offenlegung, frühe Ausbeutungsberichte und Recorded Future's Antwort.​​ 

• 19. August 2026: Wiz Research entdeckt die erste PHP Sicherheitslücke mit KI-unterstützten Forschungstools.​​ 
• 20. August 2026: Wiz Research bestätigt die nicht authentifizierte Ferncode-Ausführung (RCE) gegen Drupal.​​ 
• 21. August 2026: Wiz Research bestätigt nicht authentifizierte RCE gegen WordPress.​​ 
• 24. August 2026: Wiz Research meldet die Sicherheitslücke privat an das PHP-Sicherheitsteam und leitet damit den koordinierten Offenlegungsprozess ein.​​ 
• 21. September 2026: Das PHP-Sicherheitsteam bestätigt die Sicherheitslücke-Berichte und beginnt, koordinierte Korrekturen zu entwickeln.​​ 
• 20. Oktober 2026: PHP kündigt eine Notfall-Sicherheitsveröffentlichung außerhalb des Bands an, die für den 21. Oktober geplant ist, um zwei kritische Sicherheitslücken zu beheben.​​ 
• 20. Oktober 2026: Die Insikt Group veröffentlicht eine erste Geheimdienstnotiz, die die bevorstehenden PHP-Sicherheitsupdates hervorhebt.​​ 
• 20. Oktober 2026: Recorded Future entwickelt Attack-Surface-Intelligence-Signaturen, um potenzielle Expositionen für CVE-2026-109618 und CVE-2026-109619 zu identifizieren.​​ 
• 21. Oktober 2026, 02:29 UTC: Ein Archiv mit geleakten Sicherheitslücke-Informationen wurde zuerst bei VirusTotal eingereicht.​​ 
• 21. Oktober 2026, 07:34 UTC: Patchstack berichtet, mehrere Stunden vor der geplanten Sicherheitsfreigabe Benachrichtigungen über mehrere aktive Ausnutzungs-Vorfall von Hosting-Partnern erhalten zu haben.​​ 
• 21. Oktober 2026, 13:52 UTC: PHP veröffentlicht Sicherheitsupdates, die beide Sicherheitslücke adressieren, vor der zuvor angekündigten Veröffentlichungszeit um 14:00 UTC.​​ 
• 21. Oktober 2026, 17:52 UTC: Insikt Group veröffentlicht eine PHP2Shell Taktiken, TTPs, TTPs (TTP) Instanz zur Unterstützung von Bedrohungserkennung und -analyse.​​ 

Bemerkenswert ist, dass Berichte über Ausnutzungsaktivitäten vor der offiziellen Sicherheitsveröffentlichung auftauchten, was eine kurze Phase schaffte, in der Sicherheitslücke-Informationen öffentlich verbreitet wurden, während betroffene Organisationen keinen offiziellen Patch hatten. Infolgedessen können PHP-Nutzer Exploiting-Versuche entdecken, die vor der offiziellen Veröffentlichung des Patches stattfanden. Bedrohungsjäger sollten daher ihre Rückblickszeit für Ausbeutungsversuche bis vor der Veröffentlichung der Sicherheitslücke-Offenlegungen verlängern.​​ 

Recorded Future unabhängiger Analysen​​ 

Recorded Future's Insikt Group analysierte die PHP2Shell Sicherheitslücke, öffentlich zugängliche Proof-of-Concept (PoC)-Exploits, gemeldete Ausnutzungsaktivitäten und Verteidigungsmaßnahmen. Das daraus resultierende TTP Instance bietet den Verteidigern technischen Kontext und umsetzbare Anleitungen, um Exposition zu bewerten, Behebung zu priorisieren und potenzielle Angriffe zu identifizieren.​​ 

• Öffentliche PoCs: Mehrere öffentlich verfügbare GitHub-Repositories behaupten, PHP2Shell-Proof-of-Concept (PoC)-Exploits bereitzustellen, die auf CVE-2026-109618 und CVE-2026-109619 abzielen. Diese PoCs konzentrieren sich darauf, PHP-Speichersicherheitslücken auszunutzen, um eine entfernte Codeausführung zu erreichen, wobei ihre Effektivität variiert und einige auf Exploitation- TTPs beruhen, die später ungültig wurden.​​ 
• Exploit-Aktivitäten: Sicherheitsanbieter haben von neuen Ausnutzungsversuchen berichtet, die auf PHP2Shell abzielen, obwohl das Ausmaß der erfolgreichen Ausnutzung weiterhin unklar ist und bestätigte Hinweise auf Kompromiss (IoCs) weiterhin begrenzt sind. Die TTP-Instanz der Insikt Group enthält potenzielle Warnsignale, die Verteidiger überwachen können, wie ungewöhnliche Webanfragen, PHP-Fehler und verdächtige Serveraktivitäten.​​ 

Was du jetzt tun musst​​ 

Organisationen, die PHP-basierte Anwendungen betreiben, sollten das Patchen verwundbarer Systeme, deren Bewertung und Überwachung auf potenzielle Ausnutzung priorisieren. Angesichts von Berichten über Ausnutzungsaktivitäten vor der koordinierten Sicherheitsfreigabe sollten Organisationen auch prüfen, ob betroffene Systeme vor der Verfügbarkeit von Patches Kompromiss gewesen sein könnten.​​ 

Insikt Group empfiehlt folgende Maßnahmen, um die mit PHP2Shell verbundenen Risiken abzumildern:​​ 

• Priorisierung von Patching und Behebung: Aktualisieren Sie betroffene PHP-Bereitstellungen auf die entsprechenden gepatchten Versionen, priorisieren Sie internetbezogene Anwendungen und kritische Infrastrukturen. Organisationen, die nicht unterstützte PHP-Versionen ausführen, sollten zu unterstützten Versionen migrieren oder von Anbietern gewartete Sicherheitsfixes erhalten. Stellen Sie sicher, dass Behebung PHP-Komponenten integriert, die in Drittanbieteranwendungen, Container und verwaltete Dienste eingebettet sind.​​ 
• Identifizieren Sie exponierte Vermögenswerte und validieren Sie Behebung: Inventarisieren Sie PHP-Implementierungen in organisatorischen Umgebungen und bewerten Sie Exposition anhand von Internetzugänglichkeit, Konfiguration und geschäftlicher Kritikalität. Recorded Future Kunden sollten Attack-Surface-Intelligence nutzen, um potenziell verwundbare Internetressourcen zu identifizieren und die Behebung-Bemühungen zu validieren.​​ 
• Implementiere kompensierende Sicherheitskontrollen: Wo sofortiges Patchen nicht möglich sind, beschränken Sie den externen Zugriff auf verwundbare Systeme und implementieren Sie anwendbaren WAF-Schutz, Anfragefilterung und PHP-Konfigurationshärtung. Stellen Sie sicher, dass Ursprungsserver nicht direkt zugänglich sind, um die Perimeterverteidigung zu umgehen. Diese Maßnahmen können Exposition auf bestimmte Ausbeutungs- TTPsreduzieren, sollten aber nicht als Ersatz für Patching betrachtet werden.​​ 
• Überwachen Sie Ausnutzung und untersuchen Sie potenzielle Kompromiss: Überprüfen Sie Telemetrie von Webservern, Anwendungen und Endpunkten auf anomale HTTP-Anfragen, PHP-Prozessfehler, unerwartete Befehlsausführung und andere Hinweise auf böswillige Aktivitäten. Priorisierung der Überprüfung der Aktivitäten ab dem 20. Oktober 2026 und Untersuchung potenzieller Kompromiss-Systeme. Wo Kompromiss identifiziert wird, leiten Sie Vorfall-Antwort-Verfahren ein und rotieren Sie potenziell exponierte Anmeldedaten.​​ 

Recorded Future-Kunden können auf die Insikt Group PHP2Shell TTP-Instanz, Validated Intelligence Event und Vulnerability Intelligence Cards® für CVE-2026-109618 und CVE-2026-109619 in der Recorded Future Intelligence Operations Platform zugreifen. Recorded Future wird weiterhin die Entwicklungen im Zusammenhang mit PHP2Shell beobachten und aktualisierte Informationen bereitstellen, sobald weitere Informationen verfügbar sind.​​ 

Die Insikt Group hält sich bei ihrer Forschung an verantwortungsvolle Offenlegungsverfahren.​​ 

Über die Insikt Group^®​​ 

Die Insikt Group von Recorded Future, die Abteilung für Bedrohungsforschung des Unternehmens, besteht aus Analysten und Sicherheitsforschern mit umfassender Erfahrung in Regierungsbehörden, Strafverfolgungsbehörden, Militär und Geheimdiensten. Ihre Mission ist es, Erkenntnisse zu gewinnen, die das Risiko für die Kunden verringern, konkrete Ergebnisse ermöglichen und Geschäftsunterbrechungen verhindern.​​ 

Verwandte Ressourcen​​ 

Entdecken Sie Experteneinblicke, Berichte und Tools, um Ihre Cybersicherheitsstrategie zu stärken.​​