Cuando una dependencia se vuelve vector de robo: el ataque a PyTorch Lightning en PyPI expone credenciales y secretos

Un paquete legítimo y muy utilizado en el ecosistema Python, PyTorch Lightning, fue manipulado en una publicación maliciosa en PyPI y entregó un cargador de credenciales dirigido a navegadores, archivos de entorno y servicios en la nube. El código malicioso se activaba al importar la librería, levantaba un proceso en segundo plano que descargaba un entorno de ejecución JavaScript (Bun v1.3.13) desde GitHub y ejecutaba un archivo ofuscado de gran tamaño —identificado por los proveedores como una carga denominada “ShaiWorm”— con capacidades de robo de secretos y ejecución remota de comandos.

Los responsables del proyecto detectaron el incidente y publicaron un aviso técnico en su repositorio; Microsoft Threat Intelligence también informó que Defender bloqueó la rutina en algunos entornos y alertó a los desarrolladores. La campaña está orientada a extraer .env, tokens de GitHub, claves/API de AWS/Azure/GCP y datos almacenados en Chrome, Firefox y Brave, además de poder interactuar con APIs en la nube para extrapolar accesos. Para detalles técnicos y la respuesta del equipo, puede consultarse el aviso público en GitHub: https://github.com/Lightning-AI/pytorch-lightning/issues/21689 y el reporte de Microsoft: https://x.com/MsftSecIntel/status/2050414202259472521.

Que una dependencia tan difundida haya sido usada como vector recuerda que la cadena de suministro del software es uno de los eslabones más frágiles en seguridad. PyTorch Lightning acumula millones de descargas mensuales, por lo que la ventana de exposición para organizaciones y desarrolladores individuales puede ser amplia si no se actúa rápido. En respuesta inmediata, el paquete volvió a una versión previa considerada segura en PyPI, pero la incertidumbre sobre cómo se comprometió el proceso de build/release obliga a asumir que la campaña pudo haber alcanzado entornos con importaciones automáticas o entornos CI que instalan dependencias sin restricciones.

Si importaste la versión comprometida (2.6.3 según el aviso) o ejecutaste “import lightning” en ese periodo, debes asumir compromiso de secretos. La primera acción imprescindible es la rotación de credenciales: revoca y reemplaza tokens de GitHub, claves de API y credenciales de nube afectadas, y cambia contraseñas y secretos que residan en archivos .env utilizados por tus proyectos. También conviene auditar el acceso en las cuentas de nube para detectar uso anómalo y aplicar medidas como forzar la rotación de claves y revisar logs de autenticación.

En los sistemas donde pudo ejecutarse el código, busca indicadores de compromiso: procesos “bun” inesperados, ficheros temporales con nombres parecidos a router_runtime.js, conexiones a repositorios o artefactos externos y cualquier ejecución de comandos remotos registrada por tu EDR o logs. Herramientas de escaneo de dependencias (por ejemplo, pip-audit) y soluciones de detección en endpoints pueden ayudar a identificar instalaciones infectadas; la página de estadísticas del paquete muestra su gran difusión y sirve para priorizar revisiones: https://pypistats.org/packages/pytorch-lightning.

Para reducir el riesgo futuro, incorpora controles en tu ciclo de vida de desarrollo: usa entornos virtuales o contenedores con dependencias fijadas por hash o versión y verifica firmas cuando estén disponibles; habilita revisiones automáticas de dependencias en tus repositorios (Dependabot u otras herramientas) y aplica el principio de menor privilegio en credenciales de CI/CD y en permisos de API. Además, considera generar SBOMs (inventarios de software) para tus builds y aplicar verificaciones de integridad antes de desplegar artefactos en producción.

En infraestructuras en la nube, adoptar gestores de secretos (AWS Secrets Manager, Azure Key Vault, Google Secret Manager) y credenciales efímeras reduce el impacto de un robo puntual. Para organizaciones con equipos de datos y ML, limita el acceso a claves desde notebooks y despliegues locales, evita mantener secrets en archivos .env en repositorios ni en entornos sin control, y exige autenticación con tokens de corto plazo o roles asumiendo credenciales en lugar de claves permanentes.

Finalmente, la lección es clara: las dependencias de cadena de suministro son objetivos críticos y su compromiso exige respuesta rápida, rotación de secretos y revisión de procesos de CI/CD y publicación. Mantente atento a los avisos del mantenedor y a actualizaciones de seguridad del ecosistema; la comunidad y las herramientas de seguridad han de trabajar juntas para reducir ventanas de exposición y detectar manipulaciones antes de que se propaguen.