Log4Shell: Warum die Log4j-Sicherheitslücke weiterhin relevant ist

Erinnern Sie sich an Log4Shell? Die Zero-Day-Lücke markiert einen der schwerwiegendsten Sicherheitsvorfälle der IT-Geschichte. Wir wollten wissen: Was ist jetzt, fast 5 Jahre danach, von Log4Shell geblieben?

Die Ernüchterung im IT-Alltag zeigt: Die Schwachstelle ist alles andere als Geschichte. Obwohl wirksame Sicherheits-Patches seit Ende 2021 bereitstehen, schlummern verwundbare Log4j-Versionen nach wie vor in unzähligen Unternehmensnetzen. Das Problem liegt heute selten an Nachlässigkeit beim direkten Updaten, sondern an der immensen Tiefe moderner Software-Lieferketten (Software Supply Chains). Log4j steckt oft verborgen in Drittanbieter-Anwendungen, Legacy-Systemen oder verschachtelten Abhängigkeiten, die auf keinem einfachen Dashboard auftauchen.

Für Angreifer bleibt die Lücke damit ein hochattraktives, weil extrem leicht ausnutzbares Einfallstor. Log4Shell ist das Schullehrbeispiel dafür, warum punktuelles Flicken nicht reicht – Unternehmen brauchen vollständige Transparenz über ihre Software-Abhängigkeiten und kontinuierliche Sicherheitsanalysen.

Erfahren Sie in diesem Beitrag, welche Systeme heute besonders gefährdet sind, warum Log4Shell weiterhin ein Dauerrisiko darstellt und wie Sie verbliebene Schwachstellen in Ihrer Infrastruktur aufspüren und schließen.

Welche Systeme können von Log4Shell betroffen sein?

Log4Shell betrifft Anwendungen, die verwundbare Versionen der Java-Bibliothek Apache Log4j 2 einsetzen. Log4j wird zur Protokollierung von Ereignissen und Fehlermeldungen verwendet und ist Bestandteil zahlreicher Unternehmensanwendungen, Webanwendungen und Softwareprodukte.

Dabei muss Log4j nicht direkt als eigenständige Komponente installiert sein. Die Bibliothek kann auch innerhalb anderer Softwarepakete oder über weitere Abhängigkeiten eingebunden werden.

Log4j steckt häufig in Software-Abhängigkeiten

Genau das erschwert die Suche nach betroffenen Systemen. Log4j kann als indirekte oder transitive Abhängigkeit Teil einer Anwendung sein. IBM weist darauf hin, dass verwundbare Komponenten teilweise mehrere Ebenen tief in Abhängigkeitsketten oder JAR-Dateien eingebunden sind.

Unternehmen sollten deshalb nicht nur selbst entwickelte Java-Anwendungen prüfen. Relevant sind auch:

Standardsoftware und Fachanwendungen
Web- und Serveranwendungen
Anwendungen von Drittanbietern
ältere oder nur noch selten genutzte Systeme
selbst entwickelte Software mit externen Bibliotheken

Ob ein konkretes Produkt betroffen ist, lässt sich am zuverlässigsten über eine Analyse der eingesetzten Softwarekomponenten sowie über die Sicherheitshinweise des jeweiligen Herstellers feststellen

Warum ist Log4Shell auch heute noch relevant?

Obwohl für Log4Shell bereits seit 2021 Sicherheitsupdates verfügbar sind, können verwundbare Log4j-Versionen weiterhin in Unternehmenssystemen vorhanden sein. Das BSI weist darauf hin, dass insbesondere bei komplexer Software oft nicht transparent ist, welche Bibliotheken und Komponenten tatsächlich eingesetzt werden.

Auch aktuelle Zahlen zeigen das Problem: Nach einer Auswertung von Sonatype entfielen 2025 rund 13 Prozent aller Log4j-Downloads auf verwundbare Versionen. Veraltete Software, indirekte Abhängigkeiten und fehlende Updates können somit dazu führen, dass die Sicherheitslücke auch Jahre später noch relevant ist.

Was können Sie nun tun?

Auch wenn für Log4Shell bereits seit 2021 Sicherheitsupdates verfügbar sind, sollten Unternehmen weiterhin prüfen, ob verwundbare Log4j-Komponenten in ihrer IT-Landschaft vorhanden sind. Dabei reicht es nicht aus, nur direkt installierte Anwendungen zu betrachten. Log4j kann auch als Bestandteil anderer Software oder über indirekte Abhängigkeiten eingebunden sein.

Betroffene Systeme identifizieren

Prüfen Sie zunächst, in welchen Anwendungen und Softwareprodukten Log4j eingesetzt wird. Berücksichtigen Sie dabei auch Standardsoftware, Eigenentwicklungen, ältere Anwendungen und Systeme von Drittanbietern.

Vulnerability Scanner und Software-Composition-Analysis-Werkzeuge können dabei helfen, bekannte Schwachstellen und verwundbare Komponenten aufzuspüren. Zusätzlich sollten die Sicherheitshinweise der jeweiligen Softwarehersteller berücksichtigt werden.

Sicherheitsupdates einspielen

Werden verwundbare Log4j-Komponenten gefunden, sollten diese aktualisiert werden. Verwenden Sie dafür eine aktuell unterstützte Version von Apache Log4j beziehungsweise die vom jeweiligen Softwarehersteller bereitgestellten Sicherheitsupdates.

Eine feste Versionsnummer als allgemeine Empfehlung ist nicht sinnvoll, da Apache Log4j kontinuierlich weiterentwickelt wird und ältere Versionen aus der Wartung fallen können.

Systeme auf mögliche Angriffe prüfen

Bei Systemen, die nach Bekanntwerden von Log4Shell ungepatcht und aus dem Internet erreichbar waren, kann zusätzlich eine Überprüfung auf mögliche Kompromittierungen sinnvoll sein. Dazu können beispielsweise Logdateien, auffällige Netzwerkaktivitäten oder andere Hinweise auf einen unbefugten Zugriff untersucht werden.

Patch- und Schwachstellenmanagement dauerhaft etablieren

Log4Shell zeigt, dass bekannte Sicherheitslücken auch Jahre nach ihrer Veröffentlichung relevant bleiben können. Unternehmen sollten deshalb nicht nur auf einzelne Sicherheitsmeldungen reagieren.

Ein strukturiertes Patch- und Schwachstellenmanagement hilft dabei,

eingesetzte Software und Komponenten im Blick zu behalten,
bekannte Schwachstellen frühzeitig zu erkennen,
Sicherheitsupdates zeitnah einzuspielen,
veraltete Softwarekomponenten zu identifizieren und
Sicherheitsrisiken kontinuierlich zu bewerten.

Gerade bei komplexen IT-Landschaften kann es sinnvoll sein, die Prüfung und Absicherung gemeinsam mit einem erfahrenen IT-Dienstleister durchzuführen – wie beispielsweise mit den Managed Firewall Services von eEvolution.