Log4j Sicherheitslücke – Was tun?

Zuletzt aktualisiert am 1. Juni 2026

Seit kurzem ist bekannt, dass die Software-Bibliothek mit dem Namen Log4j eine Sicherheitslücke hat. Diese kann sehr einfach ausgenutzt werden, um ganze IT-Systeme zu übernehmen oder Daten abzugreifen. Viele Cyberkriminelle nutzen diese nun aus, während IT-Fachleute versuchen, den Schaden einzudämmen.

Doch was genau ist die Log4j Sicherheitslücke und was kann man dagegen tun?

Was ist die Log4j Sicherheitslücke?

Log4j ist ein Open-Source-Bibliothek, um in Programmen, die in Java geschrieben sind, Vorgänge zu loggen. Die Veröffentlichung der ersten Version ist nun schon fast 21 Jahre her und Log4j ist inzwischen zu einem Standard-Werkzeug geworden.

Hier ist nun eine Sicherheitslücke bekannt geworden. Bestimmte Zeichenfolgen interpretiert Log4j als Befehle, die es dann auf dem Server ausführt. Das führt dazu, dass Angreifer ganz einfach durch die Eingabe bestimmter Zeichenfolgen, diese Schwachstelle nutzen können.

Das Ausnutzen dieser Log4j Sicherheitslücke ist dementsprechend so kritisch, dass das Bundesamt für Sicherheit in der Informationstechnik (BSI) die Warnstufe Rot ausgerufen hat („extrem kritische IT-Sicherheitslage“). IT-Experten sprechen davon, dass „das Internet brennt“.

Die Log4j Sicherheitslücke hat in erster Linie auf alle Java-Anwendungen Auswirkungen, die über das Internet erreichbar sind und mit Hilfe von Log4j Nutzeranfragen protokollieren. In IT-Kreisen hat die Sicherheitslücke inzwischen den Namen Log4shell bekommen.

Was haben Nutzer durch die Sicherheitslücke zu befürchten?

Noch ist nicht klar, inwiefern zum Beispiel Router von Privatpersonen verwundbar sind. Bisher haben IT-Abteilungen von Behörden und Unternehmen am meisten mit der Log4j Sicherheitslücke zu kämpfen.

Grundsätzlich können Angriffe über die Log4j Sicherheitslücke dazu führen, dass IT-Systeme zeitweise nicht erreichbar sind oder von ihnen Daten abgegriffen werden. So wurde als Vorsichtsmaßnahme bereits Telematikinfrastruktur zum Teil vom Netz genommen, um Patientendaten zu schützen. Deshalb gab es an vielen Stellen Probleme bei der digitalen Erfassung von Krankenversichertenkarten. Solche Auswirkungen können in Zukunft noch häufiger zu spüren sein werden, da nicht alle kompromittierten Server sofort als solche erkennbar sind, sondern viele auch zu „tickenden Zeitbomben“ werden können.

Das BSI empfiehlt, zunächst einen Überblick darüber zu erstellen, welche Systeme Log4j benutzen und somit von der Sicherheitslücke betroffen sein können. Nicht zwingend benötigte Systeme sind zunächst abzuschalten. Zudem sollte Log4j soweit möglich auf die aktuelle Version geupdatet werden. Falls ein Schaden nicht mehr abwendbar erscheint, ist es zu empfehlen die betroffenen Systeme abzuschalten.

Sie brauchen Hilfe bei der Log4j Sicherheitslücke?

Bei der Suche nach und Behebung von der Log4j Sicherheitslücke steht Ihnen unser Team an Experten gerne zur Verfügung. Sie sollten auch daran denken, dass ein möglicher Datenschutz-Verstoß sofort zu melden ist. Sprechen Sie sich hier auch unbedingt mit Ihrem Datenschutzbeauftragten ab.

Unser Team an Experten kann ihre Systeme nach der Schwachstelle untersuchen und bei der Behebung unterstützen. Wir helfen Ihnen gern!

Datenschutzrechtliche Auswirkungen der Log4j-Sicherheitslücke

Die Log4j-Sicherheitslücke hat nicht nur technische, sondern auch erhebliche datenschutzrechtliche Konsequenzen. Wenn durch die Schwachstelle personenbezogene Daten kompromittiert werden, liegt eine meldepflichtige Datenschutzpanne nach Art. 33 DSGVO vor. Unternehmen sind dann verpflichtet, die zuständige Aufsichtsbehörde innerhalb von 72 Stunden zu informieren. Bei einem hohen Risiko für die Rechte und Freiheiten der betroffenen Personen müssen auch diese nach Art. 34 DSGVO benachrichtigt werden.

