DEV Community: Cristian Carrillo

Mini Shai-Hulud: un gusano de cadena de suministro que explotó TanStack y el ecosistema npm.

Cristian Carrillo — Tue, 12 May 2026 20:32:29 +0000

El día de ayer (10/05/2026) la comunidad de npm y PyPI vivió un nuevo capítulo de Mini Shai-Hulud, un campaña de ataque de cadena de suministro dirigida por el grupo TeamPCP que comprometió paquetes de TanStack, Mistral AI, UiPath, OpenSearch, guardrails‑ai y más.

El impacto se estimó en más de 170 paquetes y 500M+ de descargas acumuladas, con un nivel de severidad crítico (CVSS ≈ 9.6) y un CVE asociado: CVE‑2026‑45321.

1 ¿Qué pasó?

El ataque inyectó código malicioso en paquetes de npm muy populares, empezando por el ecosistema de TanStack (por ejemplo, @tanstack/react‑router, @tanstack/vue‑router, etc.), y luego se extendió a Mistral AI, UiPath, OpenSearch, guardrails‑ai y otros.

El malware, un gusano de credenciales (credential‑stealing worm), hacía lo siguiente al ejecutarse durante npm install o cuando se usaba el paquete en CI/CD.

• Robaba tokens de GitHub, npm, AWS, GCP, Azure, Kubernetes, Vault, IDEs y hasta carteras de cripto.
• Se auto‑replegaba hacia otros paquetes que el mantenedor pudiera publicar, propagándose en el ecosistema.
• Establecía persistencia en máquinas de desarrolladores (Claude Code, VS Code, servicios de sistema) y podía borrar datos si se revocaba cierto token.

También se ha visto una variante en PyPI (guardrails‑ai@0.10.1, mistralai@2.4.6) que descarga y ejecuta un payload remoto sin verificación de integridad, ampliando el ataque a Python y otros ecosistemas.

2 ¿Cómo sucedió?

El ataque combinó ingeniería de engaños en GitHub con un mal uso de GitHub Actions y OIDC, sin necesidad de robar directamente el token de npm.

El flujo básico fue:

1. Inyección en el fork:

    ◦ Atacante hace fork de TanStack/router y sube un commit con un paquete @tanstack/setup que contiene un script prepare malicioso que ejecuta bun run tanstack_runner.js.
    ◦ El commit es “huérfano” y se hace pasar por algo legítimo gracias a la URL de GitHub.

2. Envenenamiento de caché en GitHub Actions:

    ◦ El workflow de CI/CD de TanStack ejecuta código del fork, lo que contamina el caché de pnpm y causa que se instale código controlado por el atacante.

3. Extracción de token OIDC y publicación de paquetes:

    ◦ El payload accede a la memoria del proceso del runner (/proc/*/mem) y extrae el OIDC token legítimo de GitHub, que el sistema de SLSA considera confiable.
    ◦ El atacante usa ese token para publicar versiones falsas de los paquetes de TanStack directamente al registro de npm, con probidad de SLSA válida, lo que hace que el paquete “se vea limpio” incluso con firmas.

4. Auto‑propagación del worm:

    ◦ El malware busca tokens de npm con bypass_2fa, enumera todos los paquetes del mantenedor y vuelve a publicar versiones comprometidas, generando el efecto de “gusano” en el ecosistema.

3 ¿Qué debes tener en cuenta?

Este incidente recalca varios peligros que ya no son "teóricos":

• GitHub Actions + OIDC = nuevo vector de ataque

Un token OIDC, aunque sea de corta vida, puede usarse para publicar paquetes y firmarlos con SLSA, dando pinta de legítimo a un paquete malicioso.
• Un solo npm install puede ser suficiente
◦ El malicioso router_init.js se ejecutaba en el pre‑instalación y se auto‑desprendía en segundo plano, sin dejar rastro claro en logs.
◦ Una vez instalado, el gusano podía robar cualquier secreto a disposición en esa máquina o flujo de CI.
• Las salvaguardias “tradicionales” no bastan
◦ Firmas de paquetes, SLSA, y hasta algunos scanners estáticos no detectaron el malware porque el código ejecutable era obfuscado y ejecutado en runtime.
• El impacto va más allá de npm
El ataque ya se ha extendido a PyPI y otros ecosistemas (SAP, Bitwarden, Intercom, Lightning, etc.), lo que muestra que estamos ante una campaña operativa continua de TeamPCP, no un ataque aislado.

4 ¿Qué hacer ahora?

Si usas npm/PyPI en producción, estos pasos no son opcionales:

• Identificar exposición:
    ◦ Revisa package‑lock.json / yarn.lock / pnpm‑lock.yaml (y requirements.txt o pipenv.lock en Python) buscando versiones afectadas de @tanstack/*, @uipath/*, mistralai, guardrails‑ai, @opensearch‑project/opensearch, etc.
    ◦ Busca router_init.js o setup.mjs en el árbol de node_modules y en tus tarballs.

• Rotar todos los secretos potencialmente expuestos:
    ◦ Tokens de npm, GitHub, AWS, Vault, Kubernetes, CI/CD, etc.
    ◦ Wiz y StepSecurity recomiendan rotar cualquier token si el entorno instaló alguna versión afectada, por el alcance de lo que el malware puede extraer.

• Eliminar persistencia en máquinas de desarrolladores:
    ◦ Borrar archivos como .claude/router_runtime.js, .claude/setup.mjs, .vscode/setup.mjs y revisar settings.json y tasks.json.
    ◦ En macOS/Linux, eliminar el servicio gh‑token‑monitor antes de tocar tokens de GitHub para evitar que el wiper se dispare.

• Bloquear infraestructura de C2:
    ◦ Bloquear a nivel DNS/proxy dominios como git‑tanstack.com, *.getsession.org y otras IPs/C2 documentadas por StepSecurity, Wiz, Socket, etc.

5 ¿Cómo protegerse a futuro?

Este ataque es una hoja de ruta de hardening para cualquier equipo que consuma paquetes de terceros:

• Reducir el alcance de OIDC en GitHub Actions:
    ◦ Usar solo id‑token: write en el job que realmente publica, y evitar OIDC en workflows de test/CI generales.

• Hardening de GitHub Actions:
    ◦ Asegurar que pull_request_target solo se ejecute en ramas protegidas y que no se ejecute código de forkeos sin validación.
    ◦ Limpiar caché de CI y usar restricciones de permisos entre fork y base.

• Adoptar buffers de tiempo para nuevos paquetes:
    ◦ Estrategias como “cooldown” de versiones nuevas (nuevas versiones de npm bloqueadas por 24–72 horas) dan margen para detectar y bloquear estos ataques antes de que lleguen a producción.

• Monitoreo de tiempo de ejecución en CI:
    ◦ Herramientas que monitorean tráfico de red, lectura de memoria de runner (/proc/*/mem) o uso de sudo / python3 de forma inusual ayudan a detectar estas inyecciones que evitan el escaneo estático.

