El 29 de marzo de 2024 se hizo pública una de las vulnerabilidades más llamativas de los últimos años: la vulnerabilidad XZ, también conocida como XZ Backdoor o backdoor XZ.

La vulnerabilidad crítica fue registrada como CVE-2024-3094 y afectaba a determinadas versiones de XZ Utils, una herramienta muy utilizada en sistemas Linux para comprimir y descomprimir archivos.

Aunque al principio podía parecer “una vulnerabilidad más”, este caso fue especialmente grave porque no se trataba de un fallo accidental. Era una puerta trasera introducida de forma intencionada en un proyecto open source muy utilizado.

Este incidente demostró algo importante: la seguridad del software no depende solo del código que desarrolla una empresa, sino también de las librerías, dependencias y componentes de terceros que utiliza. Por eso, aplicar un enfoque DevSecOps ayuda a integrar controles de seguridad desde el inicio y durante todo el ciclo de vida del desarrollo.

Qué es XZ y para qué sirve

Antes de explicar la vulnerabilidad, conviene responder a una pregunta básica: qué es XZ.

XZ es un formato de compresión de archivos. Dicho de forma sencilla, sirve para reducir el tamaño de archivos y paquetes, algo muy habitual en sistemas Linux y Unix.

Cuando hablamos de XZ Utils, nos referimos al conjunto de herramientas que permite comprimir y descomprimir archivos en formato XZ. Dentro de este paquete también está liblzma, una librería utilizada por otros programas del sistema.

Por eso, aunque muchos usuarios no ejecuten XZ directamente, pueden tenerlo instalado como parte de su sistema operativo o como dependencia de otros componentes.

En resumen:

Concepto	Explicación sencilla
XZ	Formato de compresión de archivos
XZ Utils	Herramientas para comprimir y descomprimir archivos XZ
liblzma	Librería incluida en XZ Utils y usada por otros programas
XZ Backdoor	Puerta trasera maliciosa introducida en XZ Utils
CVE-2024-3094	Identificador oficial de la vulnerabilidad

Qué significa XZ Backdoor

Una backdoor o puerta trasera es un mecanismo oculto que permite acceder a un sistema sin seguir el proceso normal de autenticación.

En este caso, la XZ Backdoor podía afectar al proceso de conexión por SSH en determinados sistemas Linux. SSH es el protocolo que se utiliza para acceder de forma remota y segura a servidores.

El riesgo era muy alto porque, si se cumplían ciertas condiciones, un atacante podía llegar a ejecutar código malicioso antes de que el usuario se autenticara correctamente.

Por eso la vulnerabilidad fue considerada crítica.

Qué versiones estaban afectadas

La vulnerabilidad afectaba principalmente a las versiones:

• XZ Utils 5.6.0
• XZ Utils 5.6.1

Estas versiones incluían código malicioso que no estaba presente de forma evidente en el repositorio principal, sino en los paquetes preparados para distribución.

Esto hizo que el caso fuera especialmente complejo, porque el código malicioso estaba oculto y diseñado para pasar desapercibido.

La recomendación general fue revisar los sistemas Linux y comprobar si utilizaban alguna de estas versiones. En caso afirmativo, era necesario actualizar, eliminar o bajar de versión el paquete siguiendo las indicaciones de cada distribución.

Quién era JiaT75 y qué papel tuvo

Una de las búsquedas más frecuentes sobre este caso es JiaT75.

JiaT75 era el nombre de usuario asociado a la persona que fue ganando confianza dentro del proyecto XZ Utils durante un largo periodo de tiempo.

Según la información conocida, este usuario comenzó realizando aportaciones aparentemente legítimas al proyecto. Poco a poco fue ganando presencia, permisos y confianza dentro de la comunidad.

Este punto es clave para entender el caso: el ataque no consistió simplemente en subir código malicioso de golpe. Fue un proceso lento, preparado y basado en la confianza.

El atacante aprovechó la dinámica habitual de muchos proyectos open source:

• Pocos mantenedores.
• Mucha carga de trabajo.
• Confianza en contribuidores activos.
• Revisiones limitadas.
• Dependencia de procesos manuales.
• Falta de controles automatizados suficientes.

Por eso, el caso XZ no solo es una historia sobre malware. Es también una lección sobre la seguridad en la cadena de suministro del software.

Cómo se introdujo la vulnerabilidad XZ

El ataque fue especialmente sofisticado porque no se limitó a modificar una línea de código visible.

