TeamPCP: una firma válida que certificó malware en cripto

Cripto se construyó sobre una promesa: «no confíes, verifica». En mayo de 2026, un gusano de npm produjo una firma criptográfica perfectamente válida — que certificaba malware. El grupo TeamPCP envenenó Nx Console, la extensión oficial de VS Code (2,2 millones de instalaciones), y desató Mini Shai-Hulud, el primer gusano documentado que se autopropaga con provenance (procedencia firmada) SLSA Build Level 3 auténtica. GitHub confirmó la exfiltración de unos 3.800 de sus repositorios internos en menos de 20 minutos. Pero el dato que importa para cripto no es ese: es que la atestación criptográfica —la misma clase de prueba sobre la que se levanta toda la confianza on-chain— dejó de garantizar nada. Y no es un caso aislado: es el último eslabón de una línea de ocho años de ataques de cadena de suministro dirigidos específicamente contra cripto. Lo decimos sin alarmismo: el payload barre rutas de wallets, pero a 1 de junio no hay postmortem que documente fondos DeFi robados por esta campaña. Es un vector confirmado, no una pérdida consumada — y la historia previa explica por qué conviene tomárselo en serio.

¿Qué pasó exactamente en mayo de 2026?

El 11 de mayo de 2026 los equipos de seguridad de la cadena de suministro detectaron la primera ola de un gusano que infectaba paquetes de npm: más de 170 paquetes comprometidos, entre ellos componentes de proyectos tan usados como TanStack y librerías de Mistral AI. El 12 de mayo, el código fuente del gusano apareció publicado brevemente en un repositorio público de GitHub antes de ser retirado — material que sirvió de base para los análisis forenses posteriores.

El salto cualitativo llegó el 18 de mayo. TeamPCP publicó una versión maliciosa (v18.95.0) de Nx Console, la extensión oficial de VS Code para el monorepo Nx, con más de 2,2 millones de instalaciones. La versión envenenada estuvo disponible en el VS Code Marketplace una ventana muy corta: el postmortem oficial de Nx la cifra en 11 minutos y la alerta de CISA en 18 — en cualquier caso, menos de 20 minutos. En Open VSX (el registro abierto que usan editores como Cursor o VSCodium) la ventana llegó hasta unos 36 minutos. Tiempo más que suficiente para que la actualización automática la empujara a un número desconocido de máquinas de desarrolladores.

El 19 de mayo, GitHub confirmó la exfiltración de aproximadamente 3.800 de sus propios repositorios internos — una cifra reivindicada por el atacante y validada de forma provisional por la plataforma. GitHub aclaró que los repositorios de clientes no se vieron afectados. Ese mismo día se desató una segunda ola del gusano contra los paquetes de la familia @antv (la suite de visualización de datos de AntDesign), elevando a más de 500 los paquetes comprometidos en esa oleada. La cifra de 518 millones que circuló corresponde a las descargas históricas totales acumuladas por los paquetes afectados, no a descargas del malware.

¿Cómo funcionó el ataque, paso a paso?

La elegancia del ataque está en encadenar confianza legítima en cada eslabón. La secuencia, reconstruida desde los boletines de StepSecurity, OX Security y el postmortem de Nx:

1. Extensión envenenada. El desarrollador instala o actualiza Nx Console desde el Marketplace oficial. La extensión tiene firma válida y procede del publisher correcto. Al activarse, la versión maliciosa ejecuta código en la máquina del desarrollador con los mismos permisos que su sesión de editor.
2. Robo del token de CI/CD. Muchos repositorios usan GitHub Actions con tokens OIDC (OpenID Connect: credenciales de corta duración que un pipeline obtiene para autenticarse sin secretos estáticos) y tokens de publicación de npm. El payload busca esas credenciales en el entorno y en los ficheros de configuración del proyecto: variables de entorno, ficheros .npmrc, tokens de Actions cacheados.
3. Propagación del gusano. Con un token de publicación de npm válido, el malware no necesita esperar a otra víctima humana. Republica versiones troyanizadas de los paquetes que ese token controla, y esos paquetes a su vez infectan a quien los instale. Es la propiedad que convierte un incidente puntual en un gusano: autorreplicación a través de la red de dependencias.
4. Firma de procedencia válida. Aquí está la innovación que asusta. Mini Shai-Hulud genera atestaciones SLSA Build Level 3 auténticas para los paquetes maliciosos. La cadena de procedencia que npm muestra como prueba de que un paquete se construyó en un pipeline confiable estaba criptográficamente correcta — solo que certificaba malware. La firma no estaba falsificada: estaba emitida por un pipeline secuestrado.
5. Barrido de credenciales y wallets. El payload escanea el disco en busca de rutas de wallets de criptomonedas — ficheros de Bitcoin, Ethereum y Monero, y los directorios de aplicaciones como Exodus, Electrum y Atomic — además de claves de CI/CD, tokens de nube y secretos de despliegue. Esto es lo que convierte un ataque genérico a la cadena de suministro en una amenaza específica para quien desarrolla en Web3.

