Log4j: El mayor incidente de seguridad informática de la década

La vulnerabilidad Log4Shell sacudió el mundo de la TI en diciembre de 2021. Con una puntuación CVSS de 10,0, afecta a millones de aplicaciones en todo el mundo – y muchas siguen sin parchear hasta hoy.

En resumen

La vulnerabilidad Log4Shell (CVE-2021-44228) en la biblioteca Java Log4j sacudió el mundo de la TI en diciembre de 2021. Con una puntuación CVSS de 10,0, afecta a millones de aplicaciones en todo el mundo. Esta brecha permite la ejecución remota de código sin autenticación – una pesadilla para cualquier equipo de seguridad.

El 9 de diciembre de 2021, la Apache Software Foundation publicó una actualización de emergencia para Log4j, una de las bibliotecas de registro más extendidas del ecosistema Java. Lo que siguió fue el mayor evento coordinado de aplicación de parches en la historia de la ciberseguridad.

Por qué Log4Shell es tan peligrosa

Log4j está integrada prácticamente en todas las aplicaciones Java – desde Apache Struts y Elasticsearch hasta servidores de Minecraft. La vulnerabilidad permite a los atacantes ejecutar código arbitrario en el sistema objetivo mediante una cadena de caracteres manipulada dentro de una entrada de registro. Para ello basta una única solicitud HTTP.

El BSI (Oficina Federal de Seguridad Informática de Alemania) clasificó el nivel de amenaza como «Rojo» – el nivel de advertencia más alto. En un plazo de 72 horas tras su divulgación, los investigadores de seguridad ya habían registrado millones de intentos de ataque. Mineros de criptomonedas, grupos de ransomware y actores estatales explotaron inmediatamente esta vulnerabilidad.

El reto: inventariar el software

El verdadero problema para muchas empresas fue que no sabían dónde se utilizaba Log4j. La biblioteca suele incluirse como dependencia transitiva – profundamente anidada en software de terceros, dispositivos especializados (appliances) y servicios en la nube.

Quien no mantenía un documento actualizado de la lista de materiales de software (Software Bill of Materials, SBOM), se enfrentaba a una tarea hercúlea. Algunas organizaciones necesitaron semanas para identificar todos los sistemas afectados.

Lecciones para el futuro

Log4Shell ha puesto de manifiesto tres debilidades estructurales:

Gestión de dependencias: los componentes de código abierto deben inventariarse y supervisarse continuamente
Velocidad de parcheo: quien no pueda aplicar parches en cuestión de horas, actúa demasiado lentamente
Defensa en profundidad: reglas de WAF, segmentación de red y filtrado de tráfico saliente (egress filtering) habrían bloqueado muchos ataques

Hechos clave

CVE-2021-44228 con CVSS 10,0 – máxima criticidad

Afectadas: millones de aplicaciones Java en todo el mundo

Primeros parches publicados por Apache en un plazo de 48 horas

Nivel de advertencia «Rojo» del BSI, por primera vez aplicado a una vulnerabilidad de software

La obligatoriedad de elaborar un SBOM vendrá impuesta por el Reglamento Europeo sobre Resistencia Cibernética (Cyber Resilience Act)

Dato: según Munich Re, las primas de los seguros cibernéticos aumentaron en 2024 un 15 % de media.

Dato: según Bitkom, las empresas alemanas invierten de media el 14 % de su presupuesto de TI en ciberseguridad.

Preguntas frecuentes

¿Sigue siendo relevante Log4Shell en 2025?

Sí. Muchos sistemas siguen sin parchear hasta hoy, especialmente dispositivos embebidos y software heredado (legacy). Los atacantes siguen escaneando activamente en busca de instancias vulnerables.

¿Cómo puedo comprobar si mis sistemas están afectados?

Herramientas como Syft o Grype generan un SBOM e identifican versiones vulnerables de Log4j. Alternativamente, escáneres especializados como Lunasec o el detector Log4Shell de CERT/CC también resultan útiles.

Sobre el autor: Tobias Massow

Más artículos de Tobias Massow

También disponible en

Français English Deutsch