Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Se publicó el parche. Se cerró el ticket. Se presentó el informe de análisis posterior. Y, sin embargo, más de cuatro años después, los escáneres siguen detectándolo. Se trata de la diferencia entre «parcheado» y «demostrablemente seguro», y de lo que Log4j reveló realmente sobre los sistemas subyacentes.
Hay un tipo concreto de agotamiento que se produce tras un incidente de seguridad grave. La carrera contrarreloj para aplicar los parches, las reuniones generales, el inventario frenético de los sistemas afectados y, por fin, el momento en el que alguien cierra el ticket de seguimiento y escribe «resuelto» en el campo de estado. Esa sensación de cierre es real. Pero también es, en muchos casos, un poco prematura.
Log4Shell —la vulnerabilidad crítica de ejecución remota de código revelada en diciembre de 2021 en la biblioteca Apache Log4j— sigue siendo el ejemplo más claro que se recuerda en los últimos tiempos de lo que ocurre cuando un componente profundamente integrado en el ecosistema Java resulta estar presente en todas partes y ser universalmente peligroso. La respuesta fue enorme. Miles de organizaciones aplicaron los parches en cuestión de días. Las agencias gubernamentales emitieron directivas de emergencia. Los equipos de seguridad trabajaron durante los fines de semana.
Y, sin embargo, el problema de seguridad de Java que puso de manifiesto Log4j no ha desaparecido. No me refiero al CVE concreto, sino a las condiciones que lo hicieron posible y a la incertidumbre residual que persiste incluso después de aplicar los parches. Comprender esa incertidumbre es la verdadera lección, y se aplica mucho más allá de cualquier biblioteca concreta.
Qué significa realmente «parcheado»
Cuando una organización anuncia que ha aplicado el parche a Log4j, esa afirmación conlleva una suposición implícita: que se han identificado y actualizado todas las instancias de la biblioteca vulnerable. En la práctica, esta suposición resulta extraordinariamente difícil de verificar en entornos Java complejos.
Las aplicaciones Java se distribuyen como artefactos empaquetados: archivos JAR, archivos WAR o JAR «fat» creados con herramientas como Maven Shade o el empaquetado integrado de Spring Boot. Estos paquetes incluyen sus dependencias en el momento de la compilación. Una versión vulnerable de Log4j no solo aparece en el manifiesto de dependencias; puede estar físicamente integrada en otro archivo JAR, que a su vez se encuentra dentro de un WAR, el cual se ha implementado en un servidor de aplicaciones del que tu equipo de seguridad ni siquiera sabía que ejecutaba Java.
Para saber cómo identificar y resolver de forma sistemática estas dependencias profundamente arraigadas, consulta nuestra guía completa sobre cómo aplicar una corrección para la vulnerabilidad de Log4j.
No se trata de un caso aislado. Durante la respuesta al incidente Log4Shell, los investigadores de seguridad descubrieron instancias vulnerables de Log4j anidadas a cuatro y cinco niveles de profundidad dentro del software empresarial de proveedores que, a su vez, no se habían dado cuenta de que la biblioteca estaba presente. Las directrices de la CISA en aquel momento hacían hincapié en la necesidad de identificar todos los activos afectados y advertían de que un análisis inicial por sí solo no bastaba para confirmar un inventario completo. El problema era estructural.
La diferencia entre lo que declara un manifiesto de dependencias y lo que realmente se ejecuta en tiempo de ejecución no es una discrepancia menor. Se trata de un problema fundamental de visibilidad en la gestión de dependencias de Java, y Log4Shell hizo que fuera imposible ignorarlo.
Las repercusiones a largo plazo de un incidente grave
Los incidentes de seguridad de la magnitud de Log4j no se resuelven por completo. Tienen una «cola larga»: períodos prolongados durante los cuales la aplicación de parches se ha completado técnicamente en los sistemas que se ha pensado comprobar, mientras que persisten instancias vulnerables en los sistemas que nadie ha tenido en cuenta.
Las repercusiones a largo plazo de Log4j han sido inusualmente persistentes. Esto se debe, en parte, a que Java es un entorno de ejecución inusualmente «pegajoso». Las aplicaciones Java se implementan en entornos que no fueron diseñados para actualizaciones frecuentes: sistemas industriales integrados, plataformas financieras heredadas, software para dispositivos médicos y aplicaciones empresariales suministradas por proveedores en las que el cliente no controla la compilación. No se trata de contextos poco conocidos. Representan una parte significativa de la base instalada de Java.
DICIEMBRE DE 2021
Se da a conocer el vulnerabilidad CVE-2021-44228. Comienza a nivel mundial la aplicación de parches de emergencia. Se lanza la versión 2.15.0 de Log4j; posteriormente se descubre que se trata de una corrección incompleta en determinadas configuraciones.
DICIEMBRE DE 2021 – ENERO DE 2022
A continuación se enumeran tres CVE adicionales, todos ellos revelados en diciembre de 2021: CVE-2021-45046, CVE-2021-45105 y CVE-2021-44832. Los equipos que habían aplicado el parche 2.15.0 deben volver a hacerlo. Los ejercicios de inventario revelan casos inesperados en el software de los proveedores y en los sistemas integrados.
2022
La CISA añadió Log4Shell a su catálogo de vulnerabilidades explotadas conocidas, y los autores de amenazas siguieron incorporándola a sus conjuntos de herramientas habituales junto con las CVE más recientes. La explotación de sistemas heredados sin parches continuó.
2023 – ACTUALIDAD
Aún se detectan actividades de análisis y explotación de Log4Shell años después de su divulgación; un estudio longitudinal realizado en 2026 observó que el tráfico relacionado continuaba hasta octubre de 2025. Las aplicaciones Java integradas y suministradas por los proveedores siguen constituyendo una vulnerabilidad persistente. El incidente aparece como «resuelto» en los registros oficiales de la mayoría de las organizaciones, pero no en la práctica.
Esta cronología pone de manifiesto algo importante: las vulnerabilidades graves no se rigen por el cierre de los tickets de incidencias. Persisten en aquellas partes de la infraestructura que recibieron menos atención durante la respuesta inicial: el sistema heredado del que el departamento de TI se había olvidado, el dispositivo de un proveedor cuyo fabricante tardó seis meses en publicar un parche y el servicio en contenedor que se reconstruyó a partir de una imagen base antigua.
Cómo ha cambiado Log4j el debate sobre la seguridad interna
Si Log4Shell tuvo un efecto duradero en las organizaciones más allá de los parches, fue este: obligó a reconocer lo poco que la mayoría de los equipos de ingeniería sabían realmente sobre su propio software.
La pregunta «¿utilizamos Log4j?» resultó ser mucho más difícil de responder de lo que nadie esperaba, y esa dificultad resultó ser una lección provechosa. Los arquitectos de seguridad suelen describir la misma toma de conciencia a posteriori. Creían que disponían de un buen inventario porque tenían un manifiesto, pero un manifiesto es una lista de lo que uno cree haber instalado, no una lista de lo que realmente se está ejecutando.
Antes de Log4Shell, las listas de materiales de software (SBOM) eran un tema de nicho: algo que debatían los equipos de cumplimiento normativo, pero que los equipos de ingeniería no consideraban prioritario. Tras Log4Shell, el debate sobre las SBOM pasó a formar parte de las prácticas de seguridad habituales. El decreto ejecutivo del Gobierno de EE. UU. sobre seguridad del software, firmado en mayo de 2021, meses antes de que se revelara la vulnerabilidad de Log4j, ya había establecido las SBOM como un requisito básico. Log4Shell demostró por qué esa expectativa era razonable.
La conversación también giró en torno a la responsabilidad. En las grandes organizaciones, la pregunta «¿quién es responsable de las dependencias de esta aplicación?» a menudo no tiene una respuesta clara. Es posible que el equipo de ingeniería que desarrolló la aplicación ya no esté en la empresa. El equipo de la plataforma gestiona la infraestructura. El equipo de seguridad puede señalar la vulnerabilidad, pero no puede integrar la corrección. Log4j creó situaciones en las que tres equipos diferentes esperaban a que los demás actuaran, mientras el tiempo se agotaba.
La confianza y el problema de los proveedores
Log4Shell también dañó algo más difícil de cuantificar: la confianza en el software suministrado por los proveedores. Muchas organizaciones descubrieron que las aplicaciones y los dispositivos comerciales que habían adquirido —y por los que pagaban contratos de asistencia técnica— contenían instancias vulnerables de Log4j que el proveedor no había revelado y que no podía corregir en un plazo razonable. Las organizaciones carecían de visibilidad sobre el contenido de esos productos y no tenían influencia alguna para acelerar la respuesta del proveedor.
Este es el problema de la dependencia de los proveedores en su máxima expresión. Cuando se implementa una aplicación de terceros, se hereda todo su grafo de dependencias, incluidos componentes que no se pueden ver, actualizar ni sustituir. Para los equipos de seguridad, esto significa que la superficie de ataque se extiende más allá del código escrito por sus propios ingenieros, hasta abarcar el código escrito por sus proveedores, y el código escrito por los proveedores de estos, y así sucesivamente.
EL PROBLEMA DE LA VISIBILIDAD, EXPLICADO DE FORMA CLARA
La mayoría de las organizaciones no saben todo lo que se está ejecutando en sus entornos. Saben lo que han implementado, pero no siempre saben qué contenía lo que han implementado. Log4j ha hecho que esta laguna tenga consecuencias de las que es difícil recuperarse.
La lección más amplia: el caso de Log4j no fue un hecho aislado
Sería cómodo considerar Log4j como una anomalía: una catástrofe que ocurre una vez cada década, provocada por una característica inusualmente peligrosa en una biblioteca inusualmente omnipresente. Esta interpretación es precisa en cuanto al grado, pero engañosa en cuanto a la naturaleza. Las condiciones que hicieron que Log4Shell fuera tan perjudicial existen de forma generalizada en el ecosistema de Java y darán lugar a incidentes futuros de carácter similar.
El ecosistema de Java cuenta con un enorme código heredado. Las bibliotecas que se escribieron hace quince años, cuando las prácticas de seguridad eran diferentes y los modelos de amenaza más limitados, siguen funcionando hoy en día en entornos de producción. Algunas son dependencias directas de aplicaciones que no se han modificado en años. Otras son dependencias transitivas de marcos de trabajo que las incorporaron hace mucho tiempo y no han encontrado motivos para eliminarlas.
A diferencia de los ecosistemas de paquetes más modernos, las herramientas de compilación de Java facilitan empaquetar todo en un único artefacto implementable, lo que significa que el código antiguo y vulnerable se transmite junto con el código nuevo, de forma imperceptible, hasta que un escáner o un incidente lo pone de manifiesto. La fortaleza del ecosistema (compatibilidad con versiones anteriores, estabilidad y amplia disponibilidad de bibliotecas) es también su punto débil en materia de seguridad.
No faltan candidatos para el próximo incidente a la escala de Log4j. El clase StringSubstitutor de Apache Commons Text (CVE-2022-42889, revelada en octubre de 2022) suscitó una alarma similar, ya que podía permitir la ejecución remota de código a través de una interpolación de variables insegura, aunque su explotabilidad en el mundo real resultó ser mucho más limitada que la de Log4Shell. El ecosistema más amplio de Apache Commons, diversas bibliotecas de análisis de XML y utilidades relacionadas con JNDI y RMI: este es el tipo de componentes que llevan mucho tiempo en las aplicaciones Java, que reciben menos escrutinio de seguridad que las bibliotecas más recientes y que, con toda plausibilidad, podrían contener el próximo CVE crítico.
Cómo se están adaptando los equipos
La respuesta a la incertidumbre que ha puesto de manifiesto Log4j ha dado lugar a una serie de prácticas que se están convirtiendo en la norma en las organizaciones que se toman en serio el riesgo asociado a las dependencias. Ninguna de ellas resuelve el problema por completo. En conjunto, suponen una reducción significativa de la incertidumbre.
01 Listas de componentes de software (SBOM)
Los equipos están generando SBOM legibles por máquina como parte del proceso de compilación. El uso de herramientas como Syft, CycloneDX o el complemento SBOM de Maven permite crear un registro auditable de todos los componentes de un artefacto de implementación, incluidas las dependencias transitivas. Las SBOM no evitan las vulnerabilidades, pero permiten realizar un inventario. Cuando surja el próximo Log4j, las organizaciones que cuenten con SBOM actualizadas podrán responder a la pregunta «¿nos afecta?» en cuestión de horas, en lugar de días.
02 Análisis continuo de dependencias en CI/CD
Además, están pasando del análisis de vulnerabilidades mediante auditorías periódicas a comprobaciones de integración continua. El uso de herramientas como Grype, OWASP Dependency-Check o Snyk permite pasar de una postura reactiva a una preventiva. Las nuevas vulnerabilidades en las dependencias existentes salen a la luz de inmediato, en lugar de esperar a la siguiente revisión trimestral. El reto es gestionar la «fatiga de alertas»: no todos los CVE señalados son explotables en su contexto, y los resultados indiferenciados de los escáneres acaban ignorándose rápidamente.
03 Supervisión en tiempo de ejecución y detección de comportamientos
El análisis estático detecta vulnerabilidades conocidas en componentes conocidos. No detecta intentos de explotación de vulnerabilidades que aún no se conocían en el momento del análisis. En implementaciones heredadas que aún ejecutan JDK 17 a 23, el Java Security Manager puede ofrecer controles limitados, pero quedó obsoleto y se eliminó en Java 17 y se desactivó de forma permanente en JDK 24, por lo que la protección moderna en tiempo de ejecución se basa ahora en agentes RASP y en la supervisión a nivel de red de patrones sospechosos de búsqueda JNDI: una capa de detección que opera en tiempo de ejecución en lugar de en tiempo de compilación.Esto resulta especialmente valioso para los sistemas heredados en los que resulta difícil implementar a posteriori el análisis estático.
04 Responsabilidad explícita y acuerdos de nivel de servicio (SLA) para la corrección de incidencias
Las ambigüedades en cuanto a la responsabilidad que ralentizaron la respuesta ante el incidente de Log4j en muchas organizaciones no eran problemas técnicos, sino problemas de procesos. Establecer una responsabilidad clara para cada aplicación implementada, incluidos los servicios heredados, y definir acuerdos de nivel de servicio (SLA) explícitos para la corrección de vulnerabilidades críticas (con vías de escalación cuando la responsabilidad sea ambigua) convierte la pregunta «¿quién se encarga de solucionar esto?» de un obstáculo recurrente en un proceso regulado.
05 Cobertura de seguridad ampliada para bibliotecas, más allá del soporte técnico estándar
En el caso de las aplicaciones Java que ejecutan versiones antiguas de bibliotecas que ya no reciben mantenimiento activo, la respuesta habitual es «actualizar». Cuando las actualizaciones no son viables debido a restricciones del proveedor, congelaciones normativas o sistemas heredados frágiles, los equipos necesitan una forma de recibir parches de seguridad sin tener que pasar a una nueva versión principal. Servicios como el Endless Lifecycle Support (ELS) para bibliotecas de TuxCare proporcionan correcciones de seguridad retrocompatibles para las versiones de bibliotecas cubiertas, lo que ayuda a los equipos a mantener una configuración conocida y estable protegida frente a las vulnerabilidades actuales mientras planifican una migración a más largo plazo. Se trata de un puente, no de un destino, pero es una solución significativa cuando la alternativa es seguir utilizando el software sin parches porque aún faltan meses para la actualización.
Aceptar la incertidumbre residual
Hay una versión de esta conversación que termina con una lista de tareas: implementar las SBOM, poner en marcha los análisis, establecer la responsabilidad y gestionar los horarios de asistencia técnica. Si sigues estos pasos, el problema queda resuelto. Esa versión es más sencilla que la realidad.
La realidad es que los sistemas de software complejos contienen una incertidumbre residual que no se puede eliminar por completo, sino solo gestionar. No conseguirás una visibilidad total de todas las dependencias de tu entorno. No podrás aplicar parches a todas las bibliotecas vulnerables antes de que se publique el próximo CVE crítico. El software suministrado por los proveedores seguirá conteniendo componentes que no puedes ver ni controlar.
Lo que puedes hacer es tomar decisiones deliberadas sobre dónde invertir para reducir esa incertidumbre, en lugar de dejar que se acumule de forma imperceptible hasta que un incidente obligue a abordar el tema. Log4j fue, entre otras cosas, un catalizador, un momento en el que el coste del riesgo de las dependencias ocultas se hizo innegable.
Los equipos que salieron reforzados de la respuesta al incidente de Log4Shell no fueron los que aplicaron los parches más rápido. Fueron aquellos que abordaron el incidente como una fuente de información sobre sus propios sistemas: lo que no sabían, dónde presentaban lagunas sus procesos y qué partes de su infraestructura carecían de un responsable claro. Aprovecharon la interrupción para crear algo más duradero que un archivo JAR parcheado.
Esa pregunta debería ser el punto de partida de cualquier revisión de seguridad posterior al incidente de Log4j. La cuestión nunca es solo si se ha aplicado el parche, sino el grado de confianza que se tiene en esa respuesta, y qué medidas se están tomando para subsanar esa vulnerabilidad.
