CVE-2021-44228 Log4Shell: Defensa y Lecciones Vigentes 2026

CVE-2021-44228 Log4Shell se publicó el 9 de diciembre de 2021 y sigue siendo la vulnerabilidad más instructiva de la última década. Un 10.0 en CVSS, explotable escribiendo una cadena de texto en cualquier campo que acabara en un registro, y presente en millones de aplicaciones Java que ni siquiera sabían que lo usaban.

Casi cinco años después seguimos encontrando servidores sin parchear. Y sobre todo: seguimos repitiendo los errores estructurales que la convirtieron en un desastre.

Cómo funcionaba CVE-2021-44228 Log4Shell

CVE-2021-44228 Log4Shell aprovechaba una función de sustitución de expresiones dentro de los mensajes de registro. Si el texto contenía cierto patrón, Log4j lo interpretaba en lugar de limitarse a escribirlo, y una de esas expresiones permitía consultar un directorio remoto por JNDI.

El resultado de CVE-2021-44228 Log4Shell es que bastaba con lograr que la aplicación registrase una cadena controlada por el atacante. Y registrar entradas del usuario es exactamente lo que hace cualquier aplicación: cabeceras HTTP, nombres de usuario en intentos fallidos, campos de búsqueda, nombres de dispositivo. La superficie era prácticamente todo.

A partir de ahí la cadena se completaba sola: la aplicación consultaba el servidor del atacante, este devolvía una referencia a una clase Java, la máquina virtual la descargaba y la ejecutaba. Control total del servidor sin credenciales, sin interacción de nadie y con una petición HTTP normal y corriente.

La cadena de parches de CVE-2021-44228 Log4Shell

Aquí está una de las lecciones más útiles de CVE-2021-44228 Log4Shell, y la que más gente sigue teniendo mal en la cabeza. No hubo un parche, hubo cuatro versiones en tres semanas.

Muchas organizaciones actualizaron a 2.15.0 durante CVE-2021-44228 Log4Shell en el pánico de los primeros días, marcaron la tarea como resuelta y nunca volvieron. Cinco años después, esa decisión sigue viva en algún servidor olvidado.

Es el mismo patrón que analizamos hace unas semanas con el parche incompleto de N-able N-central: la corrección inicial no bloqueaba todas las vías, y quien dio el asunto por cerrado se quedó expuesto. Un CVE marcado como resuelto merece seguimiento, no archivo.

Por qué CVE-2021-44228 Log4Shell fue tan grave

Hay vulnerabilidades con 10.0 en CVSS todos los años y ninguna provoca lo que provocó esta. La diferencia estuvo en la combinación de cuatro factores que rara vez coinciden.

Ese último punto se menciona poco y fue determinante. Equipos enteros pasaron el puente de diciembre parcheando, con las plantillas bajo mínimos y con proveedores que tardaban días en publicar sus propias correcciones. La ventana entre la publicación y la explotación masiva se midió en horas.

Y conviene señalar algo sobre el origen del problema, porque explica bastante del sector: Log4j lo mantenía un puñado de voluntarios sin financiación, sosteniendo una pieza de la que dependían empresas de miles de millones. CVE-2021-44228 Log4Shell fue, además de un fallo técnico, la factura de años de dar por gratis el software libre que sostiene la infraestructura de todos.

De ahí salieron iniciativas de financiación y auditoría de proyectos críticos que siguen activas hoy. Si tu empresa depende de una biblioteca mantenida por dos personas en su tiempo libre, esa es una dependencia de negocio, no un detalle técnico.

Cómo comprobar hoy tu exposición a CVE-2021-44228 Log4Shell

Con CVE-2021-44228 Log4Shell, la pregunta importante no es si actualizaste en su momento, sino si sabes dónde está la biblioteca ahora mismo. Estos comandos localizan copias en el sistema de ficheros, incluidas las empaquetadas dentro de otros artefactos.

# Ficheros sueltos de la biblioteca
find / -name "log4j-core*.jar" 2>/dev/null

# Copias embebidas dentro de otros paquetes
find / -name "*.jar" -o -name "*.war" -o -name "*.ear" 2>/dev/null \
  | while read a; do
      unzip -l "$a" 2>/dev/null | grep -q JndiLookup.class && echo "REVISAR: $a"
    done

Ese segundo comando es el que encuentra los casos difíciles: aplicaciones que empaquetan la biblioteca dentro de su propio archivo y que ningún inventario de paquetes del sistema detecta.

