Kurz gesagt: Zu den belegten PHP2Shell-Fakten gehören die beiden CVE-Nummern, die Bewertung mit CVSS v4.0 9.2, die behobenen PHP-Versionen und die Übergangsmaßnahmen von php.net. Ebenfalls belegt ist die Warnstufe Orange des BSI. Nicht belegt sind eine Bewertung mit CVSS 10, bestätigte erfolgreiche Angriffe in der Breite und eine Liste von Erkennungsmerkmalen. Wer diese drei Ebenen trennt, trifft bessere Entscheidungen.
Warum ein Faktencheck zu PHP2Shell nötig ist
Kaum eine Sicherheitslücke der letzten Jahre hat so schnell so viele Schlagzeilen erzeugt. Schon bevor das PHP-Team am 21. Oktober 2026 die Updates veröffentlichte, kursierten laut Berichten Forenbeiträge, Screenshots und angebliche Details. Danach folgten Behördenwarnungen, Herstellerblogs, Zählungen exponierter Server und eine Flut von Tipps.
Für Betreiber heißt das: Nicht jede Zahl und nicht jeder Ratschlag hat dieselbe Qualität. Ein Teil stammt aus Primärquellen, ein Teil aus seriöser Berichterstattung, ein Teil aus Spekulation. Dieser Artikel sortiert, was Sie für Ihre Entscheidungen als gesichert verwenden können. Die Grundlagen der Lücke selbst erklärt die Seite Was ist PHP2Shell?.
Welche Quellen welches Gewicht haben
Eine einfache Rangfolge hilft beim Lesen jeder Meldung:
- php.net: Das PHP-Projekt ist die Primärquelle für CVE-Nummern, Bewertungen, betroffene Betriebsarten, behobene Versionen und Übergangsmaßnahmen. Wie das Projekt Sicherheitsmeldungen grundsätzlich behandelt, beschreibt unser Beitrag zum PHP-Sicherheitsprozess.
- Behörden: Das BSI liefert die Einstufung der Lage in Österreich und Handlungsempfehlungen, CERT-EU und CERT-Bund ergänzen.
- Distributionen und Anbieter: Debian, Ubuntu, Red Hat, Hoster und Plattformdienste sagen verbindlich nur etwas über ihre eigenen Pakete und Dienste.
- Sicherheitsfirmen: Cloudflare, Unit 42, CybelAngel und andere berichten aus eigenen Messungen. Wertvoll, aber jeweils mit eigener Methode.
- Medien und soziale Netzwerke: Gut für das Tempo, schwach bei Details. Aussagen von dort brauchen eine Bestätigung weiter oben.
Belegt, berichtet, unbelegt: die Übersicht
Die folgende Tabelle ordnet die häufigsten Aussagen ein. „Belegt“ heißt: Primärquelle oder Behörde. „Berichtet“ heißt: aus Medien oder Herstellerangaben, nicht unabhängig bestätigt.
| Aussage | Einordnung | Grundlage |
|---|---|---|
| Zwei Lücken, CVE-2026-109618 und CVE-2026-109619 | belegt | php.net |
| Bewertung CVSS v4.0 9.2, kritisch | belegt | php.net |
| Bewertung CVSS 10 | nicht haltbar | laut Berichten aus einem Forenbeitrag vor der Meldung |
| Behoben in 8.5.12, 8.4.27, 8.3.36, 8.2.35 | belegt | php.net |
| mod_php mit höchstem Risiko, Exploit vor Anwendungscode gezeigt | belegt | php.net |
| Nahezu alle Versionen bis PHP 5.4 betroffen | berichtet | Fachpresse |
| Erster Angriffsversuch am 17.10. | berichtet | Medienberichte unter Berufung auf Amazon |
| Mehr als 22,6 Mio. exponierte Instanzen | berichtet | Unit 42, laut TechTarget |
| Erfolgreiche Angriffe in der Breite | unbelegt | laut BSI zunächst nicht bekannt |
| Bestätigte Indicators of Compromise | gibt es nicht | keine Veröffentlichung |
| Übergangsmaßnahmen schützen vollständig | falsch | php.net nennt sie ausdrücklich unvollständig |
Auffällig ist, wie früh sich Zahlen verselbständigen. Die Bewertung 10.0 aus dem Forenbeitrag tauchte noch Tage später in Beiträgen auf, obwohl das PHP-Team längst 9.2 veröffentlicht hatte.
Wo die Unsicherheit wirklich liegt
Die größte offene Frage ist nicht technisch, sondern zeitlich: Was ist zwischen dem ersten berichteten Angriffsversuch und dem Patch auf einzelnen Servern passiert? Darauf gibt es keine allgemeine Antwort. Cloudflare und Patchstack berichteten von Angriffsversuchen, watchTowr hat CVE-2026-109618 nach eigenen Angaben nachgestellt. Huntress wiederum sah zum Zeitpunkt seiner Meldung keine Angriffe in Partnerumgebungen.
Diese Aussagen widersprechen sich nicht. Sie beschreiben unterschiedliche Ausschnitte: einen großen Proxy-Dienst, eine Plugin-Sicherheitsfirma, ein Forschungsteam und eine Firma mit eigener Kundenbasis. Ein Gesamtbild ergibt sich daraus nicht.
Ähnlich bei der Frage, welche Versionen betroffen sind. Für 8.2 bis 8.5 ist die Lage klar. Für ältere Zweige gibt es minimale Quell-Backports für 7.4, 8.0 und 8.1, aber keine offiziellen Releases. Was davor liegt, ist laut Fachpresse fast durchgehend betroffen. Für Ihre Planung macht das kaum einen Unterschied: Ein Server mit PHP 8.1 oder älter ohne bestätigten Backport ist als gefährdet zu behandeln.
Fehlende Belege für Angriffe sind kein Beleg für Sicherheit. Weil es keine bestätigten Erkennungsmerkmale gibt, lässt sich ein Angriff auf einen einzelnen Server nur über eine Prüfung des Verhaltens einschätzen, nicht über eine Liste.
Was Sie daraus für Ihre Server ableiten
Aus den belegten Fakten folgen wenige, klare Schritte. Aus den unbelegten folgt vor allem Vorsicht.
- Patchstand prüfen: behobene Version oder vom Anbieter bestätigter Backport. Die angezeigte Versionsnummer allein reicht nicht.
- Alle PHP-Prozesse neu starten: Neue Dateien wirken erst, wenn keine alten Prozesse mehr laufen.
- Logs ab dem 20.10. sichern: Die Fachpresse rät dazu, damit eine spätere Prüfung möglich bleibt.
- Auf Spuren prüfen: Neue PHP-Dateien in Upload-Ordnern, unbekannte Cronjobs, Webserver-Prozesse mit Shell. Die Seite Bin ich schon kompromittiert? führt durch die Prüfung.
- Ratschläge gegenprüfen: Tipps aus Foren und sozialen Netzwerken nur umsetzen, wenn sie sich auf php.net oder eine Behörde zurückführen lassen. Welche Empfehlungen gerade schaden, sammelt der Beitrag Gefährliche Falschtipps zu PHP2Shell.
Für die interne Kommunikation hilft dieselbe Trennung. Wer der Geschäftsführung „belegt“, „berichtet“ und „offen“ getrennt vorlegt, vermeidet sowohl Alarmismus als auch falsche Entwarnung.
Wie hilft PHP SOS konkret?
- Lage für Ihre Systeme: Wir übertragen die belegten Fakten auf Ihre Server und trennen in der Dokumentation, was gemessen, was berichtet und was offen ist.
- Patch und Nachweis: Wir prüfen Paketstand und Neustart jedes PHP-Dienstes und halten das schriftlich fest.
- Spurenprüfung: Wir sichern Logs ab dem 20. Oktober und suchen nach Verhaltensauffälligkeiten, bis der Vorfall abgeschlossen und dokumentiert ist.
- Laufende Einordnung: Neue Meldungen ordnen wir für Sie ein, bevor daraus Maßnahmen werden.
Den Ablauf beschreibt die PHP2Shell-Soforthilfe.
Fazit
PHP2Shell ist ernst, und das ist gut belegt. Gerade deshalb lohnt der nüchterne Blick: Die Primärquellen reichen für alle wichtigen Entscheidungen aus. Was darüber hinaus kursiert, ist oft schneller als genau. Patchen, neu starten, Logs sichern und auf Spuren prüfen bleibt die Antwort, unabhängig davon, welche Zahl gerade die Runde macht.
Häufige Fragen
Ist PHP2Shell mit CVSS 10 bewertet?
Nein. Die Zahl 10 stammt laut Berichten aus einem Forenbeitrag, der vor der offiziellen Meldung kursierte. Das PHP-Team bewertet beide Lücken mit CVSS v4.0 9.2. Das ist trotzdem die Kategorie kritisch.
Gibt es eine Liste mit Erkennungsmerkmalen für PHP2Shell-Angriffe?
Bisher nicht. Es gibt keine veröffentlichten, bestätigten Indicators of Compromise. Wer prüfen will, ob ein Server betroffen war, muss auf Verhaltensauffälligkeiten achten, etwa Webserver-Prozesse, die eine Shell starten, oder neue PHP-Dateien in Upload-Ordnern.
Welche Quelle ist bei PHP2Shell am verlässlichsten?
Für die technischen Fakten die Meldungen auf php.net, für die Lageeinschätzung in Österreich das BSI. Medienberichte und Herstellerblogs ergänzen das Bild, sollten aber als Berichte gekennzeichnet und gegen die Primärquelle gelesen werden.
Sind wirklich alle PHP-Versionen ab PHP 5 betroffen?
Belegt ist die Lage für die Zweige 8.2 bis 8.5, für die es Updates gibt. Laut Fachpresse sind nahezu alle Versionen bis PHP 5.4 betroffen; CERT-EU hielt laut Berichten Versionen ab PHP 5 für möglich. Für ältere Versionen gibt es keine offiziellen Updates, deshalb sollten Sie sie in jedem Fall als gefährdet behandeln.