Besonders problematisch ist, dass viele Unternehmen gar nicht wissen, ob ihre Systeme von Log4j betroffen sind. Die Bibliothek ist in unzähligen Java-Anwendungen und Frameworks eingebettet, oft als transitive Abhängigkeit, die nicht direkt sichtbar ist. Eine gründliche Inventarisierung aller eingesetzten Softwarekomponenten ist daher der erste und wichtigste Schritt. Moderne Software-Composition-Analysis-Tools (SCA) können dabei helfen, verborgene Log4j-Instanzen aufzuspüren.

Patch-Management und Sofortmaßnahmen

Die Apache Software Foundation hat zeitnah Patches für Log4j veröffentlicht. Die kritische Schwachstelle CVE-2021-44228 wurde mit Log4j Version 2.17.0 behoben. Unternehmen sollten alle betroffenen Systeme umgehend auf diese Version oder eine neuere aktualisieren. Dabei ist zu beachten, dass auch die Zwischenversionen 2.15.0 und 2.16.0 noch verwundbar waren und nicht als ausreichend sicher gelten.

Falls ein sofortiges Update nicht möglich ist, gibt es temporäre Gegenmaßnahmen. Dazu gehören das Setzen der Systemeigenschaft „log4j2.formatMsgNoLookups“ auf „true“ oder das Entfernen der JndiLookup-Klasse aus dem Classpath. Diese Maßnahmen sind jedoch nur als Übergangslösung zu verstehen und ersetzen keinesfalls das vollständige Patchen der betroffenen Systeme.

Lessons Learned: Supply-Chain-Sicherheit

Die Log4j-Krise hat deutlich gemacht, wie verwundbar die Software-Supply-Chain ist. Eine einzelne Schwachstelle in einer weit verbreiteten Open-Source-Bibliothek kann Millionen von Anwendungen weltweit betreffen. Dies unterstreicht die Notwendigkeit eines Software Bill of Materials (SBOM), also einer vollständigen Auflistung aller in einer Anwendung verwendeten Softwarekomponenten und deren Versionen.

Unternehmen sollten aus der Log4j-Erfahrung lernen und ein robustes Schwachstellenmanagement etablieren. Dazu gehören regelmäßige Sicherheitsscans, die Überwachung von Sicherheitswarnungen für alle eingesetzten Bibliotheken und ein definierter Prozess für das zeitnahe Einspielen von Sicherheitsupdates. Die Zusammenarbeit mit einem externen Datenschutzbeauftragten kann dabei helfen, die datenschutzrechtlichen Aspekte des Schwachstellenmanagements zu berücksichtigen.

Verantwortlichkeit und Haftung

Die Frage der Verantwortlichkeit bei Sicherheitsvorfällen durch Drittanbietersoftware ist komplex. Nach der DSGVO bleibt der Verantwortliche grundsätzlich für die Sicherheit der von ihm verarbeiteten personenbezogenen Daten zuständig, unabhängig davon, ob die Schwachstelle in einer selbst entwickelten oder einer fremden Softwarekomponente liegt. Art. 32 DSGVO verpflichtet den Verantwortlichen, geeignete technische und organisatorische Maßnahmen zu treffen, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten.

Unternehmen, die trotz Kenntnis der Log4j-Schwachstelle keine angemessenen Maßnahmen ergreifen, riskieren nicht nur Bußgelder nach der DSGVO, sondern auch Schadensersatzansprüche betroffener Personen nach Art. 82 DSGVO. Eine dokumentierte und zeitnahe Reaktion auf bekannte Schwachstellen ist daher nicht nur technisch, sondern auch rechtlich geboten.

Präventive Maßnahmen für die Zukunft

Um auf künftige Schwachstellen besser vorbereitet zu sein, sollten Unternehmen einen Incident-Response-Plan entwickeln und regelmäßig testen. Dieser Plan sollte klare Zuständigkeiten definieren, Kommunikationswege festlegen und die Meldepflichten nach der DSGVO berücksichtigen. Regelmäßige Penetrationstests und Sicherheitsaudits helfen, Schwachstellen vorausschauend zu identifizieren, bevor sie von Angreifern ausgenutzt werden können.

Langfristige Auswirkungen auf die IT-Sicherheitsbranche

Die Log4j-Sicherheitslücke hat die gesamte IT-Sicherheitsbranche nachhaltig beeinflusst. Sie hat das Bewusstsein dafür geschärft, wie abhängig die globale IT-Infrastruktur von wenigen, oft ehrenamtlich gepflegten Open-Source-Projekten ist. Log4j wurde jahrelang von einer Handvoll Freiwilliger weiterentwickelt, obwohl es in Anwendungen eingesetzt wird, die Milliarden von Menschen nutzen. Dies hat eine breite Diskussion über die nachhaltige Finanzierung und Unterstützung von Open-Source-Software ausgelöst.

