Riesgo de vulnerabilidad de Log4j

Ir directamente al resumen generado por IA de esta entrada del blog

¿Te acuerdas de diciembre de 2021? ¿El pánico generalizado que se desató cuando se dio a conocer Log4Shell y, de repente, todos los equipos de ingeniería del planeta se apresuraron a averiguar si utilizaban Log4j, en qué parte de su pila se escondía y con qué rapidez podían parchearlo?

La mayoría de los equipos creen que esa historia terminó a principios de 2022. Aplicaron parches a sus aplicaciones, revisaron sus dependencias, quizá actualizaron algunas bibliotecas y siguieron adelante. Log4j se convirtió en uno de esos incidentes de los que se dice «¿te acuerdas de cuando...?» —algo estresante en su momento, pero ya resuelto—.

Pero no está resuelto. Ni por asomo.

La verdad es que el riesgo de la vulnerabilidad de Log4j no desapareció tras la primera oleada de medidas correctivas de Log4Shell. Simplemente pasó más desapercibido y se hizo más difícil de detectar. Hoy, en 2026, las instancias vulnerables de Log4j siguen ocultas en entornos de producción, incrustadas en lugares donde los equipos dejaron de buscar hace años. Y no es porque los equipos de ingeniería sean descuidados, sino porque la naturaleza del funcionamiento de las dependencias de software hace que «lo parcheamos una vez» sea a menudo una falsa sensación de cierre.

Hablemos de dónde reside ahora el verdadero riesgo de Log4j, por qué sigue reapareciendo y en qué consiste una mitigación realmente eficaz cuando se trabaja con pilas de software modernas que cuentan con múltiples capas de dependencias ocultas.

El panorama de las vulnerabilidades de Log4j más allá de Log4Shell

Log4Shell (CVE-2021-44228) acaparó los titulares, y con razón. Una vulnerabilidad que permite la ejecución remota de código en una biblioteca de registro utilizada por la mitad del ecosistema Java es lo peor que puede pasar. Pero centrarse únicamente en Log4Shell es como preocuparse por el tiburón que se ve a simple vista e ignorar los que nadan en círculos bajo la superficie.

Desde el caso Log4Shell, se han descubierto múltiples vulnerabilidades adicionales en Log4j. Las vulnerabilidades CVE-2021-45046, CVE-2021-45105, CVE-2021-44832 y otras aparecieron en un intervalo de tiempo relativamente corto. Cada una de ellas requirió atención, cada una exigió parches y cada una demostró que Log4j, como componente, tenía problemas de seguridad más profundos que la simple y espectacular vulnerabilidad de ejecución remota de código (RCE).

Lo que resulta especialmente insidioso es que estas vulnerabilidades posteriores suelen afectar a rangos de versiones distintos a los de Log4Shell. Un equipo que actualizara de Log4j 2.14.1 a 2.15.0 para solucionar Log4Shell podría haber quedado expuesto a CVE-2021-45046. La actualización a la versión 2.16.0 solucionó ese problema, pero las versiones anteriores seguían teniendo que lidiar con CVE-2021-44832. Este juego del gato y el ratón con las vulnerabilidades hizo que el seguimiento de las versiones «seguras» se complicara, y muchas organizaciones perdieron la pista de qué sistemas se habían corregido por completo y cuáles solo se habían parcheado parcialmente.

Y luego está el elefante en la habitación: Log4j 1.x. Aunque la mayor parte del pánico público se centró en las vulnerabilidades de Log4j 2.x, Log4j 1.x tiene sus propios problemas de seguridad y dejó de recibir actualizaciones en 2015. Sin embargo, sigue ahí fuera, ejecutándose en sistemas de producción que nunca migraron a Log4j 2.x. Estos sistemas se enfrentan a vulnerabilidades que nunca recibirán parches oficiales porque el código fuente está abandonado.

El panorama de las vulnerabilidades tampoco es estático. Los investigadores de seguridad siguen detectando problemas en las bibliotecas de registro. La atención que Log4Shell ha atraído hacia Log4j y componentes similares significa que hay más ojos buscando problemas. Sería ingenuo pensar que hemos encontrado la última vulnerabilidad de Log4j.

Dónde se esconde Log4j en las pilas modernas

La razón por la que el riesgo de Log4j persiste no es que los equipos lo ignoren deliberadamente. Es que localizar todas las instancias de Log4j en una pila de aplicaciones moderna resulta realmente difícil.

Las dependencias transitivas son el escondite más habitual. Puede que tu aplicación no dependa directamente de Log4j, pero sí lo hace una de tus dependencias. O una de las dependencias de tus dependencias. O bien te encuentras a varias capas de profundidad en un árbol de dependencias y, en algún lugar de ahí, enterrado tres niveles más abajo, se encuentra Log4j 2.14.0.

Las herramientas de análisis de dependencias son útiles, pero no son perfectas. Te informan de las dependencias conocidas que figuran en los archivos de dependencias declarados de tu proyecto, pero no siempre detectan todo. A veces, las bibliotecas ocultan las dependencias, agrupándolas internamente de formas que no se detectan en un análisis de dependencias estándar. Otras veces, la dependencia se encuentra en un artefacto binario que tu escáner no analiza con suficiente profundidad.

Las aplicaciones en contenedores plantean sus propios retos. Es posible que estés ejecutando imágenes de contenedores creadas hace meses o años, antes de que se conociera Log4Shell. La imagen base podría contener versiones vulnerables de Log4j. Las capas de la aplicación podrían añadir más. A menos que recompiles y vuelvas a escanear las imágenes con regularidad, esas vulnerabilidades persisten incluso si tu código fuente actual está limpio.

Las aplicaciones de terceros y el software comercial suelen incluir sus propias dependencias, entre ellas Log4j. ¿Esa herramienta de monitorización empresarial que implementaste en 2020? Es posible que esté ejecutando Log4j 2.12.1 internamente, y tú no tienes visibilidad sobre ello porque se trata de una caja negra del proveedor. Es posible que el proveedor haya lanzado una versión parcheada, pero si no sigues de cerca los avisos de seguridad del proveedor o si las actualizaciones requieren pruebas y tiempos de inactividad significativos, esa instancia vulnerable sigue ahí.

También puedes consultar nuestra guía técnica sobre cómo aplicar una corrección para la vulnerabilidad de Log4j con el fin de detectar dependencias ocultas en pilas de aplicaciones complejas.

Las herramientas de compilación y los entornos de desarrollo a veces contienen versiones vulnerables de Log4j que, aunque no forman parte directamente de su aplicación de producción, siguen representando un riesgo. Los complementos de Jenkins, los repositorios de Maven, las extensiones de IDE... todos ellos pueden contener Log4j, y no siempre se incluyen en los análisis de vulnerabilidades centrados en la producción.

Los sistemas heredados y los códigos fuente congelados son quizás los que plantean mayores dificultades. ¿Esa aplicación crítica de Java que lleva cinco años funcionando sin cambios porque es estable y «nadie quiere tocarla»? Probablemente contenga Log4j vulnerable. Pero actualizarla implica realizar pruebas con las versiones actuales de JDK, validar integraciones que no se han modificado en años y, posiblemente, descubrir que ya no se mantienen algunas dependencias críticas.

Los componentes y dispositivos integrados completan la lista. Los dispositivos de red, los dispositivos de seguridad, los sistemas de IoT y otras aplicaciones Java integradas suelen utilizar Log4j internamente. Estos suelen ser los más difíciles de parchear porque las actualizaciones deben proceder del proveedor, los ciclos de actualización son lentos y, en ocasiones, el propio proveedor ha cesado su actividad o ha dejado de dar soporte al producto.

El denominador común de todos estos casos es la invisibilidad. Estas instancias de Log4j no aparecen en el árbol de dependencias de tu aplicación principal. No están incluidas en tus procesos habituales de aplicación de parches. Se encuentran en los huecos entre lo que crees que estás ejecutando y lo que realmente está implementado.

Por qué la frase «Ya lo arreglamos una vez» no cuaja

Incluso los equipos que llevaron a cabo una corrección exhaustiva a finales de 2021 y principios de 2022 suelen descubrir que vuelven a aparecer instancias vulnerables de Log4j en sus entornos. Esto no se debe a que los parches se hayan revertido, sino a que los ecosistemas de software son dinámicos.