El proceso se desarrolló durante varios años. De forma simplificada, ocurrió así:

1. Un usuario comenzó a colaborar en el proyecto.
2. Fue ganando confianza con contribuciones aparentemente normales.
3. Se introdujeron cambios técnicos que preparaban el terreno.
4. Se modificaron elementos relacionados con pruebas y compilación.
5. Se añadieron archivos que parecían legítimos.
6. El código malicioso quedó incluido en las versiones vulnerables.
7. Las versiones afectadas empezaron a llegar a algunas distribuciones Linux.

El objetivo era que la puerta trasera se activara en condiciones concretas, especialmente en sistemas que usaran SSH junto con la librería afectada.

Lo más preocupante es que el ataque no se descubrió por un control automático, sino por la curiosidad de un desarrollador que notó un comportamiento extraño.

Cómo se descubrió el backdoor XZ

El descubrimiento se produjo gracias a Andres Freund, un desarrollador que detectó algo inusual mientras investigaba problemas de rendimiento.

Al revisar el comportamiento de SSH en su sistema, observó que el proceso consumía más recursos de lo esperado y que las conexiones tardaban más de lo normal.

Ese pequeño retraso fue suficiente para que empezara a investigar.

Tras analizar el problema, descubrió que había código malicioso en XZ Utils. Gracias a esa investigación, la comunidad pudo reaccionar antes de que la vulnerabilidad llegara de forma masiva a entornos de producción.

Este detalle es importante: la vulnerabilidad XZ pudo haber tenido un impacto mucho mayor si no se hubiera detectado a tiempo.

Por qué fue tan grave la vulnerabilidad XZ

La gravedad de la vulnerabilidad XZ se entiende mejor si tenemos en cuenta tres factores.

1. XZ Utils está muy extendido

XZ Utils es un componente utilizado en muchas distribuciones Linux. Aunque no siempre sea visible para el usuario, puede estar instalado como parte del sistema o como dependencia de otros paquetes.

2. El ataque afectaba a la cadena de suministro

No era un ataque contra una empresa concreta. Era un ataque contra un componente open source que podía acabar integrado en muchos sistemas distintos.

Este tipo de amenaza se conoce como ataque a la cadena de suministro de software.

3. El objetivo era pasar desapercibido

El código malicioso estaba ofuscado y preparado para no ser evidente en una revisión rápida. Además, el atacante había construido una reputación previa dentro del proyecto.

Por eso, este caso se considera uno de los ejemplos más importantes de los últimos años sobre riesgos en componentes de terceros.

Qué podían hacer las empresas para protegerse

Tras conocerse la vulnerabilidad, las empresas debían revisar sus sistemas y comprobar si estaban usando versiones afectadas de XZ Utils.

Las acciones recomendadas eran:

• Revisar si existía XZ Utils 5.6.0 o 5.6.1 en los sistemas.
• Actualizar siguiendo las recomendaciones de la distribución Linux.
• Bajar de versión si no existía actualización segura.
• Revisar servidores con SSH expuesto.
• Comprobar imágenes Docker y contenedores que pudieran incluir el paquete vulnerable.
• Analizar dependencias de terceros.
• Revisar pipelines de construcción y despliegue.
• Mejorar la monitorización de componentes open source.

Este último punto es importante. Una empresa puede tener sistemas actualizados, pero seguir usando una imagen, paquete o contenedor que incluya una versión vulnerable.

Por eso es recomendable contar con un servicio de gestión de vulnerabilidades que permita identificar qué activos están afectados, priorizar los riesgos y corregirlos de forma ordenada.

Qué enseña este caso sobre el ciclo de vida del software

La vulnerabilidad XZ demuestra que la seguridad debe estar presente durante todo el ciclo de vida del software.

No basta con revisar una aplicación justo antes de pasarla a producción. También hay que controlar:

• Qué dependencias se utilizan.
• Quién mantiene esas dependencias.
• Qué versiones se instalan.
• Cómo se revisan los cambios.
• Qué controles existen en integración continua.
• Cómo se analizan las vulnerabilidades.
• Cómo se gestionan los componentes open source.
• Cómo se responde ante una alerta crítica.

Para conseguirlo, es importante implantar un modelo SSDLC que incorpore la seguridad en cada fase del desarrollo: diseño, codificación, revisión, pruebas, despliegue y mantenimiento.

