PHP2Shell: Zwei kritische PHP-Schwachstellen gefährden ganze Server

Die Website Ihres Unternehmens kann auf dem neuesten Stand sein, alle Plugins können abgesichert und die Zugriffsrechte korrekt konfiguriert sein. Dennoch könnten Angreifer die Kontrolle über den zugrunde liegenden Server erlangen, ohne sich anmelden zu müssen. Zwei kritische PHP-Schwachstellen, die unter dem Namen PHP2Shell zusammengefasst werden, stellen ein Sicherheitsrisiko dar, das weit über einzelne Websites hinausgeht. Neue Erkenntnisse von Amazon zeigen zudem, dass erste Angriffsversuche bereits vier Tage vor der offiziellen Veröffentlichung stattfanden.

Am 21. Oktober 2026 wurden zwei kritische Schwachstellen in der PHP-Laufzeitumgebung veröffentlicht: CVE-2026-109618 und CVE-2026-109619. Beide wurden mit einem CVSS-v4.0-Wert von 9,2 von 10 bewertet und können unter bestimmten Voraussetzungen eine Remote Code Execution (RCE) ohne vorherige Authentifizierung ermöglichen.

PHP bildet die technische Grundlage eines erheblichen Teils der Websites weltweit, darunter Onlineshops, Kundenportale und Content-Management-Systeme wie WordPress, Drupal oder Joomla. Laut den Sicherheitsforschern von Wiz wird PHP auf rund 70 % aller Websites eingesetzt. Das bedeutet jedoch nicht, dass 70 % aller Websites angreifbar sind. Das tatsächliche Risiko hängt von der eingesetzten PHP-Version, der Serverkonfiguration und den verfügbaren Sicherheitsupdates ab.

Anders als typische Schwachstellen in Webanwendungen betrifft PHP2Shell die PHP-Laufzeitumgebung selbst – nicht ein bestimmtes Plugin, CMS oder eine einzelne Anwendung. Ein WordPress-Update allein behebt das Problem daher nicht, solange der Server weiterhin eine verwundbare PHP-Version verwendet.

Wie funktioniert PHP2Shell? Ein Angriff noch vor dem Start der Anwendung

Beide Schwachstellen beruhen auf Fehlern bei der Speicherverwaltung während der Verarbeitung von HTTP-Anfragen. Die technischen Ursachen unterscheiden sich jedoch.

CVE-2026-109618 – Remote Code Execution durch fehlerhafte Speicherverwaltung

Schlägt die Speicherzuweisung während der Verarbeitung einer Anfrage fehl, können interne Datenstrukturen in PHP nur teilweise initialisiert bleiben. Bei der anschließenden Speicherbereinigung kann die Laufzeitumgebung ungültige Daten fälschlicherweise als gültig behandeln. Unter bestimmten Umständen ermöglicht dies die Ausführung beliebigen Codes.

CVE-2026-109619 – Remote Code Execution durch die Wiederverwendung ungültiger interner Zustände

Die zweite Schwachstelle entsteht, wenn interne Daten einer vorherigen Anfrage nach der Freigabe des zugehörigen Speichers weiterhin referenziert werden. Eine nachfolgende Anfrage, die vom selben PHP-Prozess verarbeitet wird, kann diesen ungültigen Zustand erneut verwenden, bevor er ordnungsgemäß initialisiert wird. Dies kann unberechtigte Speicherzugriffe oder die Ausführung von Schadcode ermöglichen.

Sicherheitsforschern gelang es, die Ausnutzung von PHP2Shell unabhängig voneinander nachzustellen. Datadog Security Labs dokumentierte einen Angriff auf CVE-2026-109618, bei dem eine speziell präparierte HTTP-Anfrage die Ausführung von Schadcode ohne Authentifizierung ermöglichte – noch bevor der eigentliche Anwendungscode ausgeführt wurde.

Genau darin liegt die besondere Gefahr von PHP2Shell: Sicherheitsmechanismen auf Anwendungsebene, einschließlich der Authentifizierung, haben unter Umständen gar keine Gelegenheit, den Angriff zu verhindern.

Eine erfolgreiche Ausnutzung kann Angreifern den Zugriff auf sensible Informationen, die Ausführung schädlicher Prozesse, die Installation von Malware oder die Nutzung des kompromittierten Servers als Ausgangspunkt für weitere Angriffe ermöglichen. Das tatsächliche Ausmaß hängt von den Berechtigungen des PHP-Prozesses und der Absicherung der umgebenden Infrastruktur ab.