Las nuevas implementaciones introducen vulnerabilidades antiguas. Un desarrollador pone en marcha un nuevo microservicio basado en una plantilla de proyecto de 2020. La plantilla incluye dependencias antiguas. A menos que la gestión de dependencias sea excepcionalmente rigurosa, ese nuevo servicio podría incluir una versión vulnerable de Log4j, aunque su organización haya «corregido» Log4j hace dos años.
Las actualizaciones de las dependencias pueden revertir las correcciones. Si actualizas una biblioteca no relacionada, esta incorpora una versión anterior de una de sus dependencias, lo que, de forma transitiva, recupera una versión vulnerable de Log4j. Es posible que tus reglas de resolución de dependencias no sean lo suficientemente estrictas como para evitarlo, o que el algoritmo de resolución de conflictos de versiones elija la versión vulnerable por motivos de compatibilidad.
Las adquisiciones y las integraciones traen consigo código externo. Tu empresa adquiere otra empresa o se integra con el sistema de un socio. De repente, te haces responsable de su código base, que quizá no haya recibido la misma atención en cuanto a la corrección de Log4j que el tuyo.
La TI en la sombra y las implementaciones no oficiales eluden los procesos estándar. Un equipo implementa algo con prisas, saltándose los análisis de seguridad y los procesos de aprobación habituales. O alguien pone en marcha un servicio «temporal» que acaba convirtiéndose en permanente. Estas implementaciones no autorizadas suelen contener vulnerabilidades que creías que ya se habían eliminado.
La restauración de copias de seguridad y la recuperación ante desastres pueden resucitar versiones vulnerables. Se restaura un sistema a partir de una copia de seguridad realizada antes de que se conociera Log4Shell. O se reconstruye un servicio a partir de artefactos de implementación archivados. A menos que se compruebe específicamente la presencia de Log4j en estos escenarios de recuperación, es posible que se vuelva a poner en producción código vulnerable.

La cuestión fundamental es que la seguridad del software no es un estado que se alcanza, sino un proceso que hay que mantener. Estar «actualizado» no es un estado permanente. Requiere una vigilancia continua, nuevos análisis periódicos y un control constante de lo que realmente se está ejecutando frente a lo que se cree que debería estar ejecutándose.

La evaluación de riesgos en la vida real

No todas las instancias de Log4j entrañan el mismo nivel de riesgo. Conocer cuál es tu exposición real te ayuda a priorizar las medidas correctivas de forma inteligente, en lugar de tratar todo como si fuera una crisis igualmente urgente.

Lo más importante es la exposición. Una instancia vulnerable de Log4j en una aplicación web conectada a Internet que procesa entradas de usuarios no fiables supone un riesgo elevado. Una instancia vulnerable de Log4j en un trabajo de procesamiento por lotes interno que solo maneja datos estructurados procedentes de fuentes fiables supone un riesgo menor. La vulnerabilidad es la misma, pero la posibilidad de explotarla en la práctica es diferente.
La sensibilidad de los datos aumenta el riesgo. Los sistemas que gestionan información de pagos, historiales médicos personales u otros datos regulados se enfrentan a mayores riesgos derivados de las vulnerabilidades de Log4j. Una filtración no solo supone un problema técnico, sino también incumplimientos normativos, responsabilidad legal y sanciones regulatorias.
La ubicación en la red influye en la facilidad de explotación. Las vulnerabilidades de Log4j en sistemas a los que solo se puede acceder desde redes internas son menos explotables de forma inmediata que aquellas expuestas a la Internet pública. Esto no las hace seguras, pero sí cambia el modelo de amenaza y la urgencia de la corrección.
La disponibilidad de exploits influye en el plazo. Una vez que los exploits que aprovechan una vulnerabilidad específica de Log4j están disponibles públicamente y son utilizados activamente por los atacantes, el margen de tiempo para una corrección segura se reduce drásticamente. Las vulnerabilidades anteriores con ecosistemas de exploits maduros son más peligrosas que los problemas recién descubiertos que aún se encuentran en fase de investigación.
Los controles compensatorios reducen el riesgo real. Si las instancias vulnerables de Log4j se encuentran detrás de cortafuegos de aplicaciones web configurados para bloquear los patrones de búsqueda JNDI, o si las herramientas de protección de aplicaciones en tiempo de ejecución supervisan los intentos de explotación, el riesgo práctico es menor que en las implementaciones completamente desprotegidas. Estos no sustituyen a la aplicación de parches, pero sí influyen en el cálculo del riesgo.