Este caso también demuestra que los proyectos open source, aunque sean esenciales, pueden depender de muy pocas personas. Si esos proyectos no reciben suficiente apoyo, revisión y supervisión, pueden convertirse en un punto débil para miles de organizaciones.

La importancia de DevSecOps ante casos como XZ Backdoor

Un enfoque DevSecOps ayuda a reducir el riesgo de este tipo de incidentes porque integra controles de seguridad desde el inicio del desarrollo.

Esto incluye:

• Análisis automático de dependencias.
• Revisión de vulnerabilidades conocidas.
• Control de versiones de paquetes.
• Análisis de imágenes Docker.
• Detección de secretos.
• Revisión de código.
• Validación de componentes open source.
• Bloqueo de builds inseguros.
• Monitorización continua.

El objetivo no es frenar el desarrollo, sino detectar problemas antes de que lleguen a producción.

En un caso como XZ Backdoor, una estrategia DevSecOps bien implantada puede ayudar a identificar rápidamente qué equipos, aplicaciones, contenedores o servidores están usando una versión afectada.

Además, integrar controles de seguridad en procesos de integración continua permite detectar dependencias vulnerables, builds inseguros o componentes no aprobados antes de que lleguen a producción.

Por qué revisar componentes de terceros es fundamental

Hoy en día, la mayoría de aplicaciones no se construyen desde cero. Utilizan frameworks, librerías, paquetes, imágenes, módulos y herramientas open source.

Esto permite desarrollar más rápido, pero también introduce dependencias externas que deben controlarse.

Una vulnerabilidad en un componente pequeño puede afectar a una aplicación completa.

Por eso, las empresas necesitan tener visibilidad sobre:

• Qué componentes usan.
• Qué versiones están instaladas.
• Qué vulnerabilidades tienen.
• Qué aplicaciones dependen de ellos.
• Qué sistemas están expuestos.
• Qué prioridad tiene cada corrección.

Sin esta visibilidad, responder ante una vulnerabilidad crítica puede convertirse en un proceso lento y desordenado.

El papel de los equipos en la seguridad del software

La seguridad no depende solo de herramientas. También depende de las personas y de cómo trabajan los equipos.

En casos como XZ Backdoor, es importante que los equipos de desarrollo, operaciones y seguridad tengan criterios claros para revisar dependencias, interpretar alertas y actuar ante vulnerabilidades críticas.

Un programa de Security Champions puede ayudar a crear referentes de seguridad dentro de los equipos técnicos. Estos perfiles facilitan la comunicación con ciberseguridad, promueven buenas prácticas y ayudan a detectar riesgos antes de que lleguen a producción.

Buenas prácticas para reducir riesgos similares

A partir del caso XZ, estas son algunas buenas prácticas recomendadas:

Buena práctica	Por qué ayuda
Inventariar dependencias	Permite saber qué componentes usa cada aplicación
Analizar vulnerabilidades	Ayuda a detectar versiones afectadas
Revisar imágenes Docker	Evita desplegar contenedores con paquetes vulnerables
Automatizar controles en CI/CD	Detecta problemas antes de producción
Evitar dependencias innecesarias	Reduce la superficie de ataque
Revisar cambios críticos	Mejora el control sobre código sensible
Usar versiones controladas	Evita actualizaciones inesperadas
Monitorizar alertas de seguridad	Permite reaccionar antes
Aplicar DevSecOps	Integra seguridad en todo el proceso
Formar a los equipos	Mejora la detección temprana de riesgos

Conclusión

La vulnerabilidad XZ Backdoor no fue una vulnerabilidad cualquiera. Fue un ataque sofisticado contra la cadena de suministro del software, basado en la confianza, la paciencia y la falta de controles suficientes.

El caso demostró que incluso componentes muy utilizados y aparentemente fiables pueden convertirse en un riesgo si no existen medidas de seguridad adecuadas.

Para las empresas, la principal lección es clara: la seguridad debe formar parte de todo el ciclo de vida del software. Esto incluye controlar dependencias, revisar componentes open source, analizar vulnerabilidades, automatizar controles y tener capacidad de respuesta rápida ante incidentes críticos.

En Ciberso ayudamos a las organizaciones a reforzar la seguridad de sus aplicaciones, dependencias, contenedores y procesos de desarrollo mediante un enfoque DevSecOps. Nuestro objetivo es detectar riesgos antes de que lleguen a producción y reducir el impacto de vulnerabilidades como XZ Backdoor.