• No confiar ciegamente en “provenance” o SLSA:
    ◦ Que un paquete tenga badges de SLSA no garantiza que el pipeline no haya sido comprometido; debes ver el provenance como una parte de tu cadena de confianza, no como la única.

6 Reflexión para líderes técnicos y de seguridad:

Este episodio muestra que:

• La cadena de suministro ya es un vector de ataque operativo y automatizado.
• Un gusano puede escalar de un solo paquete a docenas de repositorios y nubes en cuestión de horas.
• Debes combinar:
    ◦ Control de cambios de dependencias.
    ◦ Hardening de CI/CD.
    ◦ Monitoreo de tiempo de ejecución.
    ◦ Respuesta rápida de rotación de credenciales.

Enlace de referencia rápida:
• Vulnerabilidad CVE‑2026‑45321 (TanStack): detalle de impacto y severidad.
• Mini‑Shai‑Hulud en npm y PyPI: artículos de The Hacker News, Socket, StepSecurity y Wiz con IOCs y pasos de remediation.

Enigmas de la IA en el ámbito de la ciberseguridad

Cristian Carrillo — Sat, 28 Mar 2026 05:45:26 +0000

¿Qué son los enigmas de la IA en la ciberseguridad?

Cuando hablamos de enigmas, son las grandes interrogantes abiertas que plantea el uso de inteligencia artificial para proteger (y atacar) sistemas digitales. No solo se toman en cuenta los problemas técnicos, sino también éticos, estratégicos y de poder. Todavía no existe un consenso claro sobre muchas de estas cuestiones.

¿Qué significan estos enigmas?

En esencia, se refieren a preguntas como:

¿Hasta qué punto podemos confiar en un modelo de IA para tomar decisiones críticas de seguridad (bloquear usuarios, parar servicios, responder a incidentes) sin entender bien por qué la IA decide así?
¿Cómo garantizar que la IA no amplifique sesgos ni vulnere la privacidad, al mismo tiempo que detecta amenazas más rápido que los humanos?

Núcleo de los enigmas:

Doble uso de la IA: La misma tecnología que mejora la detección de amenazas y la automatización de respuestas también permite a los atacantes escalar phishing, malware, ataques adversariales y deepfakes.
Falta de control y explicabilidad: Muchos modelos de IA son "cajas negras", lo que genera incertidumbre sobre su fiabilidad, su vulnerabilidad a manipulación y quién es responsable cuando fallan.

Este auge de la IA ha introducido desafíos complejos en ciberseguridad que van más allá de las amenazas tradicionales, creando estos enigmas como la detección de ataques autónomos y la opacidad de los modelos. Estos problemas persisten debido a la rápida evolución de la tecnología.

IA agéntica autónoma

Los agentes capaces de razonar, planificar y ejecutar acciones sin supervisión humana representan el principal enigma, ya que muchos expertos los ven como el vector de ataque dominante. Pueden desplegarse para automatizar ransomware o sabotaje, evadiendo defensas tradicionales porque operan de forma impredecible y autónoma.

