Un equipo de desarrollo instala un paquete desde el registro oficial. El paquete tiene el nombre, la versión y el publicador esperados. Llegó a través del proceso de publicación habitual del proyecto, con una procedencia que identifica cómo se compiló.
Son señales de confianza significativas. Pero no pueden demostrar que nadie con autoridad sobre la publicación haya cambiado el código que se compilaba.
El 21 de octubre de 2026, el proceso de publicación habitual de LiteLLM distribuyó la versión maliciosa 1.107.0 a PyPI y a sus registros oficiales de contenedores. La investigación posterior de LiteLLM describió cómo un atacante obtuvo credenciales de GitHub con amplios privilegios, modificó un flujo de trabajo privado de publicación y lo dirigió a compilar código desde un repositorio de imitación. Investigadores independientes examinaron el paquete malicioso y encontraron mecanismos para recopilar credenciales al iniciarse Python. (investigación del incidente de LiteLLM, análisis de la carga maliciosa de Microsoft y análisis independiente de Datadog)
El incidente deja una lección práctica para los desarrolladores que usan gateways de IA y otro software de terceros. Comprobar de dónde procede un paquete es importante. No es lo mismo que saber que el código que contiene es fiable.
La versión parecía legítima porque el proceso era legítimo
LiteLLM ofrece software que las aplicaciones pueden usar para conectarse a distintos proveedores de modelos de lenguaje. En esa posición, puede gestionar claves de API y otra configuración importante. También se instala en entornos de desarrollo y en compilaciones automatizadas.
Según la investigación de LiteLLM del 23 de octubre, el ataque empezó mucho antes de que apareciera la versión maliciosa. En mayo, una clave administrativa de una Agent Platform interna y experimental se subió (commit) a un repositorio público. El archivo se eliminó al cabo de varias horas, pero la clave siguió siendo válida. LiteLLM informó de que un atacante la usó el 10 de octubre para acceder a la Agent Platform y obtener un token OAuth de GitHub CLI asociado a un propietario de la organización. (investigación publicada por LiteLLM)
Este detalle importa porque un secreto filtrado no es necesariamente inofensivo después de borrar su archivo. Si el secreto sigue siendo válido, el sistema que lo acepta todavía puede conceder acceso. El alcance de ese acceso determina hasta dónde puede extenderse una vulneración.
LiteLLM informó de que el atacante usó el token con nivel de propietario para ejecutar flujos de trabajo que expusieron más secretos. El 21 de octubre, el atacante modificó un flujo de trabajo privado de publicación para que aceptara como parámetro el propietario del repositorio de origen. Una regla normal de protección de ramas rechazó un primer push. Aun así, la credencial de propietario de la organización permitió que el cambio se aplicara. (investigación publicada por LiteLLM)
A continuación, el flujo de trabajo alterado compiló desde Berri-AI/litellm, un repositorio de imitación, en lugar del origen legítimo BerriAI/litellm. Según LiteLLM, el token robado de un segundo mantenedor aprobó el punto de control de publicación en producción, mientras que la credencial de propietario de la organización ejecutó el lanzamiento en staging (staging dispatch). Los artefactos resultantes llegaron a los canales de distribución oficiales a través de la infraestructura de publicación esperada. (investigación de LiteLLM y análisis de Datadog)
Clave filtrada
En mayo, una clave administrativa de una Agent Platform interna y experimental se subió a un repositorio público. Según LiteLLM, el archivo se eliminó al cabo de varias horas, pero la clave siguió siendo válida.
Token robado
LiteLLM informó de que un atacante usó esa clave el 10 de octubre para acceder a la Agent Platform y obtener un token OAuth de GitHub CLI asociado a un propietario de la organización.
Flujo modificado
LiteLLM informó de que el atacante usó el token con nivel de propietario para ejecutar flujos de trabajo que expusieron más secretos. El 21 de octubre, el atacante modificó un flujo de trabajo privado de publicación para que aceptara como parámetro el propietario del repositorio de origen. La protección de ramas rechazó un primer push, pero la credencial de propietario de la organización permitió que el cambio se aplicara.
Imitación compilada
El flujo de trabajo alterado compiló desde Berri-AI/litellm, un repositorio de imitación, en lugar del origen legítimo BerriAI/litellm. Según LiteLLM, el token robado de un segundo mantenedor aprobó el punto de control de publicación en producción, mientras que la credencial de propietario de la organización ejecutó el lanzamiento en staging.
Versión instalada
Los artefactos llegaron a los canales de distribución oficiales a través de la infraestructura de publicación esperada. Datadog informó de que llevaban una procedencia de compilación aparentemente legítima que identificaba con exactitud la bifurcación (fork) maliciosa como su origen. Instalar el paquete podía bastar, porque Python puede ejecutar archivos de arranque al iniciarse.
La investigación independiente de Microsoft sobre la carga maliciosa respalda el relato de una publicación comprometida, pero indica de forma explícita que no determinó por su cuenta cómo se produjeron el acceso inicial al origen (upstream) y el robo de credenciales. Por tanto, esa parte de la secuencia debe entenderse como un hallazgo forense comunicado por LiteLLM. (Microsoft Security Research)
Según la cronología de LiteLLM, la versión maliciosa se publicó hacia las 11:39 UTC del 21 de octubre. Un issue público informó de un problema hacia las 12:06, PyPI puso la versión en cuarentena hacia las 13:23 y los registros de contenedores hicieron lo mismo hacia las 13:51, un intervalo que LiteLLM describe como de unas dos horas. Datadog sitúa la cuarentena de PyPI hacia las 13:20 y la retirada de las imágenes de contenedor hacia las 13:53, también unas dos horas, y no da ninguna hora de detección. Las dos versiones difieren en minutos, no en el panorama general. (investigación publicada por LiteLLM y análisis de Datadog)
Una vía de publicación de confianza no garantiza un código fuente de confianza
Conviene separar tres preguntas.
La autenticidad pregunta si un artefacto procede del publicador esperado. La procedencia describe el proceso y el origen registrado que lo produjeron. La fiabilidad del código pregunta si el software resultante es seguro de ejecutar.
Autenticidad: ¿procede del publicador esperado?
La autenticidad pregunta si un artefacto procede del publicador esperado.
En el incidente de LiteLLM, la versión maliciosa salió del proceso de publicación habitual del proyecto, hacia PyPI y sus registros oficiales de contenedores.
Procedencia: ¿qué proceso y qué origen lo compilaron?
La procedencia describe el proceso y el origen registrado que produjeron un artefacto. Un registro de procedencia puede identificar el flujo de trabajo y el repositorio de origen, sin decidir si ese origen estaba autorizado o era seguro.
Datadog informó de que los artefactos publicados llevaban una procedencia de compilación aparentemente legítima que identificaba con exactitud la bifurcación (fork) maliciosa como su origen.
Fiabilidad del código: ¿es seguro ejecutar el código?
La fiabilidad del código pregunta si el software resultante es seguro de ejecutar.
Estas propiedades están relacionadas, pero no son intercambiables. La versión maliciosa aprovechaba el comportamiento de arranque de Python, así que instalarla podía bastar para ejecutar la carga maliciosa.
Estas propiedades están relacionadas, pero no son intercambiables.
Un registro de compilación o una atestación de procedencia puede identificar el flujo de trabajo y el repositorio de origen usados para crear un artefacto, sin decidir si ese origen estaba autorizado o era seguro. En el incidente de LiteLLM, el atacante influyó en qué origen compilaba el flujo de trabajo legítimo. Datadog informó de que los artefactos publicados llevaban una procedencia de compilación aparentemente legítima que identificaba con exactitud la bifurcación (fork) maliciosa como su origen. (Datadog Security Labs)
Esto no es motivo para abandonar la firma, la verificación de procedencia ni Trusted Publishing. Estos controles pueden ayudar a verificar el origen de un artefacto o a reducir la dependencia de credenciales de publicador de larga duración. Por sí solos, no determinan si una identidad de publicador con privilegios fue comprometida ni si la compilación seleccionó el origen previsto. El seguimiento de LiteLLM del 30 de octubre informa de que su propio pipeline firmó los artefactos y de que estos llevaban una procedencia válida de Trusted Publishing. (seguimiento de LiteLLM)
Para un equipo de desarrollo, esta distinción cambia la forma de evaluar una dependencia. La confianza no termina en el registro de paquetes. También depende de las identidades de los publicadores, los repositorios de origen aprobados, los permisos de compilación y el entorno donde se ejecuta el paquete.
Por qué instalar este paquete podía bastar
La versión maliciosa de LiteLLM no dependía de que un desarrollador hiciera la pregunta equivocada a un modelo de IA. Aprovechaba el comportamiento normal de arranque de Python.
Microsoft y Datadog encontraron tres archivos maliciosos distribuidos en el wheel afectado: cook.pth, cook.py y sitecustomize.py. Python puede procesar ciertas instrucciones .pth y cargar sitecustomize durante la inicialización del intérprete. En un entorno afectado, iniciar Python podía activar código malicioso aunque la aplicación nunca importara LiteLLM. (análisis de Microsoft y análisis de Datadog)
Eso amplió la posible exposición más allá de los sistemas que usaban LiteLLM activamente como gateway. Una computadora portátil de desarrollo, un contenedor de pruebas o un agente de compilación podían ejecutar Python para una tarea sin relación después de instalarse el paquete comprometido.
La carga maliciosa recuperada apuntaba a las credenciales de nube accesibles, a credenciales de desarrollo y de control de código fuente, a claves de proveedores de IA, a datos del navegador, a material SSH y a algunos registros de la base de datos de LiteLLM. También incluía un mecanismo que podía descargar código adicional. Los investigadores no observaron la entrega de una segunda fase, aunque Microsoft señaló que el cargador podía volver a activarse. (análisis de Microsoft y análisis de Datadog)
Que una credencial sea un objetivo no demuestra que el atacante la obtuviera. El impacto en un entorno concreto depende de qué archivos e identidades eran accesibles, de si la carga maliciosa se ejecutó durante el tiempo suficiente, de si la transmisión tuvo éxito y de si las credenciales seguían siendo válidas.
Esa distinción debe orientar tanto la información sobre seguridad como la respuesta a incidentes. La versión afectada era peligrosa. De ello no se deduce que cada descarga causara una brecha confirmada.
Por qué eliminar el paquete puede no restablecer la confianza
Los archivos de arranque maliciosos podían instalarse fuera del directorio habitual de la aplicación LiteLLM. Eliminar solo ese directorio podía dejar el entorno de Python en condiciones de volver a ejecutar la carga maliciosa. Tanto Microsoft como Datadog advirtieron de que la eliminación normal del paquete no debe tratarse como una recuperación completa. (análisis de Microsoft y análisis de Datadog)
También hay una trampa práctica en la investigación. Ejecutar el Python o el pip del entorno afectado para inspeccionarlo puede activar el mismo comportamiento de arranque. Los equipos que investiguen una máquina posiblemente comprometida deben usar herramientas limpias y un flujo de trabajo aislado en lugar de ejecutar el entorno sospechoso.
En las organizaciones que puedan haber instalado la versión 1.107.0, la respuesta debe guiarse por los avisos oficiales y por su propio equipo de seguridad. Identifica los hosts, estaciones de trabajo, contenedores y entornos de compilación afectados. Aísla o reconstruye los entornos sospechosos, investiga una posible ejecución y la actividad saliente, y rota desde un entorno limpio las credenciales a las que pudiera acceder el proceso comprometido. Revisa los registros de auditoría pertinentes en busca de un uso indebido posterior. (análisis de Microsoft y análisis de Datadog)
Reconstruir y revisar credenciales puede suponer más trabajo que eliminar un paquete. Ese trabajo aborda el riesgo real, que no se limita a que LiteLLM siga presente.
Qué cambia este incidente para los desarrolladores
La lección inmediata es concretar más la confianza en las dependencias.
Para los equipos que consumen paquetes, fijar versiones y controlar las actualizaciones de dependencias reduce la exposición imprevista. Eso no hace segura una versión maliciosa fijada. El análisis de paquetes y las comprobaciones de procedencia aportan evidencias útiles, pero el equipo sigue necesitando una forma de identificar rápidamente los despliegues afectados, reconstruir los entornos y rotar las credenciales a las que esos entornos pueden llegar.
Para los equipos que publican software, la selección del origen debe restringirse con independencia de la autoridad para ejecutar una publicación. Los flujos de trabajo de publicación no deberían poder compilar desde repositorios de imitación arbitrarios solo porque una cuenta con privilegios proporcione un parámetro de entrada. Las credenciales de publicador, las cuentas con nivel de propietario y los secretos de CI deben tener el alcance y la duración mínimos necesarios. Cuando se descubre una clave filtrada, retirarla del control de código fuente debe ir seguido de su revocación y de una evaluación de la exposición.
Para los equipos de plataforma y de seguridad, la pregunta más importante suele ser hasta dónde puede llegar una dependencia comprometida. Un gateway de IA puede estar junto a claves de proveedores, credenciales de cargas de trabajo en la nube y acceso a bases de datos. Esos permisos deben acotarse para que la vulneración de un proceso no exponga automáticamente el resto de la infraestructura de una organización.
Ninguno de estos pasos garantiza la inmunidad. Juntos reducen la posibilidad de que una sola versión comprometida se convierta en un incidente mayor de identidad e infraestructura.
En qué se diferencia de un ataque a un servidor de IA en ejecución
La cobertura de PoeLLM (en inglés) que TechiesJournal publicó por separado analiza a atacantes que explotan servicios de IA y de desarrollo vulnerables, incluido un fallo de autorización de MCP en LiteLLM. Se trata de un problema de exposición en tiempo de ejecución: un atacante llega a software ya desplegado.
El incidente del 21 de octubre cruzó un límite distinto. El código malicioso llegó a través del propio proceso de entrega de software. Un equipo podía instalar la versión comprometida desde una fuente oficial sin haber expuesto antes un endpoint público vulnerable.
La distinción importa a la hora de decidir qué inspeccionar. El refuerzo (hardening) en tiempo de ejecución y la aplicación de parches abordan las debilidades de los servicios expuestos. La procedencia de las dependencias, las restricciones de origen, la identidad del publicador, el aislamiento de credenciales y la preparación para la recuperación abordan otras partes del riesgo de la cadena de suministro de software. Las organizaciones necesitan ambas cosas.
| Pregunta | Ataque a un servidor de IA en ejecución | Versión comprometida |
|---|---|---|
| Cómo llega el código malicioso | Un atacante llega a software que ya está desplegado. | Llega a través del propio proceso de entrega de software. |
| Qué podría hacer un equipo para quedar expuesto | Ejecutar un endpoint público vulnerable. | Instalar la versión comprometida desde una fuente oficial. |
| Qué inspeccionar | Refuerzo en tiempo de ejecución y parches. | Procedencia de las dependencias, restricciones de origen, identidad del publicador, aislamiento de credenciales y preparación para la recuperación. |
Lo que una versión fiable puede decirte y lo que no
Un proceso de publicación legítimo es valioso, y el incidente de octubre no cambia eso. Demuestra que un proceso de publicación hereda la seguridad de las identidades y los orígenes en los que confía.
Los desarrolladores deben seguir usando canales oficiales, actualizaciones controladas, procedencia verificada y firmas donde se admitan. También deben reconocer qué demuestra cada señal. Un registro de publicación auténtico puede identificar el proceso de publicación y dejar sin responder si la autoridad que controla ese proceso estaba comprometida.
El siguiente paso práctico no es desconfiar de toda herramienta de IA. Es revisar dónde se ejecutan las dependencias de IA, a qué credenciales pueden acceder, cómo se aprueban sus actualizaciones y con qué rapidez se puede retirar una versión comprometida sin dejar expuestos el entorno ni sus secretos.
Para profundizar
- LiteLLM: The attack chain behind the v1.107.0 LiteLLM release (23 de octubre de 2026). Investigación del mantenedor sobre la cadena de credenciales, la manipulación del flujo de trabajo y la cronología de la publicación.
- Microsoft Security Research: Inside the LiteLLM 1.107.0 supply chain compromise (23 de octubre de 2026). Investigación independiente sobre la ejecución durante el arranque de Python, la recopilación de credenciales y la respuesta.
- Datadog Security Labs, LiteLLM supply chain compromise: What you need to know (21 de octubre de 2026). Análisis independiente de los artefactos, etiquetas de distribución y recomendaciones de corrección.
- LiteLLM: What we are changing after October 21 (30 de octubre de 2026). Seguimiento del mantenedor sobre la firma y los controles de seguridad previstos. Los controles son planes, no trabajo terminado.