Se trata de una vulnerabilidad informada con CVE-2021-44228 contra el archivo jar log4j-core y se solucionó en Log4J v2.15.0.
Usamos la API Logback a través de slf4j. Esto se confirma con el siguiente código.
final StaticLoggerBinder binder = StaticLoggerBinder.getSingleton(); System.out.println(binder.getLoggerFactory()); System.out.println(binder.getLoggerFactoryClassStr()); //output: //ch.qos.logback.classic.LoggerContext[default] //ch.qos.logback.classic.util.ContextSelectorStaticBinder mvn dependency:tree muestra la API log4j-core (versión <2.15) en classpath (tanto dependencia directa como transitiva).
¿La aplicación sigue siendo vulnerable debido al mantenimiento de log4j-core en classpath ? ¡Gracias!
Para que una vulnerabilidad sea un riesgo para usted, varias cosas deben unirse:
Aquí nadie puede decirte si "2". y ".3" son aplicables en su entorno.
Pero: cuando eliminas 1. , sabes que "2". y "3". ya no son posibles. O al revés, siempre que esté 100% convencido de que no hay una ruta en la que un usuario pueda ingresar datos en su sistema que llegue a la API correspondiente, entonces debería estar bien incluso con dejar la biblioteca en su entorno. Pero como se dijo, tener la biblioteca es el primer elemento obligatorio de la cadena. Entonces, mientras eso está presente, ¡es posible que alguien escriba un código mañana que lo lleve a "2" y "3"!
Por lo tanto, tenga en cuenta la perspectiva de la alta dirección: lo más probable es que la decisión comercial sea: reducir el riesgo a 0, así que asegúrese de no tener el JAR correspondiente en sus máquinas.
En mi entorno bigcorp, las órdenes eran bastante simples: no pierda tiempo analizando si su código usa las interfaces correspondientes. Cuando sus proyectos contengan el JAR vulnerable, actualícelo inmediatamente. Período.