Welche Rolle spielte künstliche Intelligenz bei der Entdeckung?

Nach Angaben von Wiz Research reichen einige der verwundbaren PHP-Mechanismen bis zur Version PHP 5.4 aus dem Jahr 2012 zurück.

An der Entdeckung, Analyse und koordinierten Behebung der Schwachstellen waren Sicherheitsforscher von Wiz, Calif, OpenAI und Quarkslab beteiligt. Fortschrittliche KI-Modelle unterstützten die Untersuchung komplexer Speicherabläufe, die Entwicklung funktionsfähiger Exploits und die Überprüfung der Sicherheitskorrekturen.

Laut Wiz beschleunigte der Einsatz von KI auch die Anpassung von Exploits an unterschiedliche Anwendungsumgebungen erheblich.

Diese Erkenntnisse verdeutlichen einen grundlegenden Wandel in der Cybersicherheit. Schwachstellen, deren Analyse früher umfangreiche manuelle Forschungsarbeit erforderte, lassen sich mithilfe fortschrittlicher KI-Werkzeuge möglicherweise schneller untersuchen und ausnutzen.

Für Sicherheitsteams bedeutet dies, dass sich das Zeitfenster zwischen der Veröffentlichung einer Schwachstelle und ihrer tatsächlichen Ausnutzung weiter verkürzen kann. PHP2Shell zeigt, wie wichtig schnelle Reaktionsprozesse im Schwachstellenmanagement sind.

Amazon beobachtete Angriffsversuche bereits vier Tage vor der Veröffentlichung

Neue Erkenntnisse von Amazon Threat Intelligence, die am 22. Oktober veröffentlicht wurden, zeigen, dass Angreifer bereits vor der offiziellen Bekanntgabe versuchten, PHP2Shell auszunutzen.

Amazon identifizierte den ersten Versuch am 17. Oktober 2026 über seine Honeypot-Infrastruktur MadPot. Die Aktivität ging von einer IP-Adresse aus, die einem kommerziellen Anonymisierungsdienst zugeordnet wurde.

Weitere Versuche folgten am 21. Oktober und stammten aus unterschiedlichen anonymisierten Quellen. Die Beobachtungen deuten darauf hin, dass möglicherweise mehrere Angreifer bereits vor der öffentlichen Bekanntgabe über Informationen zu den Schwachstellen verfügten.

Nach der Veröffentlichung der Sicherheitsupdates tauchten öffentlich verfügbare Exploits auf, deren Einsatz gegen die Sensoren von Amazon kurz darauf registriert wurde.

Cloudflare bestätigte unabhängig davon schädlichen Datenverkehr im Zusammenhang mit PHP2Shell, darunter auch Versuche, bestehende Sicherheitsregeln zu umgehen. Das Unternehmen stellte daraufhin zusätzliche Schutzmaßnahmen auf Ebene seiner Web Application Firewall (WAF) bereit – auch für Nutzer des kostenlosen Tarifs.

Diese Erkenntnisse sind besonders relevant, weil die ersten Angriffsversuche bereits vor der offiziellen Veröffentlichung der Schwachstellen stattfanden. Unternehmen sollten bei der Untersuchung einer möglichen Kompromittierung daher nicht nur Ereignisse nach der Bereitstellung der Sicherheitsupdates berücksichtigen, sondern auch ältere Protokolldaten auswerten.

Dabei muss jedoch zwischen beobachteten Angriffsversuchen und einer tatsächlich erfolgreichen Kompromittierung von Produktivsystemen unterschieden werden. Die Beobachtungen der Sicherheitsanbieter allein belegen noch nicht, dass Angreifer erfolgreich in konkrete Unternehmenssysteme eingedrungen sind.

Welche PHP-Versionen und Konfigurationen sind betroffen?

Das PHP-Sicherheitsteam weist auf Risiken in verschiedenen Umgebungen für den Betrieb von Webanwendungen hin. Dazu gehören Apache mit mod_php, PHP-FPM, php-cgi, FrankenPHP und LiteSpeed.

Als besonders kritisch gilt die Konfiguration Apache mit mod_php, bei der eine Ausnutzung ohne Authentifizierung noch vor der Ausführung des Anwendungscodes nachgewiesen wurde. Andere Bereitstellungsvarianten sollten jedoch ebenfalls nicht ohne entsprechende Überprüfung als sicher eingestuft werden.

Am 21. Oktober 2026 wurden folgende korrigierte PHP-Versionen veröffentlicht:

