Kurz gesagt: PHP2Shell und Log4Shell haben gemeinsam, dass sie kritische Lücken in einem sehr weit verbreiteten Grundbaustein sind, über die Angreifer ohne Anmeldung Code ausführen können. Sie unterscheiden sich in der Sichtbarkeit, der Einstufung und der Lage bei bekannten Angriffen. Die wichtigste Lehre aus Log4Shell gilt heute unverändert: Wer weiß, wo der betroffene Baustein läuft, handelt in Stunden statt in Wochen.
Warum der Vergleich gerade überall auftaucht
Im Dezember 2021 hielt Log4Shell die IT-Welt wochenlang in Atem. Das BSI rief damals die höchste Warnstufe Rot aus. Fast fünf Jahre später fällt bei PHP2Shell in vielen Beiträgen derselbe Name, oft verbunden mit der Frage: „Wird das wieder so schlimm?“
Der Vergleich ist naheliegend, und er ist nützlich, wenn man ihn richtig führt. Er zeigt, welche Muster sich wiederholen und welche Erfahrungen Unternehmen heute direkt nutzen können. Wie das BSI die aktuelle Lage einstuft, erklärt der Beitrag BSI-Warnstufe Orange.
PHP2Shell und Log4Shell im direkten Vergleich
| Merkmal | Log4Shell (2021) | PHP2Shell (2026) |
|---|---|---|
| Betroffene Software | Java-Bibliothek Log4j | PHP-Laufzeit selbst |
| Kennung | CVE-2021-44228 | CVE-2026-109618, CVE-2026-109619 |
| Bewertung | CVSS 10.0 (v3) | CVSS v4.0 9.2 |
| Wirkung | Codeausführung ohne Anmeldung | Codeausführung ohne Anmeldung |
| BSI-Warnstufe | 4 / Rot | 3 / Orange |
| Lage bei Warnung | laut damaligen Berichten Kompromittierungen bekannt | Angriffsversuche berichtet, laut BSI zunächst keine bestätigten erfolgreichen Angriffe in der Breite |
| Sichtbarkeit | oft tief in Anwendungen versteckt | auf dem Server sichtbar, Patchstand aber durch Backports schwer ablesbar |
| Folgemeldungen | mehrere weitere CVEs in wenigen Wochen | Hinweis zu CVE-2026-115560 am 23.10. |
Was die beiden Lücken gemeinsam haben
Ein Grundbaustein, unzählige Anwendungen. Log4j steckte in Java-Software aller Art, PHP trägt WordPress, Shopware, TYPO3 und unzählige Eigenentwicklungen. In beiden Fällen ist nicht ein Produkt betroffen, sondern ein Fundament.
Kein Login nötig. Beide Lücken erlauben die Ausführung von Code aus der Ferne ohne Anmeldung. Das macht sie für automatisierte Angriffe attraktiv.
Der Patch ist nicht das Ende. Bei Log4Shell zeigte sich, dass viele Systeme vor dem Update bereits angegriffen worden waren. Auch bei PHP2Shell gilt: Ein Patch entfernt keine eingeschleuste Schadsoftware. Laut Medienberichten wurde ein erster Angriffsversuch bereits am 17. Oktober beobachtet.
Folgemeldungen. Nach Log4Shell erschienen innerhalb weniger Wochen weitere CVEs zu Log4j. Bei PHP kam zwei Tage nach den Patches der Hinweis zu CVE-2026-115560. Warum weitere Meldungen wahrscheinlich sind, erläutert Nach PHP2Shell: Warum weitere Meldungen wahrscheinlich sind.
Wo der Vergleich hinkt
Der größte Unterschied liegt in der Sichtbarkeit. Log4j war oft als Teil einer Anwendung verbaut, manchmal mehrfach verschachtelt. Viele Betreiber wussten schlicht nicht, dass sie es einsetzten. PHP dagegen ist auf einem Webserver kein Geheimnis. Dafür entsteht bei PHP2Shell eine andere Unklarheit: Distributionen und Hoster spielen Korrekturen als Backport ein, die angezeigte Versionsnummer bleibt gleich. Man sieht PHP, aber nicht sofort, ob es gepatcht ist.
Ein zweiter Unterschied ist die Ausgangslage beim Update. Bei Log4Shell mussten oft Hersteller von Fachanwendungen erst neue Versionen liefern. Bei PHP2Shell stehen Updates für alle unterstützten Zweige bereit. Schwierig wird es bei PHP 8.1 und älter, für die das PHP-Projekt keine offiziellen Updates mehr veröffentlicht.
Ein dritter Unterschied betrifft den Ort des Angriffs. Bei Log4Shell konnte jede Stelle gefährlich sein, an der eine Anwendung Eingaben protokollierte, also auch interne Systeme, die nur indirekt Daten aus dem Internet erhielten. Bei PHP2Shell steht der Webserver im Mittelpunkt, der Anfragen direkt entgegennimmt. Das macht die Suche nach betroffenen Systemen etwas übersichtlicher: Zuerst kommen alle öffentlich erreichbaren PHP-Dienste, danach interne Anwendungen.
Schließlich unterscheidet sich die Lage bei der Ausnutzung. Für Log4Shell kursierten früh einfache Angriffswerkzeuge, und Kompromittierungen waren laut damaligen Berichten schon zum Zeitpunkt der Warnung bekannt. Bei PHP2Shell berichten Cloudflare und Patchstack von Angriffsversuchen, watchTowr hat eine der Lücken nach eigenen Angaben nachgestellt, bestätigte erfolgreiche Angriffe in der Breite meldete das BSI zunächst nicht. Das kann sich ändern. Es ist aber ein Grund, warum der Vergleich nicht als Prognose taugt.
Nutzen Sie die Erfahrungen aus Log4Shell im eigenen Haus: Welche Listen, Abläufe und Kontakte haben damals geholfen? Vieles davon lässt sich für PHP2Shell direkt wiederverwenden.
Fünf Lehren aus Log4Shell, die heute helfen
- Inventar vor Patch: Wer 2021 eine aktuelle Liste seiner Systeme hatte, war schneller. Das gilt heute genauso. Eine Anleitung bietet der Beitrag Inventar aller Websites und Server.
- Abhängigkeiten kennen: Eine Stückliste der Softwarebausteine, kurz SBOM, beantwortet die Frage „Wo setzen wir das ein?“ in Minuten. Für PHP-Anwendungen hilft der Blick in Composer, wie ihn Composer-Abhängigkeiten prüfen beschreibt.
- Logs aufbewahren: Nach Log4Shell konnten viele Unternehmen nicht mehr klären, ob sie betroffen waren, weil Logs fehlten. Die Fachpresse rät bei PHP2Shell, Logs ab dem 20. Oktober zu sichern.
- Nachträglich prüfen: Ein Patch beantwortet nicht, was vorher geschah. Eine Prüfung auf Spuren gehört dazu.
- Auf Folgemeldungen vorbereitet sein: Das erste Update ist selten das letzte. Wer den Update-Weg einmal sauber eingerichtet hat, wiederholt ihn schnell.
Wie hilft PHP SOS konkret?
- Bestandsaufnahme: Wir ermitteln, wo PHP in Ihrem Unternehmen läuft, in welcher Version und Betriebsart.
- Patch und Neustart: Wir spielen Updates ein und belegen den Stand je System.
- Spurenprüfung: Wir sichern Logs und prüfen auf Auffälligkeiten seit dem 17. Oktober.
- Dauerhafte Beobachtung: Wir halten Ihre Systeme im Blick, damit Folgemeldungen nicht wieder bei null beginnen.
Wie die laufende Überwachung aussieht, beschreibt Security-Monitoring für Webserver.
Fazit
PHP2Shell ist nicht Log4Shell, aber es reimt sich. Beide treffen ein Fundament, beide brauchen mehr als einen Patch. Unternehmen, die aus 2021 Inventar, Logaufbewahrung und Update-Wege mitgenommen haben, sind heute im Vorteil. Für alle anderen ist jetzt der Zeitpunkt, das nachzuholen.
Häufige Fragen
Ist PHP2Shell so schlimm wie Log4Shell?
Beide sind kritische Lücken in sehr weit verbreiteter Software, über die Angreifer ohne Anmeldung Code ausführen können. Das BSI stufte Log4Shell 2021 mit Rot ein, PHP2Shell mit Orange. Ein wichtiger Unterschied: Bei Log4Shell waren laut damaligen Berichten bei der Warnung bereits Kompromittierungen bekannt, bei PHP2Shell laut BSI zunächst keine bestätigten erfolgreichen Angriffe in der Breite.
Was war Log4Shell?
Log4Shell war eine kritische Lücke in der Java-Bibliothek Log4j, die im Dezember 2021 bekannt wurde und unter CVE-2021-44228 geführt wird. Log4j steckte als Baustein in sehr vielen Anwendungen, oft ohne dass Betreiber es wussten.
Kommen nach PHP2Shell weitere Lücken?
Das ist möglich. Nach Log4Shell folgten innerhalb weniger Wochen weitere CVEs zu Log4j. Bei PHP gab es am 23. Oktober bereits einen Hinweis zu CVE-2026-115560, der nur bei ungewöhnlicher Konfiguration greift. Planen Sie Folgemeldungen ein.
Was ist eine SBOM?
Eine Software Bill of Materials ist eine Stückliste aller Softwarebausteine, aus denen eine Anwendung besteht. Mit ihr lässt sich bei einer neuen Lücke schnell feststellen, wo der betroffene Baustein eingesetzt wird.