Incidentes y vulnerabilidades

La puerta trasera de XZ Utils (CVE-2024-3094) — un ataque a la cadena de suministro de un comantenedor de confianza

En 2024 se halló una puerta trasera en xz/liblzma, plantada por un comantenedor de confianza. Cómo se descubrió y qué hacer: fijar versiones y vigilar.

Publicado 2026-06-07 Actualizado 2026-10-23 5 min de lectura
En esta página

Revisitamos un incidente importante del pasado por las lecciones que aún se aplican a tu operación.

2024
descubierto
años
invertidos en construir confianza
confianza
lo que fue el objetivo
justo a tiempo
detectado justo antes de la estable

Qué ocurrió

La librería estaba poco mantenida, sostenida durante mucho tiempo por una sola persona. Otro individuo contribuyó de forma constante, fue construyendo confianza y acabó obteniendo el estatus de comantenedor. Entonces, oculto en actualizaciones corrientes, fue añadiendo paso a paso un mecanismo que permitía el acceso externo no autorizado bajo condiciones específicas.

Lo que se atacó no fue un fallo en el código, sino la suposición de que «la actualización legítima de una persona de confianza» es segura.

① Poco mantenida, una persona sobrecargada sosteniéndola
↓
② Otra persona contribuye de forma constante y se gana la confianza (durante años)
↓
③ Obtiene privilegios de comantenedor
↓
④ Introduce por fases una puerta trasera en actualizaciones corrientes
El ataque avanzó ganándose la confianza poco a poco, no mediante un exploit técnico. Cada paso parecía actividad legítima.

Las personas y la confianza eran el objetivo

Los cortafuegos y los parches no detienen esto. Los mantenedores de OSS funcionan a base de buena voluntad y tiempo voluntario, y los atacantes aprovecharon esa sobrecarga y ese aislamiento. Demostró que la salud de las personas y los proyectos detrás del OSS es en sí misma un asunto de seguridad.

Cómo se encontró: un ingeniero investigó un inicio de sesión lento

Se encontró cuando un ingeniero, en medio de un trabajo no relacionado, notó que un camino de inicio de sesión era «claramente más lento que antes» y que las cifras del benchmark se veían raras, y rastreó la causa en vez de ignorarlo. Como resultado, se detectó antes de que se extendiera ampliamente a las versiones estables, lo que evitó daños a gran escala.

No ignorar la sensación de que «algo va mal» resultó ser el método de detección más eficaz en este caso.

Cronología

  1. años antes

    El atacante contribuye de forma constante, construyendo la confianza de los mantenedores.
  2. principios de 2024

    Se introduce por fases una puerta trasera en actualizaciones legítimas.
  3. 2024-03

    Un ingeniero persigue una anomalía «lenta»; se detecta y divulga justo antes de la estable.

Lecciones que aún se aplican

1

Minimiza las dependencias

Menos librerías significan menos partes en las que confiar. No añadas «porque es cómodo».

2

Fija versiones, vigila los cambios

Los lockfiles atrapan las actualizaciones inesperadas; mira el contenido de los cambios en dependencias importantes (quién, qué).

3

Mejora la reproducibilidad de la compilación

Cuanto más la misma entrada produzca el mismo artefacto, más fácil será detectar una manipulación silenciosa.

4

Nunca ignores una anomalía

«Va lento / raro» es una pista importante; este descubrimiento empezó ahí. Convierte en hábito seguir las pequeñas anomalías hasta su causa.

5

Respeta y apoya a los mantenedores

La salud del OSS del que dependes acaba afectando a tu propia seguridad. Los atacantes pueden aprovechar la sobrecarga y el aislamiento de los mantenedores.

Lee a continuación

Fuentes y alcance

Estas fuentes primarias respaldan los ajustes, el alcance o las medidas anteriores; enlaces comprobados el 23 de octubre de 2026. Revisa sus condiciones de versión y configuración. Las prioridades y lecciones son recomendaciones del sitio, no una revalidación completa ni una garantía de seguridad.

FAQ

Q¿Qué hizo inusual el caso de XZ Utils?
A

Apuntó a las personas y a la confianza, no a un fallo de código. El atacante pasó años convirtiéndose en un mantenedor de OSS de confianza y coló una puerta trasera como si fuera una actualización legítima. Este tipo de ataque es difícil de detener solo con controles técnicos.

Q¿Cómo se descubrió?
A

Un ingeniero, en medio de un trabajo no relacionado, notó que un camino de inicio de sesión era «claramente más lento que antes» y que las cifras del benchmark se veían raras, y rastreó la causa en vez de ignorarlo. Como resultado, se detectó justo antes de extenderse ampliamente a las versiones estables.

Q¿Qué puede hacer un desarrollador indie?
A

Minimizar dependencias, vigilar la procedencia y el contenido de las actualizaciones, fijar versiones para que los cambios inesperados sean detectables, mejorar la reproducibilidad de la compilación y nunca ignorar una sensación de «algo va mal».