Initiativen wie die OpenSSF (Open Source Security Foundation) und Programme großer Technologiekonzerne zur Sicherheitsauditierung kritischer Open-Source-Projekte sind direkte Reaktionen auf die Log4j-Krise. Auch die EU hat mit dem Cyber Resilience Act einen Gesetzesvorschlag vorgelegt, der Hersteller von Software mit digitalen Elementen zu einem höheren Sicherheitsniveau verpflichten soll. Für Unternehmen bedeutet dies, dass sie sich auf strengere regulatorische Anforderungen an die Softwaresicherheit einstellen müssen.

Meldepflichten nach NIS-2-Richtlinie

Neben den Meldepflichten nach der DSGVO sind Unternehmen zunehmend auch durch die NIS-2-Richtlinie der EU zu schnellen Reaktionen bei Sicherheitsvorfällen verpflichtet. Die NIS-2-Richtlinie, die bis Oktober 2024 in nationales Recht umgesetzt werden musste, erweitert den Kreis der betroffenen Unternehmen erheblich und verschärft die Meldepflichten. Sicherheitsvorfälle wie die Ausnutzung der Log4j-Schwachstelle müssen innerhalb von 24 Stunden an die zuständige Behörde gemeldet werden, gefolgt von einem detaillierten Bericht innerhalb von 72 Stunden.

Unternehmen, die sowohl unter die DSGVO als auch unter die NIS-2-Richtlinie fallen, müssen ihre Meldeprozesse entsprechend koordinieren. Die parallele Einhaltung beider Regelwerke erfordert klare interne Zuständigkeiten und erprobte Abläufe. Ein Datenschutzbeauftragter und ein IT-Sicherheitsbeauftragter sollten eng zusammenarbeiten, um im Ernstfall schnell und rechtskonform reagieren zu können.

Bedeutung eines IT-Notfallplans

Die Log4j-Krise hat eindrucksvoll gezeigt, wie wichtig ein durchdachter IT-Notfallplan ist. Unternehmen, die über einen solchen Plan verfügten, konnten deutlich schneller und gezielter reagieren als solche, die erst im Ernstfall ihre Prozesse improvisieren mussten. Ein IT-Notfallplan sollte klare Eskalationswege definieren, Verantwortlichkeiten festlegen und konkrete Handlungsanweisungen für verschiedene Szenarien enthalten.

Wesentliche Bestandteile eines IT-Notfallplans sind ein aktuelles Inventar aller eingesetzten Software und deren Abhängigkeiten, definierte Kommunikationskanäle für den Krisenfall, Kontaktdaten relevanter Ansprechpartner bei Aufsichtsbehörden und externen Dienstleistern sowie vorbereitete Vorlagen für Meldungen an die Datenschutzbehörde und Benachrichtigungen an betroffene Personen. Der Plan sollte mindestens einmal jährlich in einer Übung getestet und anhand der gewonnenen Erkenntnisse aktualisiert werden.

Auswirkungen auf die Open-Source-Community

Die Log4j-Krise hat eine wichtige Debatte über die Verantwortung für die Sicherheit von Open-Source-Software angestoßen. Viele kritische Infrastrukturkomponenten werden von Freiwilligen in ihrer Freizeit entwickelt und gewartet, ohne dass sie dafür eine angemessene Vergütung erhalten. Die Erwartung, dass diese Entwickler rund um die Uhr für Sicherheitsnotfälle zur Verfügung stehen, ist weder realistisch noch fair.

Große Technologieunternehmen wie Google, Microsoft und Amazon haben als Reaktion auf die Log4j-Krise Millionenbeträge für die Sicherheitsüberprüfung kritischer Open-Source-Projekte bereitgestellt. Auch die EU hat im Rahmen ihres „EU Free and Open Source Software Auditing“ (EU-FOSSA) Projekts die Sicherheitsauditierung wichtiger Open-Source-Bibliotheken finanziert. Diese Initiativen sind ein wichtiger Schritt, können das grundsätzliche Problem der Unterfinanzierung von Open-Source-Infrastruktur jedoch nur teilweise lösen. Unternehmen, die Open-Source-Software einsetzen, sollten daher einen Beitrag zur Sicherheit und Nachhaltigkeit dieser Projekte leisten.

Datenschutz für Ihr Unternehmen

• DSGVO-Beratung
• Verarbeitungsverzeichnis
• TOM Datenschutz
• Datenschutz-Schulung

Erstberatung anfragen