log4j-check

Ein Selbstprüfungstool für die Log4j-2025/2026-Welle von „stiller Konfigurationsfehler"-Advisories. Keine Laufzeitabhängigkeiten, ein einzelnes Jar, keine Netzwerkverbindung.

⚠️ Zuerst die Einordnung klarstellen: Diese Welle besteht ausschließlich aus Medium-Schwachstellen, keine einzige RCE, nicht vergleichbar mit Log4Shell. Gemeinsam ist ihnen, dass die Konfiguration ohne jegliche Fehlermeldung unwirksam wird – Eigenschaften werden stillschweigend ignoriert, Eigenschaften werden stillschweigend umbenannt, Logs werden stillschweigend verworfen. Allein anhand der Versionsnummer lässt sich also nicht erkennen, ob man betroffen ist; man muss die Konfiguration lesen. Wenn Sie nach CVE-2021-44228 (Log4Shell) suchen, kann dieses Tool Ihnen nicht helfen.

java -jar log4j-check.jar app.jar          # fat jar 里带配置,一步到位
java -jar log4j-check.jar ./target ./src   # 构建产物 + 源码
java -jar log4j-check.jar ~/.m2/repository --no-config

Welche Frage beantwortet es

Dependabot sagt dir „log4j hat N Schwachstellen“. Dieses Tool beantwortet drei Fragen, die es nicht beantwortet:

1. Auf welche Version solltest du eigentlich aktualisieren? — Nicht einfach irgendeine Advisory abschreiben, sondern die zutreffenden Einträge einzeln schneiden.
2. Wie viele der 7 triffst du wirklich? — Jeder erfordert, dass du ein bestimmtes Layout / einen bestimmten Appender verwendest, und diese Dinge stehen in log4j2.xml, sie sind lesbar, und zwar genau lesbar.
3. Gehörst du zu denen, die „schon aktualisiert haben und glauben, es sei behoben“? — In dieser Gruppe gibt es zwei Patch-Lücken-Ketten.

Drei tragende Schlussfolgerungen (alle selbst überprüfbar)

Eins, 🔥 Wer auf 2.25.4 aktualisiert hat, ist nicht weit genug gegangen (der übersehene Eintrag, den auch Dependabot nicht melden konnte)

Von diesen 7 Einträgen haben 6 eine Fix-Version ≤ 2.25.4. Daher kommen die meisten zu der Antwort „auf 2.25.4 aktualisieren“.

Aber CVE-2026-49844 erfordert 2.25.5 (auf der 2.26-Linie 2.26.1). In der Advisory steht im Original, dass es sich um einen unvollständigen Fix von CVE-2026-34481 handelt:

Der in Version 2.25.4 veröffentlichte Fix deckte nicht alle betroffenen Codepfade ab. CVE-2026-49844 wurde dem verbleibenden Problem zugewiesen …

📌 Korrektur (2026-08-16)

Dieser Abschnitt lautete ursprünglich „und genau dieser Eintrag ist derjenige, den Dependabot strukturell nicht melden kann“ — dieser Satz stimmt jetzt nur noch zur Hälfte.

GHSA-qv9r-c865-cp47 wurde am 2026-08-13 von GitHub auf reviewed gesetzt und die Paketinformationen ergänzt, die beiden ergänzten Bereiche sind >= 2.13.1, < 2.25.5 und >= 2.26.0, < 2.26.1:

• ✅ Wer 2.x ausführt, erhält jetzt Dependabot-Warnungen.
• 🔴 Aber die 3.x-Vorschau-Linie (3.0.0-alpha1 ~ 3.0.0-beta2) hat bis heute keinen entsprechenden Bereich, diese Linie wird weiterhin nicht gemeldet.

Die Upgrade-Schlussfolgerung hat sich überhaupt nicht geändert — log4j-api erfordert weiterhin 2.25.5 (die 2.26-Linie erfordert 2.26.1). Geändert hat sich nur, ob „die Maschine es sehen kann“. Die Bewertungstabelle dieses Tools wurde pro Versionslinie einzeln aktualisiert, die im Bericht gedruckten Zahlen werden aus der Tabelle berechnet und nicht mehr fest kodiert.

🔑 Diese Sache selbst ist es wert, besser im Gedächtnis behalten zu werden als das ursprüngliche Beispiel: Die Form einer Advisory wird mit der Zeit von Upstream ergänzt, und die Schlussfolgerung deines letzten Scans aktualisiert sich nicht von selbst, und niemand benachrichtigt dich. „Damals gescannt“ und „jetzt sicher“ sind zwei verschiedene Dinge.

Ihre GitHub-Advisory (GHSA-qv9r-c865-cp47) war vor dem 2026-08-13 unreviewed, und das vulnerabilities-Array war leer — kein Paketname, kein Versionsbereich, keine Fix-Version, in dieser Zeit konnte Dependabot keine Daten bekommen, die es mit deinem Abhängigkeitsbaum vergleichen konnte.

Auf OSV.dev war es damals genauso: Die anderen 6 konnten über den GHSA-Alias Maven-Koordinaten erhalten, nur dieser nicht (er hat in OSV nicht einmal einen GHSA-Alias). Dies ist ein unabhängiger Beleg aus einer dritten Quelle, tools/recheck_before_publish.py überprüft dies bei jedem erneuten Lauf (das Skript meldet jetzt auch „bereits ergänzt“ selbst).

🔴 Lies diesen Eintrag nicht als „Dependabot ist unbrauchbar“. Es ist „diese Daten existierten damals nicht“, nicht „dieses Tool hat einen Bug“. unreviewed ist ein normaler Prozesszustand von GitHub, und die Ergänzung am 08-13 ist genau das normale Durchlaufen dieses Prozesses.

Die andere Kette ist CVE-2025-68161 (2.25.3) → CVE-2026-34477 (2.25.4): Das Attribut verifyHostName wurde seit 2.12.0 eingeführt, aber bis 2.25.3 durchgehend stillschweigend ignoriert, konfiguriert war gleichbedeutend mit nicht konfiguriert. Wer gemäß 68161 auf 2.25.3 aktualisiert hat und die Hostnamenprüfung über das Attribut (statt über die System-Property) konfiguriert, ist weiterhin betroffen.

Zwei, die Bewertungsgranularität ist CVE × Modul, insgesamt 4 Module

Modul	Zutreffende Einträge	Sollte aktualisiert werden auf
log4j-core	34477 / 34478 / 34480 / 68161	2.25.4
log4j-api	49844	2.25.5 (2.26-Linie: 2.26.1)
log4j-1.2-api	34479	2.25.4
log4j-layout-template-json	34481	2.25.4

Die Zielversionen sind nicht dieselbe Zahl. Und in den pom-Dateien der allermeisten Projekte steht nur log4j-core — über diese eine Koordinate findet man nur 4 Einträge, die anderen 3 existieren für sie überhaupt nicht.

Dieses Tool scannt die vier Module jeweils separat auf ihre Version und bewertet sie jeweils separat. Wenn die Versionen der vier Module auseinanderlaufen (BOM-Überschreibung, manuelle Ausschlüsse, zwei Generationen von jars in einem alten WAR), meldet es dies ausdrücklich.

Drei, Rauschunterdrückung: Jeder Eintrag erfordert ein bestimmtes Layout / einen bestimmten Appender, und das steht in der Konfiguration

CVE	Auslösebedingung (aus dem offiziellen Originaltext)
CVE-2026-34477	verifyHostName-Attribut von <Ssl> + Socket-/Syslog-/SMTP-Appender
CVE-2025-68161	SocketAppender + TLS
CVE-2026-34478	Direkte Konfiguration von Rfc5424Layout (bei Verwendung von SyslogAppender nicht betroffen)
CVE-2026-34480	XmlLayout von log4j-core
CVE-2026-34479	Log4j1XmlLayout der Bridge oder log4j-1-Kompatibilitätsschicht + org.apache.log4j.xml.XMLLayout
CVE-2026-34481	JsonTemplateLayout + Gleitkommawerte in MapMessage/ObjectMessage
CVE-2026-49844	Message-Resolver von JsonTemplateLayout oder MapMessage.asJson()

Praxisgetestet (echte Artefakte, siehe unten): dasselbe Set mit den vier Modulen der betroffenen Version,

• Die Konfiguration ist die häufigste Art (Console + RollingFile + PatternLayout) → Versionsebene meldet 7 Einträge, tatsächlich zutreffend 0 Einträge
• Die Konfiguration enthält Socket+<Ssl verifyHostName>+Rfc5424Layout+XmlLayout → meldet 7 Einträge, tatsächlich zutreffend 4 Einträge

Zwei Negativkriterien sind ausdrücklich im offiziellen Text genannt und stehen als eigener Abschnitt: Wer SyslogAppender verwendet, ist nicht von 34478 betroffen; wer nur den HTTP-Appender mit verifyHostname verwendet, ist nicht von 34477 betroffen. Dieser Abschnitt hat eine völlig andere Verlässlichkeit als „ich habe nichts gefunden“ – Ersteres ist durch den Originaltext belegt, Letzteres bedeutet nur, dass wir es nicht gesehen haben.