El objetivo de la evaluación de riesgos no es justificar la inacción, sino ayudarte a destinar los limitados recursos de corrección a aquellos ámbitos en los que tendrán un mayor impacto en tu situación real de seguridad.

Estrategias prácticas de mitigación

Así pues, has detectado vulnerabilidades de Log4j en tu entorno. Algunas son fáciles de solucionar, otras son complicadas. A continuación te explicamos en qué consiste una mitigación realmente eficaz.

Lo primero es una investigación exhaustiva

No se puede arreglar lo que no se encuentra. Invierte en un análisis exhaustivo antes de empezar a aplicar parches.

Utiliza varios métodos de análisis: análisis de dependencias del código fuente, análisis de imágenes de contenedores, análisis binario de los artefactos implementados y detección en tiempo de ejecución. Cada método detecta aspectos distintos. El análisis del código fuente detecta las dependencias declaradas. El análisis de contenedores detecta vulnerabilidades en las imágenes base. El análisis binario detecta las dependencias ocultas. La detección en tiempo de ejecución identifica lo que realmente se carga en producción.

No limites el análisis a los entornos de producción. Comprueba los entornos de desarrollo, los sistemas de compilación, los entornos de prueba y cualquier otro lugar donde se ejecute código. Un Log4j vulnerable en el portátil de un desarrollador puede que no suponga un riesgo inmediato para la producción, pero representa una deuda técnica y una posible exposición futura.

Documenta tus hallazgos con datos concretos: qué sistemas, qué versiones de Log4j, qué rutas de código utilizan realmente la funcionalidad de registro y cuál es el alcance de la vulnerabilidad. Este inventario se convertirá en tu hoja de ruta para la corrección.

Establecer prioridades en función del riesgo real

Soluciona primero los casos que presenten mayor riesgo. Es decir, los sistemas conectados a Internet, los que gestionan datos confidenciales y cualquier sistema en el que se hayan detectado patrones de explotación activos.

En el caso de los sistemas de riesgo medio, aplica controles compensatorios mientras planificas las medidas correctivas adecuadas. Implementa reglas WAF, activa la supervisión en tiempo de ejecución, restringe el acceso a la red e implementa capas de autenticación adicionales. Estas medidas de mitigación te permiten ganar tiempo para realizar las actualizaciones de forma adecuada, en lugar de hacerlas con prisas.

En el caso de los sistemas de menor riesgo, puedes permitirte plazos más flexibles, pero no dejes que «menor riesgo» se convierta en «nunca se arregla». Establece plazos concretos y cúmplelos.

Actualiza siempre que sea posible

La solución adecuada para las vulnerabilidades de Log4j consiste en actualizar a versiones parcheadas. En el caso de Log4j 2.x, esto significa pasar al menos a la versión 2.17.1, que corrige todas las vulnerabilidades importantes descubiertas hasta principios de 2022.

Prueba minuciosamente las actualizaciones. Los cambios en la versión de Log4j pueden provocar diferencias de comportamiento, especialmente en lo que respecta a la configuración y el rendimiento. Comprueba el funcionamiento en entornos de prueba que reflejen las condiciones de producción antes de implementar los cambios.

Si no es posible actualizar Log4j directamente debido a restricciones en las dependencias principales, intenta actualizar las dependencias que incluyen Log4j. A veces es necesario actualizar varias capas del árbol de dependencias para eliminar el problema.

Dejar de utilizar Log4j 1.x

Si todavía utilizas Log4j 1.x, estás trabajando con un código que ya no recibe soporte ni mantenimiento. Lo más recomendable es migrar a un marco de registro moderno, como Log4j 2.x, Logback u otra opción que reciba mantenimiento.

