El Pipeline Como Línea de Defensa: Lo Que Enseñan los Casos OVHcloud y LiteLLM

Entre el 19 y el 21 de octubre de 2026, dos herramientas usadas a diario en pipelines de construcción y despliegue fueron sustituidas por versiones que roban credenciales. Una era la interfaz de línea de comandos de un proveedor europeo de cloud. La otra, una biblioteca de código abierto con más de 20 millones de descargas por semana, según Datadog Security Labs.

Ninguno de los dos casos empezó con un fallo en el pipeline de quienes usaban esas herramientas. Pero en ambos, el pipeline de quien las consumía era el lugar adecuado para frenar la entrada.

19 de octubre: la interfaz de línea de comandos de OVHcloud

Durante 94 minutos, de 14:47 a 16:21 (hora de París), los binarios oficiales de ovhcloud-cli publicados en GitHub, versiones 0.11.0 a 0.15.0, fueron sustituidos por versiones alteradas, preparadas para recoger secretos guardados en el disco. Según IT-Connect, el fichero de sumas de verificación también fue reescrito: quien comparara la descarga con el valor publicado en la propia página de la versión obtenía una coincidencia perfecta.

El fundador de OVHcloud, Octave Klaba, explicó la causa públicamente: la opción de inmutabilidad de las versiones en GitHub estaba desactivada, lo que permitió a una cuenta con privilegios suficientes modificar versiones ya publicadas sin pasar por el pipeline de construcción. El pipeline de la propia OVHcloud no fue comprometido. La opción se activó y la versión 0.16.0 salió firmada e inmutable.

El detalle más útil está en la detección. Según IT-Connect, quien dio la alerta fue el pipeline de integración continua de un cliente, que tenía registrada la huella SHA-256 del fichero. La huella cambió sin aviso, la construcción falló y el cliente abrió una incidencia pública en el repositorio.

21 de octubre: el flujo de publicación de LiteLLM

Dos días después, la versión 1.107.0 de LiteLLM se publicó en PyPI y en imágenes Docker con código que recoge credenciales y abre la puerta a la ejecución remota. El informe oficial del proyecto describe una secuencia que atravesó varias barreras.

La protección de ramas de GitHub rechazó el primer intento de modificar el flujo privado de publicación. Una credencial de una cuenta de desarrollador con privilegios se impuso a esa protección y aplicó el cambio. El flujo modificado pasó a construir desde un repositorio con un nombre casi idéntico al oficial. La aprobación de producción se satisfizo con la credencial de una segunda cuenta. Y una tercera cuenta borró los registros de las ejecuciones.

La versión estuvo disponible unas dos horas antes de retirarse. La etiqueta de código oficial en GitHub no contenía los ficheros maliciosos. Las imágenes comprometidas, según el propio informe, tenían una firma válida, hecha con la clave anterior del proyecto. El informe advierte que partes del análisis siguen en revisión.

El proyecto ya había reforzado el proceso tras un incidente en marzo: publicación desde un repositorio privado, publicadores de confianza, etiquetas Docker inmutables e imágenes firmadas. Como resume el informe, el atacante tuvo que comprometer varios controles independientes para tener éxito.

Lo que tienen en común los dos casos

Tres puntos atraviesan ambos incidentes.

1. La prueba venía del mismo lugar que el artefacto. En OVHcloud, la suma de verificación se reescribió con el binario. En LiteLLM, la firma era válida. Verificar contra una prueba publicada por el mismo canal que fue comprometido no prueba nada.
2. La defensa que funcionó estaba del lado de quien consume. Un pipeline que fija versiones y huellas frena el cambio silencioso, porque compara con un valor registrado antes del ataque.
3. Las credenciales con poder sobre la publicación fueron la puerta de entrada. En ambos casos, cuentas legítimas hicieron lo que el pipeline de construcción existía para controlar.

La escala del problema

La automatización que se ejecuta en los pipelines ha crecido más deprisa que la atención que recibe. Según el Octoverse 2026 de GitHub, se ejecutaron 45.000 millones de trabajos de GitHub Actions en los doce meses hasta septiembre de 2026, frente a 14.000 millones en el periodo anterior.

Cada trabajo que descarga una herramienta, una imagen o una biblioteca es una entrada. La pregunta deja de ser si el pipeline es rápido. Pasa a ser qué acepta sin preguntar.

Cuatro prácticas que no exigen herramientas nuevas

1. Fijar versiones y huellas. Herramientas de construcción, imágenes base y dependencias entran en el pipeline con versión exacta y suma de verificación registrada en el propio repositorio. Un cambio silencioso pasa a romper la construcción, como le ocurrió al cliente de OVHcloud.
2. Verificar en el origen, no en la misma página. Preferir versiones inmutables y atestaciones de procedencia verificadas con la herramienta del proveedor, en lugar de la suma de verificación publicada junto al fichero.
3. Separar quién modifica el flujo de quién aprueba producción. Los cambios en el propio flujo de publicación deben pasar por revisión, y la aprobación de producción no debe depender de una sola cuenta. Registros de ejecución protegidos contra el borrado.
4. Inventariar las credenciales del pipeline. Saber qué secretos usa cada flujo, con qué permisos, quién puede leerlos y cuándo se rotan. En el caso de OVHcloud, la recomendación a los afectados fue cambiar todos los secretos del disco: es más fácil cuando se sabe cuáles son.

Ninguna de las cuatro elimina el riesgo. Juntas, reducen la ventana en la que una herramienta alterada puede entrar sin que nadie lo note.

Conclusión

Los dos incidentes duraron horas, no días, y aun así tuvieron alcance global, porque estas herramientas entran automáticamente en miles de pipelines. En ambos, el proveedor reaccionó deprisa y explicó públicamente lo ocurrido. La lección para quien consume es otra: el pipeline no es solo el camino por el que el código sale a producción. Es también el primer lugar donde se puede verificar lo que entra.

Cuándo tiene sentido reforzar el equipo interno se explica en DevOps as a Service, cuándo tiene sentido, y el camino hasta producción se trató en configurar un pipeline de CI/CD en dos horas. Para revisar lo que el pipeline acepta hoy sin verificar, es posible reservar una Sesión de Orientación, sin compromiso.