log4j-check

Strumento di autoverifica per il lotto di avvisi 2025/2026 di log4j relativi alla "disattivazione silenziosa della configurazione". Zero dipendenze a runtime, singolo jar, nessuna connessione di rete.

⚠️ Chiariamo subito i termini: questo lotto è tutto di livello medium, non c'è nessuna RCE, non è il tipo di Log4Shell. Il loro punto in comune è che la configurazione smette di funzionare senza alcun errore — proprietà ignorate silenziosamente, proprietà rinominate silenziosamente, log scartati silenziosamente. Quindi guardando solo il numero di versione non puoi capire se sei stato colpito o no, devi leggere la configurazione. Se stai cercando CVE-2021-44228 (Log4Shell), questo strumento non ti può aiutare.

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

A quali domande risponde

Dependabot ti dice «log4j ha N vulnerabilità». Questo strumento risponde a tre domande a cui lui non risponde:

1. A quale versione devi davvero aggiornare? —— Non copiare un singolo advisory, ma intersecare una per una le voci che hai colpito.
2. Quante di queste 7 voci ti riguardano davvero? —— Ognuna richiede che tu usi un determinato layout / appender, e queste cose sono scritte in log4j2.xml, si possono leggere, e si possono leggere con precisione.
3. Fai parte di quelli che «hanno già aggiornato e pensano di aver finito»? —— In questo gruppo ci sono due catene di lacune nelle patch.

Tre conclusioni portanti (tutte verificabili autonomamente)

Uno, 🔥 Chi è passato alla 2.25.4 non è arrivato al punto giusto (la voce mancante, che un tempo nemmeno Dependabot riusciva a segnalare)

Di queste 7 voci, le versioni correttive di 6 sono ≤ 2.25.4. Così la stragrande maggioranza delle persone arriva alla risposta «aggiorna alla 2.25.4».

Ma CVE-2026-49844 richiede la 2.25.5 (sulla linea 2.26 serve la 2.26.1). Il suo advisory dichiara testualmente di essere una correzione incompleta di CVE-2026-34481:

La correzione rilasciata nella versione 2.25.4 non copriva tutti i percorsi di codice interessati. A CVE-2026-49844 è stato assegnato il problema rimanente …

📌 Correzione (2026-08-16)

Questa sezione diceva originariamente «e questa è proprio la voce che Dependabot, per ragioni strutturali, non riesce a segnalare» —— quella frase ora è vera solo a metà.

GHSA-qv9r-c865-cp47 è stato convertito da GitHub in reviewed il 2026-08-13 e completato con le informazioni sul pacchetto, i due intervalli aggiunti sono >= 2.13.1, < 2.25.5 e >= 2.26.0, < 2.26.1:

• ✅ Chi esegue la 2.x ora riceve gli avvisi di Dependabot.
• 🔴 Ma la linea di anteprima 3.x (3.0.0-alpha1 ~ 3.0.0-beta2) finora non ha un intervallo corrispondente, e quella linea continua a non essere segnalabile.

La conclusione sull'aggiornamento non è affatto cambiata —— log4j-api richiede comunque la 2.25.5 (la linea 2.26 richiede la 2.26.1). È cambiato solo «se la macchina riesce a vederlo». La tabella di valutazione di questo strumento è stata aggiornata voce per voce secondo le linee di versione; i numeri stampati nel report sono calcolati dalla tabella, non più hardcoded.

🔑 Questo fatto in sé merita più di essere ricordato rispetto al vecchio esempio: la forma degli advisory viene completata a monte nel tempo, e le conclusioni della tua ultima scansione non si aggiornano da sole, né nessuno ti avvisa. «All'epoca ho scansionato» e «ora è sicuro» sono due cose diverse.

Il suo GitHub advisory (GHSA-qv9r-c865-cp47)prima del 2026-08-13 era unreviewed, e l'array vulnerabilities era vuoto —— nessun nome di pacchetto, nessun intervallo di versioni, nessuna versione correttiva, in quel periodo Dependabot non aveva alcun dato da confrontare con il tuo albero delle dipendenze.

