log4j-check

Herramienta de autodiagnóstico para esta tanda de avisos de 2025/2026 de log4j sobre «fallo silencioso de configuración». Cero dependencias en tiempo de ejecución, un único jar, sin conexión a red.

⚠️ Primero dejemos claro el alcance: esta tanda es toda medium, no hay ni una sola RCE, no es como Log4Shell. Su punto en común es que la configuración deja de funcionar sin ningún tipo de error — propiedades ignoradas silenciosamente, propiedades renombradas silenciosamente, logs descartados silenciosamente. Así que con solo mirar el número de versión no puedes saber si te ha afectado o no, hay que leer la configuración. Si estás buscando CVE-2021-44228 (Log4Shell), esta herramienta no te sirve.

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

Qué pregunta responde

Dependabot te dice «log4j tiene N vulnerabilidades». Esta herramienta responde tres cosas que él no responde:

1. ¿A qué versión deberías actualizar exactamente? — No se trata de copiar un advisory, sino de intersecar uno por uno los elementos afectados.
2. De estas 7, ¿cuántas te afectan realmente? — Cada una exige que uses un layout / appender específico, y esas cosas están escritas en log4j2.xml, se pueden leer, y se pueden leer con precisión.
3. ¿Perteneces al grupo de «ya actualicé y creo que está arreglado»? — En este grupo hay dos cadenas de vacíos de parches.

Tres conclusiones fundamentales (todas verificables por tu cuenta)

Uno, 🔥 Quienes actualizaron a 2.25.4 no llegaron al objetivo (la que se omitió, que en su momento Dependabot tampoco podía reportar)

De estas 7, las versiones corregidas de 6 son ≤ 2.25.4. Por eso la gran mayoría llega a la respuesta «actualizar a 2.25.4».

Pero CVE-2026-49844 requiere 2.25.5 (en la línea 2.26 requiere 2.26.1). Su advisory dice textualmente que es una corrección incompleta de CVE-2026-34481:

La corrección publicada en la versión 2.25.4 no cubría todas las rutas de código afectadas. Se asignó CVE-2026-49844 al problema restante …

📌 Corrección (2026-08-16)

Esta sección originalmente decía «y esta es justamente la que Dependabot estructuralmente no puede reportar» — esa frase ahora solo es cierta a medias.

GHSA-qv9r-c865-cp47 fue convertido por GitHub a reviewed el 2026-08-13 y se completó la información del paquete, los dos rangos añadidos son >= 2.13.1, < 2.25.5 y >= 2.26.0, < 2.26.1:

• ✅ Quienes ejecutan 2.x, ahora sí reciben la alerta de Dependabot.
• 🔴 Pero la línea de vista previa 3.x (3.0.0-alpha1 ~ 3.0.0-beta2) hasta ahora no tiene rango correspondiente, esa línea sigue sin poder reportarse.

La conclusión de actualización no cambia en absoluto — log4j-api sigue requiriendo 2.25.5 (la línea 2.26 requiere 2.26.1). Lo único que cambia es «si la máquina puede verlo». La tabla de decisión de esta herramienta se ha actualizado línea por línea según la versión, los números impresos en el informe se calculan a partir de la tabla, ya no están codificados de forma fija.

🔑 Esto en sí mismo merece más recordarse que el ejemplo original: la forma del advisory puede completarse por el upstream con el tiempo, y la conclusión de tu último escaneo no se actualiza sola, ni nadie te avisa. «Ya lo escaneé en su momento» y «ahora es seguro» son dos cosas distintas.

Su GitHub advisory (GHSA-qv9r-c865-cp47)antes del 2026-08-13 era unreviewed, y el array vulnerabilities estaba vacío — sin nombre de paquete, sin rango de versiones, sin versión corregida, durante ese tiempo Dependabot no tenía ningún dato que pudiera comparar con tu árbol de dependencias.

