Alerta de seguridad: malware que se activa al importar Lightning 2.6.2 y 2.6.3 roba credenciales y se replica en npm y repositorios

Una nueva entrega del problema persistente de las cadenas de suministro de software acaba de golpear al ecosistema Python: las versiones 2.6.2 y 2.6.3 del paquete Lightning, publicadas el 30 de abril de 2026, fueron liberadas con código malicioso diseñado para robar credenciales y propagarse desde entornos de desarrollo hasta repositorios remotos. El proyecto ha sido puesto en cuarentena en el índice oficial de paquetes, pero el vector y la sofisticación del ataque exigen una respuesta rápida y coordinada por parte de equipos de desarrollo, administradores de infraestructuras y responsables de seguridad.

Desde el punto de vista técnico, el paquete comprometido ocultaba un directorio llamado _runtime que contenía un descargador y una carga útil JavaScript ofuscada. La cadena de ejecución se activa automáticamente al importar el módulo, sin acciones adicionales por parte del desarrollador. Un script Python denominado start.py descarga el runtime Bun y hace correr un payload ofuscado de gran tamaño ("router_runtime.js") cuyo objetivo principal es la recolección masiva de credenciales. Entre las credenciales buscadas, los tokens de GitHub se validan contra el endpoint de la API antes de usarlos para inyectar un payload de comportamiento gusano en múltiples ramas de repositorios con permisos de escritura, creando o sobrescribiendo archivos y usando una identidad codificada para aparentar ser otra organización. A su vez, el malware implementa un vector de propagación npm que altera paquetes locales —modificando el postinstall en package.json, aumentando versiones de parche y reapackando los .tgz— de modo que un desarrollador que publique sin verificar puede distribuir el malware hacia la cadena de suministro de npm.

Las implicaciones son graves: un ataque que combina ejecución automática al importar, robo de tokens y capacidades de reposición masiva puede comprometer tanto entornos locales como pipelines CI/CD y downstream users. Si un token con permisos amplios es robado, el atacante no solo extrae datos sino que puede introducir código malicioso directamente en múltiples repositorios, escalando el daño de forma exponencial. Además, la mezcla de vectores Python y npm evidencia cómo los atacantes buscan puntos de apoyo en el entramado multinivel de dependencias modernas.

Acciones inmediatas recomendadas: bloquear y eliminar las versiones 2.6.2 y 2.6.3 de todos los sistemas afectados y, si fuera necesario, degradar a la última versión conocida limpia (2.6.1). Rotar y revocar de inmediato todos los tokens y credenciales que hayan podido residir en las máquinas comprometidas, incluyendo tokens personales y de servicio, claves SSH y secretos de CI. Revisar el historial de commits en repositorios que usan esos tokens buscando commits y archivos inesperados (autoría falsa, nuevos archivos o sobrescrituras sin preaviso) y restaurar desde copias de seguridad o estado conocido bueno si se detecta manipulación. Para la detección local, busque artefactos como directorios ocultos tipo _runtime, scripts start.py, presencia del runtime Bun y ficheros de payload ofuscado (por ejemplo router_runtime.js) y modificaciones recientes en package.json con hooks postinstall; eliminar paquetes afectados y reinstalarlos desde fuentes verificadas es imprescindible.

Medidas preventivas a medio y largo plazo: aplicar políticas de mínimos privilegios en tokens (usar tokens de repositorio o tokens con permisos finos en lugar de tokens con alcance global), habilitar autenticación multifactor y proteger las cuentas mantenedoras de paquetes con 2FA obligatoria, usar lockfiles y hashes verificados para dependencias (pip hash, lockfiles de poetry/pipenv), revisar y restringir la capacidad de publicación en CI, y adoptar prácticas recomendadas por la comunidad para la seguridad de la cadena de suministro como SLSA y las guías del OpenSSF. Automatizar el escaneo de secretos en repositorios y en artifacts, comprobar la integridad de paquetes descargados y limitar la exposición de credenciales en entornos locales reducirá la ventana de explotación en futuros incidentes.

Es importante seguir fuentes oficiales y actualizaciones de los mantenedores mientras continúe la investigación: el proyecto afectado comparte información pública en su repositorio y en PyPI, y organismos y firmas de seguridad están publicando indicadores de compromiso y análisis técnicos detallados que conviene seguir para una respuesta eficaz. Consulte la página del proyecto en PyPI https://pypi.org/project/lightning/ y el repositorio oficial en GitHub https://github.com/Lightning-AI/lightning para avisos y actualizaciones, y repase las recomendaciones generales de seguridad de la cadena de suministro en iniciativas como OpenSSF https://openssf.org/.

En resumen: la lección se repite —auditorías periódicas, least privilege, rotación de credenciales y validación de artefactos son imprescindibles— y la rápida detección y revocación de recursos comprometidos es la diferencia entre un incidente contenido y una brecha extensiva en múltiples proyectos y ecosistemas.