¿Por qué este ataque es específicamente peligroso para devs Web3?

Un desarrollador de aplicaciones tradicionales que sufre este compromiso pierde, en el peor caso, secretos corporativos y acceso a infraestructura de la empresa. Un desarrollador Web3 tiene en la misma máquina, y a menudo en el mismo árbol de proyecto, activos que son dinero al portador.

El equivalente Web3 de «robar la contraseña de producción» es robar la clave privada que firma un despliegue de contrato, o la seed de una wallet de tesorería de un protocolo. No hay departamento de fraude que revierta la transacción ni soporte que congele la cuenta: si la clave se filtra y el atacante firma, los fondos se han ido. Las rutas que el payload de Mini Shai-Hulud rastrea — Exodus, Electrum, Atomic, claves de Ethereum y Bitcoin — son exactamente las que un dev cripto tiene a mano para probar, desplegar y operar.

A esto se suma el riesgo de pipeline. Si el token de publicación de npm de tu librería se filtra, el atacante no te roba a ti: troyaniza tu paquete y se lo entrega a todos tus usuarios con tu firma. Para un proyecto DeFi cuya librería de SDK consumen otras dapps, eso significa convertirse, sin saberlo, en el vector que compromete a terceros. El daño reputacional y de confianza es difícil de revertir.

La distinción honesta: a 1 de junio de 2026 no existe un postmortem público que documente fondos DeFi sustraídos atribuibles a esta campaña. El vector está confirmado por el análisis del payload; el robo de criptoactivos a través de él es un riesgo activo, no un hecho reportado. Tratarlo como inminente es prudente; afirmar que ya ha vaciado tesorerías es falso.

¿Es esto nuevo? El linaje de ataques de cadena de suministro contra cripto

No. Lo que hace a Mini Shai-Hulud relevante no es que sea inédito, sino que es el peldaño más alto de una escalera que cripto lleva subiendo desde 2018. La cadena de suministro de software —los paquetes de npm, las librerías que firman transacciones, los SDK que cargan las dapps— ha sido un objetivo recurrente precisamente porque conecta directamente con el dinero. Estos son los hitos:

La columna de robos enseña dos cosas. Primera: la escala y el daño no van de la mano. El ataque de septiembre de 2025 tocó paquetes con 2.600 millones de descargas semanales y se llevó céntimos; Ledger drenó más de medio millón de dólares en menos de dos horas con una librería mucho más pequeña, porque estaba enchufada directamente a las firmas de dapps. Lo que decide el botín no es cuántas máquinas infectas, sino cuántas tienen una clave que mueve dinero al alcance. Segunda: la sofisticación sí escala. Copay esperaba pasivamente a una víctima rica; Shai-Hulud se autopropaga; Mini Shai-Hulud, además, firma su propio malware con una atestación que el sistema da por buena.

La paradoja de la confianza: cuando una firma válida certifica malware

Aquí está el golpe que debería incomodar a cripto más que el robo de 3.800 repositorios. La industria del software construyó SLSA y las atestaciones de procedencia de npm como respuesta a SolarWinds: la idea era que pudieras verificar criptográficamente que un paquete se construyó en un pipeline confiable, sin tener que confiar en nadie de palabra. Es, punto por punto, la misma filosofía que sostiene cripto — «don't trust, verify», la verificación reemplaza a la confianza.