Malware adaptativo

El malware impulsado por IA aprende de fallos, reescribe su código y prueba métodos hasta infiltrarse. Esto mencionado anteriormente, haciendo imposible su detección con antivirus convencionales. Este "aprendizaje en tiempo real" crea un puzzle constante para las defensas estáticas.

Envenenamiento de datos

Los atacantes manipulan datos de entrenamiento para "cegar" sistemas de IA de seguridad, clasificando amenazas como inofensivas sin activar alertas. Detectar este envenenamiento sutil es un reto sin herramientas de auditoría avanzadas.

Deepfakes e impersonación

La IA genera deepfakes de voz o emails hiperrealistas para phishing o fraude, con un aumento de porcentaje alto en vishing. Verificar la autenticidad en tiempo real sigue siendo un enigma sin biométricos robustos.

Shadow AI y riesgos internos

Empleados usan IA no autorizada ("shadow AI"), creando flujos invisibles de datos sensibles y brechas regulatorias. Controlar privilegios mínimos y monitorear agentes internos es un desafío organizacional sin marcos "IA-first".

Cajas negras opacas

Los modelos de IA toman decisiones inexplicables, generando "puntos ciegos" donde ni analistas entienden los porqués, lo que erosiona la confianza en alertas automáticas. Explicar y auditar estas "cajas negras" es un desafío que permanece sin resolver.

Entonces, es clave en estos tiempos implementar auditorías regulares y aplicar el principio de menor privilegio en sistemas de IA. Prevenir para no lamentar.

Por último, se puede decir que los "enigmas" de la IA en ciberseguridad son los dilemas pendientes sobre cómo integrar esta tecnología de forma segura, equilibrada y responsable, sin darle a los atacantes una ventaja definitiva ni perder el control humano sobre la defensa.

Parámetro de seguridad/estabilidad con PNPM

Cristian Carrillo — Wed, 17 Sep 2025 21:03:41 +0000

Sabemos la problemática que hay actualmente con los ataques que han afectado de forma recurrente a los paquetes de NPM. No obstante, hay una forma de minimizar esta afectación en nuestros proyectos.

¡Ojo al dato y comparte! Te explico:👇🏽👀

Muchos trabajan con «npm», pero «pnpm» tiene una configuración que nos puede ayudar en estas instancias. PNPM implementó algo llamado «minimumReleaseAge» que se utiliza para evitar instalar versiones de dependencias que sean muy recientes.

Esto nos ayuda a reducir el riesgo de instalar paquetes comprometidos o maliciosos que hayan sido liberados hace poco. Ahora:

¿Cómo configurar «minimumReleaseAge» en pnpm? Te explico:

1️⃣ Se especifica la cantidad mínima de minutos que deben haber pasado desde que una versión de un paquete fue publicada, antes de que pnpm permita instalarla.

2️⃣ Esta configuración se puede definir en el archivo «pnpm-workspace.yaml» o en un archivo de configuración específico de pnpm.

3️⃣ Ejemplo: para evitar instalar versiones publicadas en los últimos 3 días (3 días = 3 * 24 * 60 = 4320 minutos):

minimumReleaseAge: 4320

4️⃣ Si necesitas excluir algunos paquetes para que siempre se pueda instalar su última versión sin esperar, tienes la configuración «minimumReleaseAgeExclude» donde puedes listarlos. ↓

Esto señalado anteriormente, permite que esas dependencias se instalen siempre a pesar del tiempo de publicación.

→ Resumen del archivo «pnpm-workspace.yaml» relevante. ↓

Con esta configuración, pnpm evitará instalar automáticamente versiones nuevas de dependencias que tengan menos de 3 días desde su publicación, ayudando a prevenir ataques mediante versiones comprometidas que suelen detectarse y eliminarse en el corto plazo.

⚠️ Importante: Esta funcionalidad está disponible desde pnpm versión 10.16.0 en adelante.

Esta forma de configuración aplicada en el entorno de trabajo orquesta las instalaciones, respetando esta política de seguridad frente a paquetes recién publicados.

Esta configuración ayuda principalmente a mejorar la seguridad de las instalaciones, pues muchas veces las versiones maliciosas o comprometidas son detectadas y eliminadas del registro poco después de su publicación.

Al retrasar la instalación de versiones nuevas, se reduce el riesgo de instalar paquetes potencialmente dañinos inmediatamente después de su lanzamiento.

=> Algunas recomendaciones para la configuración de minimumReleaseAge en proyectos npm con pnpm:

1440 minutos (1 día): Es un valor común para evitar instalar versiones recién publicadas que podrían ser maliciosas o no verificadas, dando tiempo para detección de problemas.

60 a 180 minutos (1 a 3 horas): Para proyectos que necesitan versiones nuevas relativamente rápido, pero aun con un mínimo de margen para seguridad.

0 minutos: En casos donde la prioridad sea, usar siempre la última versión sin demora, pero con mayor riesgo.

💻 Espero te haya servido esta información. ✊🏽😎