Para un parque de cierto tamaño, hacer esto a mano no escala. Un inventario continuo con una plataforma de seguridad como Wazuh o el escaneo de imágenes de contenedor con Trivy en Kubernetes convierte esa búsqueda en una consulta de treinta segundos.

Mitigaciones de CVE-2021-44228 Log4Shell y cuál era falsa

Durante los primeros días de CVE-2021-44228 Log4Shell circularon varias mitigaciones, y conviene saber cuáles resistieron el escrutinio porque la confusión todavía colea.

• Actualizar a 2.17.1 o superior. Es la solución real y la única definitiva.
• Eliminar la clase JndiLookup del archivo. Mitigación válida cuando no se puede actualizar, y sigue siendo útil hoy para software que ya no recibe mantenimiento.
• La propiedad formatMsgNoLookups. Se recomendó mucho y resultó insuficiente en varios escenarios. Nunca debió considerarse una solución.
• Bloquear con el cortafuegos de aplicación. Filtra intentos evidentes, pero las variantes ofuscadas lo esquivaron desde el primer día.

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Esa tercera línea es la lección incómoda de CVE-2021-44228 Log4Shell: una mitigación repetida por medio sector durante días y que no protegía del todo. Cuando llega el siguiente incidente grande, conviene desconfiar de las soluciones rápidas que circulan las primeras cuarenta y ocho horas.

Qué deberíamos haber aprendido de CVE-2021-44228 Log4Shell

Más allá del fallo técnico, CVE-2021-44228 Log4Shell dejó tres problemas estructurales que siguen sin resolverse en muchas organizaciones.

Nadie sabía qué tenía instalado

La pregunta «¿usamos Log4j?» tardó semanas en responderse en empresas grandes, y la respuesta llegó a base de buscar a mano. De ahí el impulso al inventario de componentes de software, el famoso SBOM. Si hoy no puedes responder en minutos qué bibliotecas hay en producción, el próximo incidente te pillará igual.

Las dependencias transitivas son la mayoría

Casi nadie incluía la biblioteca a propósito: llegaba dentro de un framework, dentro de un servidor de aplicaciones o dentro de un producto comercial. Tu inventario tiene que abarcar lo que instalaste y también lo que instalaron tus dependencias, que es la parte más grande y la que peor se ve.

Salida a Internet sin control

El ataque necesitaba que el servidor pudiese conectarse hacia fuera para descargar el código. Muchos servidores internos, que nunca deberían iniciar conexiones a Internet, podían hacerlo sin restricción. Filtrar el tráfico saliente habría cortado la cadena aunque la biblioteca fuese vulnerable, y sigue siendo una de las medidas más rentables que se pueden aplicar.

Es una defensa que además no depende de conocer el fallo. Frente a CVE-2021-44228 Log4Shell funcionaba sin que nadie supiera que Log4j existía, y funcionará igual con la próxima vulnerabilidad de esta familia, sea cual sea. Esa es la característica que distingue una medida estructural de un parche puntual: protege contra lo que todavía no sabes.

Un ejercicio que merece la pena

Si quieres saber cómo estás hoy, prueba a responder estas cuatro preguntas sin abrir una terminal. Son exactamente las que hubo que contestar en diciembre de 2021, y el tiempo que tardes es una medida bastante honesta de tu madurez operativa.

• ¿Qué aplicaciones Java tienes en producción y quién las mantiene?
• ¿Puedes listar sus dependencias con versión sin conectarte a cada servidor?
• ¿Qué servidores pueden iniciar conexiones salientes a Internet y hacia dónde?
• ¿Cuánto tardarías en desplegar un parche urgente en todos ellos?

Si alguna respuesta es «habría que mirarlo», ahí tienes tu trabajo pendiente. No hace falta esperar al próximo incidente para empezar.

Ese enfoque de cortar la cadena en varios puntos es el que compartimos al analizar el ataque a la cadena de suministro de XZ y el escape de contenedor de runc: no hay una sola barrera que aguante todo, pero varias barreras mediocres bien colocadas evitan bastantes desastres.

Preguntas frecuentes sobre CVE-2021-44228 Log4Shell

Fuentes

• Apache Logging — Página oficial de seguridad de Log4j
• NVD — CVE-2021-44228
• CISA — Guía sobre la vulnerabilidad de Apache Log4j
• Rapid7 — Análisis técnico de Log4Shell

Más avisos y retrospectivas en nuestra sección de vulnerabilidades.

Artículo con finalidad informativa y defensiva; no incluye cadenas ni detalles de explotación.