A menudo se trata de una tarea de gran envergadura. Los formatos de configuración son distintos. Las API han cambiado. Es posible que haya que actualizar las dependencias. Pero es un trabajo necesario que debería haberse hecho hace años y que no se puede posponer indefinidamente.

Planifica la migración por fases. Empieza por los sistemas menos críticos para familiarizarte con los patrones e identificar posibles problemas. Elabora documentación interna y guías de migración. A continuación, ve pasando por tus sistemas de producción de forma sistemática.

Tratamiento de los componentes de proveedores y de terceros

En el caso del software comercial y los componentes proporcionados por los proveedores, consulte los avisos de seguridad y los calendarios de actualización. Muchos proveedores han publicado parches para Log4j, pero no los instalan automáticamente en los entornos de los clientes.

Si los proveedores no han actualizado su software, eleva el asunto a un nivel superior. Envía solicitudes de asistencia, involucra a tus gestores de cuentas y deja claro que esto supone un obstáculo para seguir utilizando el servicio. Los proveedores responden a la presión de los clientes, sobre todo cuando esta proviene de varios clientes a la vez.

En el caso del software de proveedores críticos que no se pueda actualizar, aplica medidas de aislamiento de red y controles de seguridad adicionales. El hecho de que no puedas aplicar parches al software no significa que no puedas limitar su exposición.

Cuando la remediación se topa con un obstáculo

A pesar de todos los esfuerzos, algunas instancias de Log4j se resisten a la corrección. Se trata de sistemas heredados para los que ya no hay soporte técnico y que no se pueden actualizar fácilmente, de software de terceros para el que ya no se publican parches, o de aplicaciones personalizadas que requerirían una profunda remodelación para pasar a versiones más recientes de Log4j.

En estos casos, las opciones de soporte de seguridad ampliado ofrecen una alternativa. Servicios como el de TuxCare «Endless Lifecycle Support for Log4j» de TuxCare pueden proporcionar parches de seguridad para versiones de software antiguas y sin soporte, incluidas las instancias heredadas de Log4j que no recibirán actualizaciones oficiales.

No se trata de una solución a largo plazo ni de una excusa para eludir las actualizaciones necesarias. Sin embargo, es una salida pragmática para aquellas situaciones en las que una corrección inmediata no es técnicamente viable. Si te ves obligado a seguir utilizando Log4j 1.x en una aplicación heredada congelada cuya migración llevaría dieciocho meses, el soporte ampliado puede mantener esa instancia protegida contra las vulnerabilidades conocidas mientras ejecutas el plan de migración.

Piensa en ello como una forma de ganar tiempo sin asumir todo el riesgo que supone utilizar software sin parches. Seguirás teniendo la responsabilidad de modernizar esos sistemas en algún momento, pero no te verás obligado a realizar migraciones precipitadas que podrían provocar nuevos problemas o interrupciones en el negocio.

La clave está en ser claro respecto a la estrategia. La asistencia prolongada no sustituye a una solución adecuada, sino que es un puente que permite resolver el problema en un plazo razonable, en lugar de hacerlo bajo la presión de una crisis.

Desarrollo de prácticas de seguridad sostenibles

La verdadera lección que nos deja Log4j no tiene que ver con esta biblioteca en concreto. Se refiere a la naturaleza de las dependencias de software y a la vigilancia constante que se requiere para gestionar la seguridad en las aplicaciones modernas.

