log4j-check

Outil d'auto-vérification pour la série d'avis 2025/2026 de log4j concernant la « défaillance silencieuse de configuration ». Zéro dépendance à l'exécution, un seul jar, sans connexion réseau.

⚠️ Précisons d'abord le périmètre : cette série est entièrement de sévérité medium, pas une seule RCE, ce n'est pas du type Log4Shell. Leur point commun est que la configuration a cessé de fonctionner sans aucune erreur — des propriétés sont silencieusement ignorées, des propriétés sont silencieusement renommées, des logs sont silencieusement perdus. Donc le simple numéro de version ne permet pas de savoir si vous êtes concerné, il faut lire la configuration. Si vous cherchez CVE-2021-44228 (Log4Shell), cet outil ne vous aidera pas.

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

À quelles questions répond-il

Dependabot vous dit « log4j a N vulnérabilités ». Cet outil répond à trois questions auxquelles il ne répond pas :

1. Vers quelle version devez-vous réellement monter ? — Il ne s'agit pas de recopier un avis donné, mais de croiser un par un les entrées concernées.
2. Sur ces 7 entrées, combien vous concernent vraiment ? — Chacune exige que vous utilisiez un layout / appender précis, et ces éléments sont écrits dans log4j2.xml, ils sont lisibles, et lisibles avec précision.
3. Faites-vous partie de ceux qui « ont déjà mis à jour et croient avoir terminé » ? — Dans ce lot, il y a deux chaînes de correctifs manquants.

Trois conclusions porteuses (toutes vérifiables par vous-même)

1. 🔥 Ceux qui sont passés à 2.25.4 ne sont pas allés au bout (l'entrée manquée, que Dependabot non plus ne pouvait pas signaler à l'époque)

Sur ces 7 entrées, les versions corrigées de 6 d'entre elles sont ≤ 2.25.4. La grande majorité des gens en conclut donc « passer à 2.25.4 ».

Mais CVE-2026-49844 exige 2.25.5 (sur la branche 2.26, il faut 2.26.1). Son avis indique lui-même être un correctif incomplet de CVE-2026-34481 :

Le correctif publié dans la version 2.25.4 ne couvrait pas tous les chemins de code concernés. La CVE-2026-49844 a été attribuée au problème restant …

📌 Correction (2026-08-16)

Cette section disait à l'origine « et c'est précisément celle que Dependabot ne peut structurellement pas signaler » — cette phrase n'est désormais vraie qu'à moitié.

GHSA-qv9r-c865-cp47 a été converti par GitHub en reviewed le 2026-08-13 et complété avec les informations de paquet ; les deux intervalles ajoutés sont >= 2.13.1, < 2.25.5 et >= 2.26.0, < 2.26.1 :

• ✅ Ceux qui font tourner 2.x reçoivent désormais les alertes Dependabot.
• 🔴 Mais la ligne preview 3.x (3.0.0-alpha1 ~ 3.0.0-beta2) n'a toujours pas d'intervalle correspondant, et cette ligne reste non signalable.

La conclusion de mise à jour ne change pas du tout — log4j-api exige toujours 2.25.5 (la ligne 2.26 exige 2.26.1). Seul change le fait que « la machine le voie ou non ». La table de décision de cet outil a été mise à jour ligne de version par ligne de version ; les chiffres imprimés dans le rapport sont calculés à partir de la table, et non plus codés en dur.

🔑 Ce fait lui-même mérite d'être retenu plus que l'exemple initial : la forme des avis est complétée en amont au fil du temps, et la conclusion de votre dernier scan ne se met pas à jour toute seule, et personne ne vous préviendra. « On a scanné à l'époque » et « c'est sûr maintenant » sont deux choses différentes.

Son avis GitHub (GHSA-qv9r-c865-cp47) avant le 2026-08-13 était unreviewed, et le tableau vulnerabilities était vide — pas de nom de paquet, pas d'intervalle de versions, pas de version corrigée ; pendant cette période, Dependabot n'avait aucune donnée à comparer avec votre arbre de dépendances.

