Atacantes usaron credenciales robadas para publicar paquetes npm maliciosos con certificaciones Sigstore válidas, revelando una falla sistémica en la verificación de identidad de herramientas de desarrollo y comprometiendo asistentes de código IA. Urge reforzar la seguridad.
Puntos Clave
- 01.Los atacantes eludieron la verificación de procedencia de Sigstore en npm utilizando certificados válidos generados a partir de cuentas de mantenedores comprometidas.
- 02.Se explotaron múltiples vulnerabilidades críticas en herramientas de desarrollo, incluyendo extensiones de VS Code, CLIs de codificación de IA (Claude Code, Gemini, Cursor, Copilot) y Semantic Kernel.
- 03.Siete superficies de ataque distintas fallaron en 48 horas, demostrando un modelo de verificación de herramientas de desarrollo roto que los marcos de proveedores actuales no cubren adecuadamente.
- 04.Actores de amenazas, como STARDUST CHOLLIMA, han aumentado significativamente su ritmo operativo, apuntando a credenciales de desarrolladores mediante ingeniería social sofisticada y personas generadas por IA.
- 05.Se necesita una reevaluación urgente de las posturas de seguridad, exigiendo aprobación bipartita para la publicación de paquetes, deshabilitando aprobaciones automáticas en herramientas de IA y auditorías robustas de almacenamiento de credenciales.
El 19 de mayo, una alarmante estadística sacudió el panorama de la seguridad de la cadena de suministro de software: 633 versiones de paquetes npm maliciosos pasaron la verificación de procedencia de Sigstore. Esto ocurrió a pesar de que la intención era maliciosa, porque los atacantes habían logrado generar certificados de firma válidos utilizando credenciales robadas de cuentas de mantenedores legítimos. Este incidente crítico, junto con una serie de vulnerabilidades en las herramientas de desarrollo, ha destapado una brecha sistémica en cómo se verifican la confianza y la identidad en el ecosistema de desarrollo moderno, especialmente con la creciente integración de la inteligencia artificial.
La Ilusión de la Confianza: Sigstore Eludido
La esencia del problema residía en un hecho perturbador: Sigstore funcionó exactamente según lo diseñado. Verificó que el paquete se construyó en un entorno de integración continua (CI), confirmó que se emitió un certificado válido y registró todo en el registro de transparencia. La falla no estaba en la mecánica de Sigstore, sino en su alcance. El sistema no pudo determinar si la persona que poseía las credenciales autorizó la publicación real, un vacío crítico que convirtió la última señal de confianza automatizada en npm en un sofisticado camuflaje para los atacantes.
Este lapso permitió a los atacantes enmascarar sus actividades maliciosas detrás de una capa de legitimidad aparente, socavando fundamentalmente la confianza que los desarrolladores depositan en las herramientas de la cadena de suministro. La capacidad de un adversario para comprometer una cuenta de mantenedor y luego usar esa identidad para generar certificados de firma válidos representa un desafío profundo para los modelos de seguridad existentes.
Un Precursor: El Compromiso de la Extensión Nx Console
Solo un día antes del incidente de Sigstore, el 18 de mayo, StepSecurity documentó un ataque a la extensión Nx Console para VS Code, una herramienta ampliamente utilizada por desarrolladores con más de 2.2 millones de instalaciones. La versión 18.95.0 de la extensión se publicó utilizando credenciales robadas y permaneció activa por menos de 40 minutos. Sin embargo, en esa breve ventana, la telemetría interna de Nx registró aproximadamente 6,000 activaciones, la mayoría a través de actualizaciones automáticas, en contraste con solo 28 descargas oficiales directas.
La carga útil de este ataque fue devastadora, diseñada para cosechar información sensible de las máquinas de los desarrolladores. Incluía archivos de configuración de Claude Code, claves de AWS, tokens de GitHub, tokens de npm, contenido de bóvedas de 1Password y tokens de cuentas de servicio de Kubernetes. Este incidente demostró la velocidad y la escala con la que los atacantes pueden explotar las credenciales comprometidas y la naturaleza crítica de los datos en riesgo.
La Campaña "Mini Shai-Hulud": Una Cascada en la Cadena de Suministro
La verdadera escala de la amenaza se materializó con la campaña "Mini Shai-Hulud", atribuida por múltiples investigadores al actor de amenazas con motivaciones financieras identificado como TeamPCP. Esta campaña masiva golpeó el registro de npm a la 01:39 UTC del 19 de mayo. Endor Labs detectó la ola inicial cuando dos paquetes inactivos, jest-canvas-mock y size-sensor, publicaron nuevas versiones que contenían un script Bun ofuscado de 498 KB. Ninguno de estos paquetes había sido actualizado en más de tres años, lo que hizo que una versión repentina con dependencias de hash de confirmación de GitHub en bruto fuera una señal de detección clara, pero solo si las herramientas de seguridad estaban vigilando activamente.
Para las 02:06 UTC, la infección se había propagado a través del ecosistema de visualización de datos @antv y docenas de paquetes sin ámbito, incluyendo echarts-for-react (con aproximadamente 1.1 millones de descargas semanales). Socket elevó el total a 639 versiones comprometidas en 323 paquetes únicos solo en esta ola. A lo largo del ciclo de vida completo de la campaña, Socket ha rastreado 1,055 versiones maliciosas en 502 paquetes, abarcando npm, PyPI y Composer. StepSecurity confirmó que la carga útil incluía una integración completa de Sigstore, lo que significa que el atacante no solo robó credenciales, sino que pudo firmar y publicar paquetes npm posteriores que llevaban atestaciones de procedencia válidas.
Fallas Sistémicas: Vulnerabilidades en Herramientas de Codificación de IA
Estos incidentes no son eventos aislados, sino síntomas de un problema más amplio. Equipos de investigación de Endor Labs, Socket, StepSecurity, Adversa AI, Johns Hopkins, Microsoft MSRC y LayerX demostraron independientemente que el modelo de verificación de herramientas de desarrollo está fundamentalmente roto y que ningún marco de proveedor audita todas las superficies de ataque que fallaron en cascada.
Siete superficies de ataque fallaron en las 48 horas entre el 18 y el 19 de mayo, revelando un problema sistémico. Entre ellas, la suplantación de identidad de procedencia de npm, el robo de credenciales de extensiones de VS Code, la auto-ejecución de servidores MCP (Micro-Container Platform), la inyección de prompts en agentes de CI/CD, la ejecución de código en marcos de agentes, la exposición del almacenamiento de credenciales de IDE y la exposición de datos de la IA en la sombra.
Auto-ejecución de Servidores MCP y Agentes de IA
Adversa AI reveló TrustFall el 7 de mayo, demostrando que Claude Code, Gemini CLI, Cursor CLI y Copilot CLI auto-ejecutan servidores MCP definidos por el proyecto en el momento en que un desarrollador acepta un prompt de confianza de carpeta. Los cuatro por defecto responden con “Sí” o “Confiar”. Una sola pulsación de tecla genera un proceso sin aislamiento con los privilegios completos del desarrollador, capaz de leer secretos almacenados y código fuente de otros proyectos. En los ejecutores de CI que utilizan la Acción de GitHub de Claude Code en modo sin cabeza, el diálogo de confianza nunca se renderiza, permitiendo que el ataque se ejecute sin interacción humana.
Inyección de Prompts y Exposición de Claves de API
Investigadores de Johns Hopkins publicaron “Comment and Control”, probando que una instrucción maliciosa en el título de una solicitud de extracción de GitHub podía hacer que Claude Code Security Review publicara su propia clave de API como comentario. El mismo ataque funcionó en la Acción de Google Gemini CLI y el Agente Copilot de GitHub. Anthropic calificó la vulnerabilidad con un CVSS de 9.4 (Crítica) a través de su programa HackerOne.
Vulnerabilidades del Semantic Kernel y Almacenamiento de Credenciales
Microsoft MSRC reveló dos vulnerabilidades críticas en Semantic Kernel el 7 de mayo. Una redirige campos de almacén vectorial controlados por el atacante a una llamada eval() de Python; la otra expone un método de descarga de archivos del lado del host como una función de kernel invocable, lo que significa que un documento envenenado en un almacén vectorial puede iniciar un proceso en el host. Además, investigadores de seguridad de LayerX demostraron que Cursor almacena claves de API y tokens de sesión en almacenamiento desprotegido, lo que permite que cualquier extensión del navegador acceda a las credenciales del desarrollador sin permisos elevados.
Amenazas Crecientes: Adversarios Duplican el Ritmo Operativo
Los actores de amenazas que buscan estas credenciales han duplicado su ritmo operativo, evidenciando una escalada preocupante. El informe Verizon 2026 Data Breach Investigations Report, publicado el 19 de mayo, encontró que el 67% de los empleados acceden a servicios de IA desde cuentas no corporativas en dispositivos corporativos. La IA en la sombra es ahora la tercera acción interna no maliciosa más común en los conjuntos de datos de DLP (Data Loss Prevention). El código fuente encabeza todos los tipos de datos enviados a plataformas de IA no autorizadas, la misma clase de activos que la campaña del gusano npm. El informe CrowdStrike 2026 Financial Services Threat Landscape Report, publicado el 14 de mayo, documenta a los adversarios que buscan activamente los tipos de credenciales que cosechan estos ataques.
STARDUST CHOLLIMA triplicó su ritmo operativo contra entidades financieras en el cuarto trimestre de 2025. CrowdStrike documentó que el grupo utilizaba personas reclutadoras generadas por IA en LinkedIn y Telegram, enviando desafíos de codificación maliciosos que parecían evaluaciones técnicas y realizando videollamadas falsas con entornos sintéticos. Los objetivos son PAT de GitHub, tokens de npm, claves de AWS y secretos de CI/CD. La exposición a la IA en la sombra, una de las siete superficies de ataque, es la puerta por la que transitan.
El Modelo de Verificación Roto: Brechas en la Matriz de Auditoría
Ningún marco de proveedor actual abarca las siete superficies de ataque simultáneamente, lo que revela una brecha crítica en la seguridad de las herramientas de desarrollo. Esta deficiencia subraya la urgencia de reevaluar las estrategias de protección. La matriz de auditoría de identidad robada de herramientas de desarrollo expone dónde fallan las verificaciones y qué es lo que las pilas de seguridad existentes no pueden ver:
- Falsificación de procedencia de npm: Los certificados Sigstore generados a partir de tokens OIDC robados pasan la verificación automática. Las herramientas EDR y SAST no validan si la identidad de CI que firmó un paquete autorizó la publicación. La acción de auditoría recomendada es requerir aprobación bipartita en el momento de la publicación para paquetes con más de 10,000 descargas semanales y no tratar una insignia verde de Sigstore como prueba de legitimidad.
- Robo de credenciales de extensiones de VS Code: El Marketplace de VS Code aceptó una versión maliciosa publicada con un token de contribuyente robado. Las actualizaciones automáticas de extensiones eluden la detección de endpoints. Se debe aplicar políticas de antigüedad mínima para las actualizaciones de extensiones y auditar todas las extensiones con acceso a las API del terminal o del sistema de archivos.
- Auto-ejecución de servidores MCP: Los cuadros de diálogo de confianza de los cuatro CLIs de IA por defecto responden “Sí/Confiar” sin enumerar qué ejecutables se generarán. EDR monitorea el comportamiento del proceso, no lo que un LLM instruye a un servidor MCP. La mitigación implica deshabilitar la aprobación automática de servidores MCP con alcance de proyecto en las herramientas de IA y bloquear
.mcp.jsonen los pipelines de CI a menos que esté explícitamente en la lista blanca. - Inyección de prompts en agentes de CI/CD: Los flujos de trabajo de GitHub Actions que utilizan
pull_request_targetinyectan secretos en entornos de ejecutor que los agentes de IA procesan como instrucciones. Los registros de SIEM muestran una llamada a la API legítima, siendo la llamada misma el ataque. Es crucial migrar los flujos de trabajo de revisión de código de IA apull_requesty auditar los flujos de trabajo con acceso a secretos para integraciones de agentes de IA. - Ejecución de código del marco del agente: El SDK de Python de Semantic Kernel enrutó los campos de filtro del almacén vectorial a
eval(). El SDK de .NET expuso la escritura de archivos del host como una función de kernel invocable. Los firewalls de aplicaciones no inspeccionan cómo un marco de orquestación analiza las cargas útiles internamente. Se recomienda actualizar el SDK de Python de Semantic Kernel a 1.39.4 y el SDK de .NET a 1.71.0, y auditar todos los marcos de agentes en busca de funciones que accedan al sistema de archivos o al shell del host. - Exposición del almacenamiento de credenciales del IDE: Cursor almacena claves de API y tokens de sesión en almacenamiento desprotegido. DLP monitorea los datos en tránsito, pero las credenciales de Cursor en reposo son invisibles hasta la exfiltración. Es imperativo auditar las herramientas de desarrollo para las prácticas de almacenamiento de credenciales y requerir almacenamiento protegido.
- Exposición de datos de la IA en la sombra: El 67% de los empleados acceden a servicios de IA desde cuentas no corporativas. Las políticas CASB cubren SaaS sancionados, pero las cuentas de IA no corporativas operan fuera de su alcance. Se debe implementar una gobernanza de IA a nivel de navegador para monitorear el uso no corporativo de IA en dispositivos corporativos.
Acciones Inmediatas para Directores de Seguridad
Los directores de seguridad deberían considerar urgentemente la ejecución de esta matriz contra los contratos de proveedores actuales antes de que finalicen las renovaciones del segundo trimestre. Es crucial preguntar a cada proveedor qué de las siete superficies cubre su producto y tratar las “no respuestas” como un mapa de brechas. Cualquier credencial accesible desde una máquina de desarrollador o un ejecutor de CI que haya instalado paquetes npm afectados entre las 01:39 y las 02:18 UTC del 19 de mayo debe considerarse comprometida. Esto incluye PAT de GitHub, tokens de npm, claves de acceso de AWS, tokens de cuentas de servicio de Kubernetes, tokens de HashiCorp Vault, claves SSH y contenido de bóvedas de 1Password.
Las integraciones de agentes de codificación de IA que se ejecutan en pipelines de CI/CD con flujos de trabajo pull_request_target merecen una revisión exhaustiva. Cada una de ellas es una superficie de inyección de prompts que procesa los comentarios de PR como instrucciones del agente.
Los equipos de adquisiciones que evalúan herramientas de codificación de IA deben considerar añadir una dimensión de resistencia al robo de identidad a las evaluaciones de proveedores. La pregunta que vale la pena hacer: ¿puede el proveedor demostrar cómo su herramienta distingue una publicación legítima de un mantenedor de un atacante que usa credenciales comprometidas? Si no pueden, la herramienta no es una capa de verificación efectiva.
Redefiniendo la Identidad: El Camino Hacia la Seguridad del Desarrollador
La cadena de suministro de herramientas de desarrollo se enfrenta al mismo problema que enfrentaba la gestión de identidad y acceso (IAM) hace una década: las credenciales prueban quién dices ser, no quién eres. IAM tuvo una ventaja de 10 años en el desarrollo de controles compensatorios antes de que los grupos patrocinados por estados convirtieran el robo de credenciales en una operación industrial. El ecosistema de herramientas de codificación de IA está comenzando ese reloj ahora. La urgencia es palpable, y la necesidad de un cambio fundamental en los paradigmas de seguridad es innegable para proteger el futuro del desarrollo de software.