PHP 8.1 und ältere Versionen werden vom PHP-Projekt offiziell nicht mehr unterstützt. Einige Linux-Distributionen und Anbieter mit Langzeitunterstützung stellen jedoch weiterhin Sicherheitskorrekturen für ältere Versionen bereit. Das PHP-Sicherheitsteam hat außerdem minimale Quellcode-Patches für PHP 7.4, 8.0 und 8.1 veröffentlicht.

Unternehmen sollten deshalb die Sicherheitshinweise und Änderungsprotokolle ihrer jeweiligen Anbieter prüfen, anstatt sich ausschließlich auf die angezeigte PHP-Versionsnummer zu verlassen.

Fünf Maßnahmen, die Unternehmen jetzt ergreifen sollten

1. Alle PHP-Installationen identifizieren. Erfassen Sie öffentlich erreichbare Webanwendungen, interne Systeme, Container, Lösungen von Drittanbietern und weitere Umgebungen, in denen PHP eingesetzt wird. Priorisieren Sie internetexponierte Systeme und Anwendungen, die sensible Unternehmensdaten verarbeiten.

2. Sicherheitsupdates unverzüglich installieren. Aktualisieren Sie PHP auf eine korrigierte Version oder installieren Sie einen vom Anbieter bereitgestellten Sicherheitspatch. Starten Sie Apache, PHP-FPM und andere dauerhaft laufende PHP-Prozesse neu und überprüfen Sie, ob die aktualisierte Laufzeitumgebung tatsächlich aktiv ist. Bei containerisierten Anwendungen müssen betroffene Images neu erstellt und die entsprechenden Dienste erneut bereitgestellt werden. Eine Aktualisierung des Quellcodes allein schützt die produktive Umgebung nicht.

3. Mögliche Kompromittierungen untersuchen – auch vor der Veröffentlichung. Analysieren Sie Sicherheitsprotokolle mindestens ab dem 17. Oktober, als Amazon den ersten Angriffsversuch registrierte. Achten Sie auf verdächtige HTTP-Anfragen, ungewöhnlich große Formulardaten, Fehler durch Speichermangel, unerwartete von PHP gestartete Prozesse und unautorisierte Dateiänderungen. Korrelieren Sie nach Möglichkeit die Protokolle von Webservern, Endpunkten und Netzwerkkomponenten.

4. Das Risiko reduzieren, wenn ein sofortiges Update nicht möglich ist. Aktivieren Sie die vom Anbieter empfohlenen WAF-Regeln, beschränken Sie unnötige öffentliche Zugriffe und erwägen Sie eine vorübergehende Isolierung verwundbarer Dienste. Diese Maßnahmen können das Risiko verringern, ersetzen jedoch keinen Sicherheitspatch.

5. Die Sicherheit nach der Aktualisierung überprüfen. Stellen Sie sicher, dass alle verwundbaren Laufzeitumgebungen tatsächlich aktualisiert wurden, überprüfen Sie die Wirksamkeit der Schutzmaßnahmen und untersuchen Sie verdächtige Aktivitäten aus der Zeit vor der Installation der Updates. Die Behebung einer Schwachstelle und die Untersuchung einer möglichen Kompromittierung sind zwei eigenständige Aufgaben.

Eine funktionierende Website bedeutet nicht automatisch einen sicheren Server

Die Untersuchungen von Datadog zeigen eine wichtige Herausforderung bei der Angriffserkennung: Eine erfolgreiche Ausnutzung von PHP2Shell muss nicht zwangsläufig zum Absturz eines PHP-Prozesses führen.

Ein kompromittierter Server kann daher weiterhin scheinbar problemlos funktionieren, ohne dass Administratoren offensichtliche Anzeichen eines Angriffs bemerken.

Sicherheitsteams sollten sich deshalb nicht allein auf die Verfügbarkeit ihrer Dienste verlassen. Wichtige Hinweise können unerwartete Befehlsausführungen, ungewöhnliches Verhalten von PHP-Prozessen, Speicherfehler oder verdächtige HTTP-Kommunikation sein.

Zusätzliche Möglichkeiten bietet die Überwachung des Netzwerkverkehrs. Corelight hat Erkennungsregeln für Zeek und Suricata veröffentlicht. Elastic wiederum beschreibt verhaltensbasierte Erkennungsansätze, die sich auf verdächtige Prozesse und Aktivitäten nach einer erfolgreichen Ausnutzung konzentrieren. Die Wirksamkeit solcher Maßnahmen hängt jedoch von den verfügbaren Daten, der Konfiguration und der jeweiligen Angriffstechnik ab.