Mini Shai-Hulud no rompió esa verificación: la cooptó. Sus paquetes maliciosos llevan una firma de procedencia SLSA Build Level 3 auténtica, criptográficamente correcta, porque la emitió un pipeline real — solo que secuestrado. La verificación pasa. La prueba es válida. Y certifica malware. La lección es desagradable y aplica directamente a cualquier sistema basado en atestación, incluido buena parte del andamiaje on-chain: una firma válida demuestra de dónde viene algo, nunca que sea honesto. Cuando confundimos «verificado» con «seguro», la criptografía deja de protegernos y empieza a darnos una falsa tranquilidad firmada.

¿En qué se diferencia de SolarWinds?

El ataque a SolarWinds (2020) es la referencia obligada de la cadena de suministro de software. La comparación ayuda a medir cuánto ha cambiado el listón en seis años.

Dos diferencias importan más que las demás. La primera es la autorreplicación: SolarWinds dependía de que las víctimas instalaran una actualización concreta; Mini Shai-Hulud se propaga solo cada vez que captura un token de publicación, sin esperar intervención humana. La segunda es la procedencia válida: la industria construyó SLSA y las atestaciones de npm precisamente como respuesta a SolarWinds, para que pudieras verificar que un paquete vino de un pipeline confiable. TeamPCP no rompió esa defensa — la cooptó. Una firma de procedencia auténtica deja de ser garantía cuando el pipeline que la emite ya está comprometido.

¿Quién es TeamPCP y por qué importa la atribución?

Google Threat Intelligence (Mandiant) rastrea al grupo como UNC6780. A diferencia de SolarWinds, atribuido a espionaje de estado-nación, TeamPCP tiene motivación financiera: monetiza los accesos a través del grupo de ransomware Vect, según el análisis recogido por SANS Internet Storm Center y CSA Labs. El grupo lleva latente desde aproximadamente el 24 de mayo; no hay nuevas olas fechadas con posterioridad a esa fecha que se puedan dar por confirmadas.

La cronología institucional cerró el círculo a finales de mayo. El 27 de mayo, la vulnerabilidad de Nx Console — registrada como CVE-2026-48027, con una puntuación CVSS de 9,8 en el NVD y 9,4 en la valoración de CISA — se añadió al catálogo KEV (Known Exploited Vulnerabilities) de CISA, la lista de fallos con explotación activa confirmada. El 28 de mayo, CISA emitió una alerta formal sobre los compromisos de Nx Console y los repositorios de GitHub. Por separado, el CERT-EU documentó a la Comisión Europea como víctima downstream a través de un compromiso anterior del mismo grupo en la herramienta Trivy (marzo de 2026), lo que muestra el alcance institucional del actor más allá del ecosistema cripto.

¿Cómo audito mi entorno de desarrollo Web3 ahora mismo?

Este es el bloque accionable. Si desarrollas en Web3 y usas VS Code, npm o pipelines de CI/CD, recorre estos puntos antes de seguir leyendo el resto.

• Audita las extensiones de VS Code instaladas. Revisa la lista de extensiones y sus versiones. Si tienes Nx Console, confirma que no estás en la v18.95.0; Nx publicó una versión limpia tras el incidente. Más allá de esta extensión concreta, desactiva la actualización automática de extensiones en entornos donde manejes claves sensibles: la actualización silenciosa fue precisamente lo que distribuyó el payload en menos de 20 minutos.
• Verifica la procedencia de tus dependencias npm — con escepticismo. Ejecuta npm audit signatures y revisa las atestaciones de procedencia, pero asume que una procedencia válida ya no es prueba suficiente por sí sola. Una pista útil reportada en este caso: en la oleada de @antv del 19 de mayo se publicaron más de 300 versiones en una ráfaga de unos 22 minutos; herramientas de análisis de dependencias como Socket.dev o Phylum detectan ese patrón de publicación masiva en tiempo real.
• Aísla las claves de CI/CD de los permisos de publicación. El token que construye y testea no debería ser el mismo que publica paquetes. Usa tokens de npm granulares con alcance mínimo, prefiere OIDC de corta duración frente a secretos estáticos de larga vida, y configura trusted publishing donde el registro lo soporte. Un token de build robado que no puede publicar no convierte tu librería en un gusano.
• Saca las claves de wallet del entorno de desarrollo. No guardes seeds de producción ni claves de despliegue en ficheros del proyecto, variables de entorno del editor o gestores de secretos que la sesión de VS Code pueda leer. Usa una wallet hardware o un firmante aislado para cualquier operación con valor real, y wallets desechables y sin fondos para pruebas.
• Rota credenciales si tienes la menor duda. Si instalaste o actualizaste Nx Console entre el 11 y el 19 de mayo, trata todas las credenciales accesibles desde esa máquina como comprometidas: tokens de npm y GitHub, claves de nube, y muy especialmente cualquier clave de wallet que haya tocado ese equipo. La rotación es barata comparada con asumir que no pasó nada.