La gestión de dependencias debe ser una práctica de ingeniería fundamental, no algo en lo que se piensa cuando surge una crisis. Esto implica auditorías periódicas de dependencias, análisis automatizados en los procesos de CI/CD, políticas sobre las versiones aceptables de las dependencias y procesos para evaluar y actualizar las dependencias de forma continua.
Los análisis de seguridad no pueden ser una actividad puntual. Las vulnerabilidades se descubren constantemente. El análisis debe ejecutarse de forma continua: en desarrollo, en CI/CD, en producción y en todos los entornos intermedios. Lo que ayer estaba limpio, hoy puede ser vulnerable.
La gestión de riesgos de los proveedores requiere una supervisión activa. Realice un seguimiento del software de terceros que utiliza, supervise los avisos de seguridad de los proveedores, evalúe las prácticas de seguridad de los proveedores antes de la adquisición y establezca acuerdos de nivel de servicio (SLA) claros para las actualizaciones de seguridad en los contratos con los proveedores.
Los procesos de respuesta ante incidentes deben incluir las vulnerabilidades de las dependencias como escenario. Cuando aparezca la próxima vulnerabilidad del nivel de Log4Shell —y habrá una próxima—, ¿con qué rapidez podrá identificar los sistemas afectados? ¿Cómo prioriza la corrección? ¿Quién toma las decisiones sobre el riesgo aceptable y los plazos?
Las decisiones de arquitectura pueden limitar el impacto de las vulnerabilidades. Los microservicios con dependencias aisladas son más fáciles de actualizar que las aplicaciones monolíticas con enormes árboles de dependencias. Las aplicaciones en contenedores con imágenes que se reconstruyen periódicamente incorporan las actualizaciones de seguridad de forma más natural que las máquinas virtuales que llevan mucho tiempo en funcionamiento. La infraestructura inmutable acorta los periodos de vulnerabilidad.

Tu plan de acción

Si estás leyendo esto y te preguntas si aún hay vulnerabilidades ocultas de Log4j acechando en tu entorno, esto es lo que debes hacer:

Realice análisis exhaustivos en todos los entornos utilizando diversos métodos de análisis. No se limite a comprobar sus aplicaciones principales: compruebe también los sistemas de compilación, el software de terceros, las cargas de trabajo en contenedores y los sistemas heredados.

Haz un inventario de lo que encuentres con suficiente detalle como para evaluar el riesgo y planificar las medidas correctivas. No basta con decir «se ha encontrado Log4j 2.14.1», sino que hay que especificar «se ha encontrado en un servicio API orientado al cliente, que gestiona el procesamiento de pagos y está expuesto a Internet».

Establece prioridades de forma rigurosa en función del riesgo real. Soluciona inmediatamente los problemas peligrosos. Planifica medidas correctivas bien pensadas para los casos de riesgo medio. No ignores los casos de bajo riesgo, pero no dejes que obstaculicen el trabajo de alta prioridad.

Aplica medidas de control compensatorias para todo aquello que no puedas solucionar de inmediato. Reglas WAF, segmentación de la red, supervisión en tiempo de ejecución: utiliza todas las herramientas disponibles para reducir la vulnerabilidad práctica.

En situaciones en las que realmente no se sale del atolladero, considera la posibilidad de recurrir a un servicio de asistencia prolongada como estrategia puente. Pero sé sincero sobre lo que es y lo que no es, y establece plazos claros para una solución definitiva.

La verdad incómoda

El riesgo que supone la vulnerabilidad de Log4j no es un problema que se resuelva de una vez por todas y del que luego uno se olvide. Se trata de un problema de seguridad constante que requiere una atención continua, análisis periódicos y un esfuerzo constante para solucionarlo.

Los puntos ciegos no van a desaparecer. Las dependencias seguirán ocultando versiones vulnerables en lugares inesperados. Los sistemas heredados seguirán resistiéndose a las actualizaciones sencillas. Es posible que aún se descubran nuevas vulnerabilidades de Log4j. El trabajo nunca termina del todo.

Pero eso no es motivo para desesperarse ni quedarse paralizados. Es motivo para desarrollar prácticas sostenibles que hagan que la gestión de este tipo de riesgos sea algo habitual, en lugar de excepcional. Los equipos que consideran la seguridad de las dependencias como una labor continua, en lugar de como crisis periódicas, gestionan estas situaciones de forma mucho más eficaz.

No hace falta alcanzar la perfección. Lo que hay que hacer es mantener la visibilidad, gestionar los riesgos de forma inteligente y seguir avanzando. Así es como se traduce en la práctica la seguridad sostenible.

El pánico por Log4Shell ya ha pasado hace tiempo. Pero la historia de la vulnerabilidad de Log4j sigue vigente. Asegúrate de seguir prestándole atención.

Si quieres disfrutar de actualizaciones de seguridad a largo plazo que te mantengan protegido mucho más allá de la fecha de fin de vida útil, echa un vistazo a Soporte de ciclo de vida ilimitado para Log4j.

Resumen