Google Cloud weist außerdem darauf hin, dass es in Cloud-Umgebungen nicht ausreicht, lediglich den Quellcode zu aktualisieren. Auch die tatsächlich bereitgestellten Anwendungen und ihre Abhängigkeiten müssen aktualisiert werden. Besonders relevant ist dies bei Containern, in denen verwundbare PHP-Versionen selbst nach der Veröffentlichung von Sicherheitsupdates weiterlaufen können.

Auch vorübergehende Konfigurationsänderungen haben ihre Grenzen. So kann beispielsweise die Deaktivierung von session.upload_progress das Risiko bestimmter Angriffswege reduzieren, die eigentlichen Schwachstellen jedoch nicht beseitigen.

Die wichtigste Maßnahme bleibt daher die Installation der entsprechenden PHP-Sicherheitsupdates.

Was bedeutet PHP2Shell für CIOs, CTOs und CISOs?

PHP2Shell wirft eine Frage auf, die weit über PHP hinausgeht: Wie gut kennt Ihr Unternehmen die Technologien, auf denen seine geschäftskritischen Anwendungen basieren?

Eine Anwendung kann Sicherheitsaudits erfolgreich bestehen, starke Authentifizierungsmechanismen einsetzen und regelmäßig aktualisiert werden. Dennoch kann sie aufgrund einer Schwachstelle in der zugrunde liegenden Laufzeitumgebung, in ihren Abhängigkeiten oder in der Serverkonfiguration angreifbar bleiben.

Für IT- und Sicherheitsverantwortliche sind deshalb drei Bereiche besonders wichtig:

• Transparenz über eingesetzte Technologien: Wissen, welche Laufzeitumgebungen, Bibliotheken und weiteren Abhängigkeiten in geschäftskritischen Systemen eingesetzt werden – einschließlich Lösungen, die von externen Dienstleistern verwaltet werden.
• Schnelle Behebung von Schwachstellen: Betroffene Systeme identifizieren, Sicherheitsupdates in produktiven Umgebungen bereitstellen und deren Wirksamkeit ohne unnötige Verzögerungen überprüfen.
• Erkennung möglicher Kompromittierungen: Über ausreichende Sicherheitsprotokolle und Incident-Response-Prozesse verfügen, um mögliche Angriffe auch rückwirkend untersuchen zu können – einschließlich des Zeitraums vor der offiziellen Veröffentlichung einer Schwachstelle.

Die Erkenntnisse von Amazon verdeutlichen einen weiteren wichtigen Punkt: Unternehmen dürfen nicht automatisch davon ausgehen, dass der Zeitraum vor der öffentlichen Bekanntgabe einer Schwachstelle sicher war. Liegen glaubwürdige Hinweise auf frühere Ausnutzungsversuche vor, müssen diese bei der Sicherheitsuntersuchung berücksichtigt werden.

Diese Fähigkeiten sind nicht nur bei PHP2Shell entscheidend. Sie bilden die Grundlage für eine wirksame Reaktion auf zukünftige Schwachstellen in weitverbreiteten Softwaretechnologien.

PHP2Shell zeigt: Anwendungssicherheit endet nicht beim Quellcode

PHP2Shell verdeutlicht, wie Schwachstellen in grundlegenden Technologien selbst gut abgesicherte Anwendungen gefährden können.

Die unmittelbaren Prioritäten sind klar: Verwundbare PHP-Installationen aktualisieren und mögliche Angriffsversuche untersuchen – auch aus der Zeit vor der offiziellen Veröffentlichung.

Langfristig sollten Unternehmen jedoch auch prüfen, ob sie ausreichend Transparenz über die technischen Abhängigkeiten ihrer Anwendungen, die Konfiguration ihrer Server und mögliche weitere Angriffswege nach einer erfolgreichen Kompromittierung haben.

Professionelle Penetrationstests helfen Unternehmen, Schwachstellen in Webanwendungen und IT-Infrastrukturen aufzudecken, ihre tatsächliche Ausnutzbarkeit zu überprüfen und mögliche Auswirkungen auf den Geschäftsbetrieb besser einzuschätzen.

Möchten Sie die Sicherheit Ihrer Webanwendungen oder IT-Infrastruktur überprüfen lassen? Die Sicherheitsexperten von Citadelo unterstützen Sie dabei, Schwachstellen zu identifizieren, Risiken zu bewerten und Maßnahmen zur Behebung gezielt zu priorisieren.