¿Qué señales indican que una extensión o paquete está comprometido?

No siempre hay un CVE publicado cuando lo necesitas. Lo que hizo a este incidente difícil de detectar, según los análisis de Microsoft y StepSecurity, es que no se apoyó en infraestructura externa desconocida sino en plataformas de confianza —el propio Marketplace oficial, GitHub, el registro de npm—, justo donde las herramientas de seguridad suelen bajar la guardia. Por eso la recomendación de los equipos de respuesta (CISA, CERT-EU) no fue buscar una firma concreta, sino revisar accesos y actividad inusuales sobre esa infraestructura de confianza durante la ventana del 18-19 de mayo.

El indicador de ecosistema más fiable en esta campaña fue temporal: una ráfaga de versiones nuevas publicadas casi simultáneamente en muchos paquetes del mismo autor u organización —el patrón de un token de publicación robado republicando en masa, como las 300+ versiones de @antv en ~22 minutos—. Es un patrón que las herramientas de análisis de dependencias marcan en tiempo real.

La defensa práctica no es detectar el día cero, sino reducir el radio de explosión: actualizaciones manuales y revisadas en máquinas con claves, permisos mínimos, y separación tajante entre el equipo donde escribes código y el lugar donde viven las claves que mueven dinero.

¿Qué lecciones quedan para el desarrollo Web3?

Tres datos del propio incidente concentran la lección. El primero es de tiempo de reacción: CISA tardó nueve días en emitir la alerta formal (del compromiso del 19 de mayo a la alerta del 28), y el CVE-2026-48027 no entró al catálogo KEV hasta el 27. Quien esperó al aviso oficial para actuar estuvo expuesto más de una semana; la defensa no puede depender de la cadencia institucional.

El segundo es de alcance: el CERT-EU documentó a la Comisión Europea como víctima downstream de un compromiso anterior del mismo grupo en la herramienta Trivy, fechado en marzo de 2026. Es decir, UNC6780 llevaba al menos tres meses operando en la misma cadena de suministro antes de que la industria conectara los puntos. La superficie de un proyecto cripto ya no termina en el contrato auditado: empieza en el editor, el registro de paquetes y el pipeline que despliega.

El tercero es el que más enseña, porque es el que funcionó: según GitHub, los repositorios de clientes no se vieron afectados precisamente porque el acceso comprometido no los alcanzaba — la segregación de credenciales contuvo el daño. Esa es la frontera que separa una brecha molesta de una pérdida irreversible. Las firmas SLSA y las atestaciones de npm siguen siendo útiles, pero TeamPCP las cooptó: prueban que un paquete vino de un pipeline, no que ese pipeline fuera honesto. La defensa se desplaza hacia los permisos mínimos y la hipótesis de compromiso por defecto — y a no dejar nunca las claves que mueven valor al alcance de un editor.

Fuentes y enlaces: Postmortem oficial de Nx · StepSecurity (extensión comprometida) · SecurityWeek (GitHub confirma 3.800 repos) · The Record (clientes no afectados) · OX Security (Mini Shai-Hulud) · SANS ISC (UNC6780 / Vect) · CVE-2026-48027 · Alerta CISA (28-may) · npm (event-stream/Copay, 2018) · Ledger Connect Kit (2023) · @solana/web3.js (2024)