En OSV.dev ocurría lo mismo en ese momento: las otras 6 sí se podían obtener con coordenadas Maven a través del alias GHSA, solo esta no (en OSV ni siquiera tiene alias GHSA). Esta es una corroboración independiente en una tercera fuente, tools/recheck_before_publish.py lo vuelve a verificar cada vez que se ejecuta (ese script ahora también reporta el hecho mismo de «ya se completó»).

🔴 No leas esto como «Dependabot no sirve». Es «ese dato no existía en ese momento», no «esta herramienta tiene un bug». unreviewed es un estado normal del flujo de GitHub, y la completación del 08-13 es precisamente ese flujo completándose normalmente.

La otra cadena es CVE-2025-68161 (2.25.3) → CVE-2026-34477 (2.25.4): la propiedad verifyHostName se introdujo desde 2.12.0, pero fue ignorada silenciosamente hasta 2.25.3, configurarla era como no configurarla. Quienes siguiendo 68161 actualizaron a 2.25.3 y configuraron la verificación de nombre de host con la propiedad (en lugar de system property), siguen afectados.

Dos, la granularidad de decisión es CVE × módulo, en total 4 módulos

Módulo	Elementos afectados	Actualizar a
log4j-core	34477 / 34478 / 34480 / 68161	2.25.4
log4j-api	49844	2.25.5 (línea 2.26: 2.26.1)
log4j-1.2-api	34479	2.25.4
log4j-layout-template-json	34481	2.25.4

La versión objetivo no es el mismo número. Y en el pom de la gran mayoría de proyectos solo se escribe log4j-core — buscando por esa única coordenada solo se encuentran 4, las otras 3 para ellos simplemente no existen.

Esta herramienta escanea por separado las versiones de los cuatro módulos y decide por separado. Cuando las versiones de los cuatro módulos están desalineadas (cobertura de BOM, exclusión manual, dos generaciones de jar metidas en un WAR antiguo) lo reporta explícitamente.

Tres. Reducción de ruido: cada entrada exige un layout / appender específico, y eso está escrito en la configuración

CVE	Condición de activación (tomada del texto oficial)
CVE-2026-34477	atributo verifyHostName de <Ssl> + appender Socket / Syslog / SMTP
CVE-2025-68161	SocketAppender + TLS
CVE-2026-34478	configurar directamente Rfc5424Layout (los que usan SyslogAppender no se ven afectados)
CVE-2026-34480	XmlLayout de log4j-core
CVE-2026-34479	Log4j1XmlLayout del puente, o capa de compatibilidad con log4j 1 + org.apache.log4j.xml.XMLLayout
CVE-2026-34481	JsonTemplateLayout + valores de punto flotante en MapMessage/ObjectMessage
CVE-2026-49844	message resolver de JsonTemplateLayout, o MapMessage.asJson()

Medido (artefacto real, ver abajo): en el mismo conjunto con los cuatro módulos de la versión afectada,

• La configuración es la más común (Console + RollingFile + PatternLayout) → la capa de versión reporta 7 elementos, aciertos reales 0
• La configuración tiene Socket+<Ssl verifyHostName>+Rfc5424Layout+XmlLayout → reporta 7 elementos, aciertos reales 4

Los dos criterios negativos están enunciados textualmente en la documentación oficial y se documentan por separado: Los que usan SyslogAppender no están afectados por 34478; los que solo usan verifyHostname del appender HTTP no están afectados por 34477. El nivel de fiabilidad de este apartado y el de «no lo encontré» son completamente distintos: el primero está respaldado por el texto original, el segundo solo significa que no lo vimos.

🔴 verifyHostName (N mayúscula, <Ssl>, afectado) y verifyHostname (n minúscula, appender HTTP, la documentación oficial indica que no está afectado) difieren solo en una letra de mayúscula/minúscula, y la conclusión es completamente opuesta. Del mismo modo, XmlLayout (34480, log4j-core) es una subcadena de Log4j1XmlLayout (34479, puente). Hacer solo grep por nombre haría que alguien cargue con CVE que no le corresponden. Por eso la capa de configuración hace análisis estructurado en lugar de coincidencia de texto.