Un ataque mostró que las firmas válidas no siempre prueban que una publicación sea segura.
El 19 de mayo de 2026, una campaña contra npm dejó al descubierto una debilidad en la cadena de suministro del software. Al menos 633 versiones dañinas superaron las comprobaciones de Sigstore porque se publicaron con certificados válidos generados desde una identidad comprometida.
Sigstore hizo lo previsto: verificó que el paquete salía de un entorno de integración continua, aceptó el certificado y dejó constancia en un registro de transparencia. La brecha estaba en otro punto. El sistema podía confirmar que la cuenta era válida, pero no que su titular hubiera autorizado la publicación.
La operación, relacionada por varios investigadores con TeamPCP, empezó con paquetes que llevaban años sin cambios, como jest-canvas-mock y size-sensor. Luego se propagó por @antv y por paquetes sin ámbito. Socket elevó el balance a 639 versiones en 323 paquetes; en todo el ciclo rastreó 1.055 versiones maliciosas en npm, PyPI y Composer.
Un día antes, la extensión Nx Console para Visual Studio Code sufrió un ataque parecido. La versión 18.95.0, publicada con credenciales robadas, estuvo disponible menos de 40 minutos, pero se activó unas 6.000 veces, en gran parte mediante actualizaciones automáticas.
El código buscaba tokens de GitHub y npm, claves de AWS, datos de Kubernetes, secretos de 1Password y configuración de Claude Code. Para los equipos, una insignia de confianza no prueba por sí sola que una publicación sea legítima. Hace falta controlar cuentas, aprobaciones, extensiones y secretos.
Basado en: Louis Columbus, VentureBeat