Kurz gesagt: Eine Woche nach dem ersten beobachteten Angriffsversuch ist PHP2Shell aktuell vor allem eine Frage der Umsetzung: Patches für PHP 8.2 bis 8.5 liegen seit dem 21. Oktober vor, große Distributionen haben nachgezogen, das BSI warnt mit Stufe Orange. Angriffsversuche wurden beobachtet, bestätigte erfolgreiche Angriffe in der Breite meldete das BSI zunächst nicht. Offen bleiben Altversionen, nicht neu gestartete Server und die Frage, was vor dem Patch geschah.
Die Lage in drei Sätzen
PHP2Shell sind zwei kritische Lücken im PHP-Interpreter selbst, CVE-2026-109618 und CVE-2026-109619, je mit CVSS v4.0 9.2 bewertet. Sie erlauben Codeausführung aus der Ferne ohne Anmeldung, also den Fall, den Sicherheitsleute am meisten fürchten. Betroffen sind PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed; das höchste Risiko sieht das PHP-Team bei mod_php.
Diese Übersicht ordnet den Stand am 25. Oktober 2026 nach Akteuren. Den Ablauf Tag für Tag finden Sie in der PHP2Shell-Chronologie, hier geht es um das Gesamtbild.
Was nach einer Woche belegt ist
Gesichert sind die Angaben des PHP-Projekts: Die Releases 8.5.12, 8.4.27, 8.3.36 und 8.2.35 vom 21. Oktober schließen beide Lücken. Für PHP 7.4, 8.0 und 8.1 gibt es nur minimale Quell-Backports, keine offiziellen Releases. php.net betont, dass es keine vollständigen Übergangsmaßnahmen gibt und das Update der einzig sichere Weg ist.
Am 23. Oktober kam ein Hinweis zu CVE-2026-115560 hinzu. Er betrifft nur eine ungewöhnliche Session-Konfiguration; als Abhilfe nennt php.net session.upload_progress.enabled=0 bis zum nächsten regulären Bugfix-Release.
Auch die großen Distributionen haben Stellung bezogen. Wir haben die offiziellen Meldungen geprüft:
| Anbieter | Stand laut offizieller Meldung |
|---|---|
| Ubuntu | USN-8948-1 für 22.04, 24.04, 26.04 und 26.10; USN-8948-2 für 14.04 bis 20.04 über Ubuntu Pro |
| Debian | Korrigierte Pakete für bookworm (php8.2, DLA-4848-1) und trixie (php8.4, DSA-6574-1) |
| Red Hat | Bulletin RHSB-2026-013 für RHEL 7 bis 10; einige Updates verfügbar, weitere in Arbeit |
Red Hat stuft CVE-2026-109618 mit eigener Bewertung als „Important“ ein und begründet das mit höherer Angriffskomplexität. Das ist eine andere Bewertungsmethode als die des PHP-Projekts und kein Grund, das Update aufzuschieben.
Wie Behörden die Lage bewerten
Das BSI hat Warnstufe 3 / Orange ausgerufen. Es empfiehlt das sofortige Update und, wenn das nicht sofort geht, die betroffenen Webserver vorübergehend vom Netz zu nehmen. Das BSI rechnete mit schneller großflächiger Ausnutzung. Was die Einstufung bedeutet, erklärt die Seite Was das BSI zu PHP2Shell empfiehlt.
Laut Berichten hält CERT-EU für möglich, dass Versionen ab PHP 5 betroffen sind, und rät, öffentlich erreichbare Anwendungen zu isolieren, wenn sie nicht zeitnah gepatcht werden können. CERT-Bund und das Sicherheitsunternehmen Huntress haben ebenfalls gewarnt.
Die Empfehlung, notfalls abzuschalten, wurde sichtbar umgesetzt. Laut Medienberichten nahm die Stadt Mainz ihr zentrales Webportal vorsorglich vom Netz; Ämter blieben per Telefon und E-Mail erreichbar. In Hessen waren laut hessenschau Seiten der Landesregierung, des BKA sowie der Städte Kassel und Wiesbaden vorübergehend offline. Die Staatskanzlei meldete keinen Angriff, die Seiten waren am Abend wieder erreichbar. Weitere Kommunen, Hochschulen und Kliniken handelten laut Berichten ähnlich.
Was über Angriffe bekannt ist
Hier ist die Trennung zwischen Beobachtung und Bestätigung besonders wichtig.
- Beobachtet: Laut Medienberichten gab es am 17. Oktober einen ersten Angriffsversuch, den Amazon beobachtete. Cloudflare und Patchstack berichteten von Angriffsversuchen; Cloudflare sah zudem veränderte Angriffsmuster.
- Nachgestellt: watchTowr hat CVE-2026-109618 laut Berichten nach eigenen Angaben nachgestellt.
- Nicht bestätigt: Das BSI meldete zunächst keine bestätigten erfolgreichen Ausnutzungen in der Breite. Huntress sah zum Zeitpunkt seiner Meldung keine Angriffe in Partnerumgebungen.
- Unbekannt: Es gibt keine veröffentlichten, bestätigten Indicators of Compromise. Wer prüfen will, ob ein Server betroffen ist, muss auf Verhaltensmuster achten.
Zum Ausmaß kursieren zwei Zahlen. Die Forscher von Unit 42 bei Palo Alto Networks kamen auf über 22,6 Millionen potenziell verwundbare Instanzen, die aus dem Netz erreichbar sind. CybelAngel nennt rund 2,24 Millionen erreichbare PHP-Hosts, davon laut eigener Auswertung 59 Prozent auf Versionen ohne kommenden offiziellen Fix. Beide messen Unterschiedliches und sind nicht direkt vergleichbar. Eine Einordnung liefert der Beitrag Zahlen richtig einordnen.
Was offen ist
Drei Fragen bestimmen die nächsten Wochen:
- Altversionen: Ein großer Teil der erreichbaren PHP-Installationen läuft laut den genannten Auswertungen auf Zweigen ohne offiziellen Fix. Ob kommerzielle Langzeitangebote PHP2Shell abdecken, muss jeweils beim Anbieter schriftlich bestätigt werden.
- Unvollständige Updates: Neue Pakete wirken erst, wenn alle PHP-Prozesse neu gestartet sind. Red Hat weist ausdrücklich darauf hin, dass ein bloßes Neuladen nicht genügt.
- Die Zeit vor dem Patch: Zwischen dem 17. und 21. Oktober waren Server verwundbar, während bereits Angriffsversuche liefen. Ein Patch beweist nicht, dass in dieser Zeit nichts passiert ist.
Bewahren Sie Webserver- und PHP-Logs ab dem 20. Oktober auf, wie es die Fachpresse empfiehlt. Ohne Logs lässt sich die wichtigste offene Frage für Ihren Server später nicht mehr beantworten.
Was Betreiber jetzt prüfen sollten
Für die eigene Lagebewertung genügen vier Prüfpunkte je Server: Ist PHP auf einem behobenen Stand oder einem bestätigten Backport? Laufen alle Prozesse seit dem Update? Ist session.upload_progress.enabled serverseitig abgeschaltet, solange das Advisory zu CVE-2026-115560 aussteht? Gibt es Auffälligkeiten seit dem 17. Oktober?
Für den letzten Punkt hilft die Seite Bin ich schon kompromittiert?. Ein Webserver-Prozess, der eine Shell startet, neue PHP-Dateien in Upload-Ordnern, unbekannte Cronjobs oder SSH-Schlüssel sind Warnsignale, die eine genauere Untersuchung rechtfertigen.
Wie hilft PHP SOS konkret?
- Wir bewerten den Patchstand jedes Servers anhand von Paketstand, Changelog und Prozess-Startzeiten.
- Wo kein Patch verfügbar ist, setzen wir die Übergangsmaßnahmen von php.net und klären den Weg zur unterstützten Version.
- Wir sichern Logs ab dem 20. Oktober und suchen nach Spuren aus der Zeit vor dem Patch.
- Mit der PHP2Shell-Soforthilfe bündeln wir diese Schritte für Unternehmen, die schnell Klarheit brauchen.
Häufige Fragen
Wird PHP2Shell schon aktiv ausgenutzt?
Cloudflare und Patchstack berichteten von Angriffsversuchen. Bestätigte erfolgreiche Angriffe in der Breite meldete das BSI zunächst nicht. Huntress sah zum Zeitpunkt seiner Meldung keine Angriffe in Partnerumgebungen.
Ist die Gefahr nach den Patches vorbei?
Nein. Die Patches schützen nur Server, die sie installiert und alle PHP-Prozesse neu gestartet haben. Systeme auf PHP 8.1 und älter bleiben ohne bestätigten Backport verwundbar, und ein Patch entfernt keine vorher eingeschleuste Schadsoftware.
Warum waren Behörden-Websites offline?
Laut Medienberichten haben unter anderem die Stadt Mainz und mehrere Stellen in Hessen ihre Websites vorsorglich abgeschaltet. Das entspricht der BSI-Empfehlung für Server, die nicht sofort aktualisiert werden können. Eine Abschaltung bedeutet nicht, dass ein Angriff stattgefunden hat.
Gibt es Erkennungsmerkmale für einen PHP2Shell-Angriff?
Veröffentlichte, bestätigte Indicators of Compromise gibt es bislang nicht. Die Erkennung beruht auf Verhaltensanalyse, etwa auf PHP-Prozessen, die eine Shell starten, oder auf neuen PHP-Dateien in Upload-Ordnern.