Por Canuto  

LiteLLM, una popular interfaz de Python para conectarse con múltiples modelos de lenguaje, retiró dos versiones de PyPI tras descubrirse que habían sido infectadas con malware para robar credenciales. El caso apunta a un ataque más amplio contra la cadena de suministro de software que habría comenzado con la manipulación de Trivy y su integración en flujos de CI/CD.
***

  • LiteLLM retiró las versiones v1.82.7 y v1.82.8 de PyPI por incluir código malicioso en el archivo litellm_init.pth.
  • Según Aqua Security, atacantes explotaron una mala configuración en GitHub Actions de Trivy para robar credenciales privilegiadas y alterar pipelines.
  • La PyPA recomendó asumir que cualquier credencial accesible desde el entorno de LiteLLM pudo haber quedado expuesta y debe ser revocada o rotada.

 

LiteLLM, una interfaz de código abierto para acceder a múltiples modelos de lenguaje grandes, quedó en el centro de un incidente de seguridad luego de que dos de sus versiones publicadas en Python Package Index, o PyPI, fueran retiradas por contener malware diseñado para robar credenciales.

Las versiones afectadas fueron LiteLLM v1.82.7 y v1.82.8. De acuerdo con la información reportada por The Register, ambas incluían código malicioso dentro de un archivo de componente llamado litellm_init.pth, lo que abrió la puerta a la posible exposición de secretos y tokens disponibles en los entornos donde el paquete fue instalado y ejecutado.

El caso es relevante más allá de un solo proyecto. También vuelve a poner en primer plano los riesgos de la cadena de suministro de software, especialmente en herramientas usadas por desarrolladores de inteligencia artificial, donde la automatización de despliegues y pruebas se apoya de forma intensa en integraciones de terceros.

En términos simples, un ataque de cadena de suministro ocurre cuando los atacantes no comprometen primero al usuario final, sino a una pieza intermedia del ecosistema, como una librería, una acción de GitHub, un contenedor o una herramienta de seguridad. Cuando esa pieza se distribuye de forma masiva, el impacto puede multiplicarse rápidamente.

Cómo se habría originado el compromiso

Krrish Dholakia, CEO de Berri AI y responsable del mantenimiento de LiteLLM, dijo en una publicación en línea que el compromiso parece haberse originado por el uso de Trivy dentro de la canalización CI/CD del proyecto. Trivy es un escáner de vulnerabilidades de código abierto mantenido por Aqua Security y ampliamente utilizado como control de seguridad en numerosos flujos de desarrollo.

Según Aqua Security, la campaña maliciosa comenzó a finales de febrero. Los atacantes habrían aprovechado una mala configuración en el entorno de GitHub Actions de Trivy para robar un token de acceso privilegiado que permitía manipular la canalización CI/CD del proyecto.

El software fue subvertido el 19 de marzo, cuando un grupo identificado como TeamPCP utilizó credenciales comprometidas para publicar una versión maliciosa de Trivy, la v0.69.4. Más tarde, el 22 de marzo, también se publicaron como imágenes de DockerHub las versiones maliciosas v0.69.5 y v0.69.6.

Sin embargo, Aqua Security explicó que el método empleado fue más sofisticado que la simple publicación de una nueva versión alterada. La firma señaló que los atacantes modificaron etiquetas de versión existentes asociadas con el script de GitHub Action trivy-action, lo que permitió inyectar código malicioso en flujos de trabajo que muchas organizaciones ya estaban ejecutando sin advertir cambios visibles.

Ese detalle es importante porque muchas canalizaciones CI/CD dependen de etiquetas de versión en lugar de fijar commits específicos. Cuando una organización referencia una etiqueta mutable, puede seguir ejecutando código distinto al esperado si esa referencia es alterada por un atacante.

Qué ocurrió dentro de LiteLLM

Dholakia explicó que el token PYPI_PUBLISH de LiteLLM, almacenado en el repositorio de GitHub del proyecto como una variable .env, fue enviado a Trivy. Allí, según su relato, los atacantes lograron obtenerlo y luego lo utilizaron para subir nuevo código de LiteLLM a PyPI.

El directivo afirmó que el equipo eliminó todos sus tokens de publicación de PyPI tras detectar el incidente. También indicó que, aunque sus cuentas contaban con autenticación de dos factores, el problema en este caso estuvo relacionado con un token comprometido y no con el acceso directo a las cuentas.

En sus declaraciones, Dholakia señaló que el proyecto está revisando sus cuentas para reforzar la seguridad. Entre las medidas consideradas mencionó la publicación confiable mediante tokens JWT y la posibilidad de migrar hacia una cuenta distinta de PyPI.