Su OSV.dev all'epoca era lo stesso: le altre 6 voci riuscivano a ottenere le coordinate Maven tramite l'alias GHSA, solo questa no (in OSV non aveva nemmeno un alias GHSA). Questa è una terza prova indipendente da una terza fonte, tools/recheck_before_publish.py la riverifica a ogni riesecuzione (lo script ora segnala anche il fatto stesso che «è stato completato»).

🔴 Non leggere questa voce come «Dependabot non funziona bene». È «questo dato all'epoca non esisteva», non «questo strumento ha un bug». unreviewed è uno stato normale del flusso di GitHub, e il completamento del 08-13 è proprio quel flusso che si conclude normalmente.

L'altra catena è CVE-2025-68161 (2.25.3) → CVE-2026-34477 (2.25.4): l'attributo verifyHostName è stato introdotto dalla 2.12.0, ma fino alla 2.25.3 è stato silenziosamente ignorato, configurarlo equivaleva a non configurarlo. Chi è passato alla 2.25.3 seguendo la 68161 e configura la verifica del nome host tramite l'attributo (invece che tramite system property) viene comunque colpito.

Due, la granularità di valutazione è CVE × modulo, per un totale di 4 moduli

Modulo	Voci colpite	Versione a cui aggiornare
log4j-core	34477 / 34478 / 34480 / 68161	2.25.4
log4j-api	49844	2.25.5 (linea 2.26: 2.26.1)
log4j-1.2-api	34479	2.25.4
log4j-layout-template-json	34481	2.25.4

La versione di destinazione non è lo stesso numero. E nel pom della stragrande maggioranza dei progetti è scritto solo log4j-core —— cercando a partire da quella singola coordinata si trovano solo 4 voci, le altre 3 per loro semplicemente non esistono.

Questo strumento scansiona le versioni dei quattro moduli separatamente e le valuta separatamente. Quando le versioni dei quattro moduli sono sfasate (copertura del BOM, esclusioni manuali, due generazioni di jar infilate in un vecchio WAR) lo segnala esplicitamente.

Tre, riduzione del rumore: ognuna richiede uno specifico layout / appender, e questo è scritto nella configurazione

CVE	Condizione di attivazione (dal testo ufficiale)
CVE-2026-34477	attributo verifyHostName di <Ssl> + appender Socket / Syslog / SMTP
CVE-2025-68161	SocketAppender + TLS
CVE-2026-34478	configurazione diretta di Rfc5424Layout (chi usa SyslogAppender non è interessato)
CVE-2026-34480	XmlLayout di log4j-core
CVE-2026-34479	Log4j1XmlLayout del bridge, oppure livello di compatibilità log4j 1 + org.apache.log4j.xml.XMLLayout
CVE-2026-34481	JsonTemplateLayout + valori in virgola mobile in MapMessage/ObjectMessage
CVE-2026-49844	message resolver di JsonTemplateLayout, oppure MapMessage.asJson()

Test effettuato (componente reale, vedi sotto): lo stesso set con i quattro moduli della versione interessata,

• La configurazione è quella più comune (Console + RollingFile + PatternLayout) → il livello di versione segnala 7 voci, di cui realmente colpite 0
• La configurazione contiene Socket+<Ssl verifyHostName>+Rfc5424Layout+XmlLayout → segnala 7 voci, di cui realmente colpite 4

I due criteri negativi sono dichiarati esplicitamente nel testo ufficiale, documentati separatamente: Chi usa SyslogAppender non è colpito da 34478; chi usa solo verifyHostname dell'HTTP appender non è colpito da 34477. Questo livello e «non l'ho trovato» hanno un grado di affidabilità completamente diverso — il primo è supportato dal testo ufficiale, il secondo è solo ciò che non abbiamo visto.