Sur OSV.dev, il en allait de même à l'époque : les 6 autres entrées permettaient d'obtenir les coordonnées Maven via l'alias GHSA, seule celle-ci ne le permettait pas (dans OSV, elle n'avait même pas d'alias GHSA). C'est une corroboration indépendante sur une troisième source ; tools/recheck_before_publish.py revérifie à chaque réexécution (ce script signale désormais aussi le fait même que « c'est désormais complété »).

🔴 Ne lisez pas cette entrée comme « Dependabot ne marche pas bien ». C'est « cette donnée n'existait pas à l'époque », pas « cet outil a un bug ». unreviewed est un état normal du processus GitHub, et le complément du 08-13 est précisément ce processus qui s'achève normalement.

L'autre chaîne est CVE-2025-68161 (2.25.3) → CVE-2026-34477 (2.25.4) : l'attribut verifyHostName a été introduit depuis 2.12.0, mais a été silencieusement ignoré jusqu'à 2.25.3 ; le configurer revenait à ne pas le configurer. Ceux qui sont passés à 2.25.3 selon 68161 et qui configurent la vérification du nom d'hôte via l'attribut (et non via une propriété système) sont toujours touchés.

2. La granularité de décision est CVE × module, soit 4 modules au total

Module	Entrées concernées	Version cible
log4j-core	34477 / 34478 / 34480 / 68161	2.25.4
log4j-api	49844	2.25.5 (ligne 2.26 : 2.26.1)
log4j-1.2-api	34479	2.25.4
log4j-layout-template-json	34481	2.25.4

La version cible n'est pas le même chiffre. Or la plupart des projets n'écrivent que log4j-core dans leur pom — en interrogeant cette seule coordonnée, on n'obtient que 4 entrées ; les 3 autres n'existent tout simplement pas pour eux.

Cet outil scanne les quatre modules séparément et prend une décision séparément pour chacun. Lorsque les versions des quatre modules divergent (couverture par le BOM, exclusions manuelles, deux générations de jars enfouies dans un vieux WAR), il le signale explicitement.

Trois, réduction du bruit : chacune exige un layout / appender spécifique, et cela est écrit dans la configuration

CVE	Condition de déclenchement (tirée du texte officiel)
CVE-2026-34477	propriété verifyHostName de <Ssl> + appender Socket / Syslog / SMTP
CVE-2025-68161	SocketAppender + TLS
CVE-2026-34478	configuration directe de Rfc5424Layout (ceux utilisant SyslogAppender ne sont pas affectés)
CVE-2026-34480	XmlLayout de log4j-core
CVE-2026-34479	Log4j1XmlLayout du pont, ou couche de compatibilité log4j 1 + org.apache.log4j.xml.XMLLayout
CVE-2026-34481	JsonTemplateLayout + valeurs à virgule flottante dans MapMessage/ObjectMessage
CVE-2026-49844	résolveur de message de JsonTemplateLayout, ou MapMessage.asJson()

Testé sur des composants réels (voir ci-dessous) : un même ensemble contenant les quatre modules affectés,

• Configuration du type le plus courant (Console + RollingFile + PatternLayout) → la couche de version signale 7 entrées, dont 0 réellement confirmées
• Configuration contenant Socket+<Ssl verifyHostName>+Rfc5424Layout+XmlLayout → 7 entrées signalées, dont 4 réellement confirmées

Les deux critères négatifs sont explicitement énoncés dans le texte officiel, documentés séparément : Ceux qui utilisent SyslogAppender ne sont pas concernés par 34478 ; ceux qui utilisent uniquement le verifyHostname de l'appender HTTP ne sont pas concernés par 34477. Le degré de fiabilité de cette catégorie est totalement différent de celui de « je n'ai pas trouvé » — la première est corroborée par le texte officiel, la seconde signifie seulement que nous ne l'avons pas vue.