Este punto refleja una lección frecuente en seguridad moderna. La protección de cuentas con 2FA sigue siendo valiosa, pero no resuelve por sí sola el riesgo asociado a secretos de automatización mal gestionados, sobre todo cuando esos secretos circulan por pipelines complejos y herramientas externas.

Para los proyectos de software que dependen de publicaciones automatizadas, la exposición de un token de distribución puede ser suficiente para que un actor malicioso publique paquetes aparentemente legítimos, firmados o distribuidos desde canales oficiales.

Aviso de seguridad y posible impacto

La Python Packaging Authority, o PyPA, publicó un aviso de seguridad sobre el compromiso de LiteLLM. Su recomendación fue clara: cualquier persona que haya instalado y ejecutado el proyecto debe asumir que cualquier credencial disponible para el entorno de LiteLLM pudo haber quedado expuesta.

En consecuencia, la PyPA pidió revocar o rotar esas credenciales según corresponda. Esto puede incluir claves de API, secretos de despliegue, credenciales de servicios en la nube, tokens de acceso a repositorios u otros datos sensibles presentes en variables de entorno o configuraciones locales.

El impacto exacto sobre usuarios y organizaciones no fue cuantificado en el reporte. Tampoco se detalló cuántas instalaciones descargaron específicamente las versiones comprometidas antes de que fueran eliminadas del índice de paquetes.

Aun así, el incidente tiene peso especial porque LiteLLM funciona como una capa de acceso a múltiples modelos de lenguaje grandes. En la práctica, eso implica que puede operar en entornos donde circulan claves de proveedores de IA, servicios empresariales y flujos internos con información sensible.

Para lectores menos familiarizados con este tipo de software, las interfaces como LiteLLM suelen servir como puente entre aplicaciones y distintos modelos de IA. Por eso, si una dependencia de este tipo es comprometida, el alcance potencial va más allá del equipo del desarrollador y puede tocar sistemas productivos.

Spam presuntamente generado por IA en GitHub

El episodio incluyó además un elemento inusual. El reporte de vulnerabilidad en GitHub aparentemente fue blanco de una campaña de spam diseñada para distraer y ocultar comentarios útiles dentro del hilo de discusión.

Según el investigador de seguridad Rami McCarthy, a las 05:44 AM PDT docenas de variaciones presumiblemente generadas por inteligencia artificial de la frase “Thanks, that helped!” inundaron el repositorio. El efecto de ese ruido era dificultar la lectura del intercambio técnico en torno al incidente.

McCarthy indicó que 19 de las 25 cuentas utilizadas para publicar esos mensajes también fueron empleadas en la campaña de spam asociada a Trivy. Aunque ese dato no amplía por sí mismo el daño técnico, sí sugiere una táctica paralela para entorpecer la respuesta comunitaria y la visibilidad del análisis útil.

La combinación de código malicioso y ruido informativo representa un patrón preocupante. En incidentes de seguridad, cada minuto cuenta, y la saturación de canales públicos con mensajes irrelevantes puede ralentizar el trabajo de investigadores y mantenedores.

Una advertencia para el ecosistema de desarrollo

El caso de LiteLLM refuerza una discusión cada vez más urgente en torno a la seguridad de la infraestructura que sostiene el desarrollo moderno. Herramientas de escaneo, acciones automatizadas, imágenes de contenedor y tokens de publicación se han vuelto piezas críticas del proceso, pero también objetivos atractivos para actores maliciosos.

Cuando una utilidad de seguridad como Trivy termina convertida en vector de ataque, el problema adquiere una dimensión extra. Muchas organizaciones confían en ese tipo de software precisamente para reducir riesgos, por lo que un compromiso en esa capa puede propagarse con rapidez y con una falsa sensación de confianza.

La lección inmediata parece apuntar a prácticas más estrictas. Entre ellas destacan el uso de commits fijados en CI/CD, la reducción de privilegios de los tokens, la rotación frecuente de secretos y la adopción de mecanismos de publicación confiable que minimicen la exposición de credenciales estáticas.

Por ahora, la prioridad para quienes usaron LiteLLM en las versiones afectadas es revisar instalaciones, identificar credenciales potencialmente accesibles desde esos entornos y proceder a su revocación o reemplazo. El incidente también deja una señal más amplia para el ecosistema de IA y software abierto: la automatización acelera el desarrollo, pero también puede amplificar los errores de seguridad cuando una pieza confiable es comprometida.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados