En 2026, los mecanismos de confianza que construimos para proteger la cadena de software, SLSA provenance, code signing, CI/CD, se tornaron los vectores de ataque. En Tech86, acompañamos esa inversión en tiempo real: cada nuevo patrón de seguridad que la industria adoptó fue absorbido como superficie por los atacantes. El resultado fue una cadena de compromisos que en semanas alcanzó OpenAI, Mistral AI, Grafana Labs, Microsoft y el propio GitHub.
El año en que la provenancia engañó a todo el mundo
El 11 de mayo de 2026, el Mini Shai-Hulud publicó 84 versiones maliciosas en 42 paquetes @tanstack/* en 6 minutos. Todas con firma digital válida. Todas con provenancia SLSA Build Level 3. El CVE-2026-45321 recibió CVSS 9.6, y lo más alarmante es que la infraestructura de confianza funcionó exactamente como proyectada.
El atacante encadenó tres vulnerabilidades conocidas: un pull_request_target que ejecutaba código de fork externo con acceso al CI del repositorio base, cache poisoning cross-boundary que envenenó el pnpm store bajo la llave exacta del release workflow, y extracción del token OIDC de la memoria del runner vía dump de /proc/PID/mem. El step oficial de publish nunca ejecutó, la publicación maliciosa ya había ocurrido usando el token legítimo.
Sigstore, Fulcio CA y Rekor log confirmaron todo. La atestación SLSA registra correctamente que el paquete fue publicado por release.yml@refs/heads/main en TanStack/router. Lo que ella no codifica es qué step del workflow corrió npm publish. Provenancia no es seguridad. Es procedencia. El paquete vino de donde dice que vino, pero lo que estaba dentro era malware.
La cadena que nadie vio formándose
TanStack no fue un incidente aislado. Fue el punto cero. En horas, el worm se auto-propagó para 170+ paquetes en 19 namespaces incluyendo Mistral AI SDK, UiPath, OpenSearch y Guardrails AI. Con las credenciales robadas de un mantenedor del Nx Console, TeamPCP publicó la versión 18.95.0 de la extensión Nx Console en el VS Code Marketplace. Ventana de exposición: 18 minutos. Downloads oficiales: 28.
Uno de los devs con actualización automática activada trabajaba en GitHub. Con los tokens robados, el atacante enumeró y clonó 3.800 repositorios internos. Código propietario. Scripts de deploy. Configs de infra. Schemas de API interna. GitHub confirmó: "Las alegaciones actuales del atacante sobre ~3.800 repositorios son direccionalmente consistentes con nuestra investigación." El atacante listó los datos en el Breached forum por US$ 50 mil, después US$ 95 mil con supuesto partnership con Lapsus$.
La misma cadena derribó a Grafana. Rotacionaron tokens en masa, pero olvidaron uno. El CISO confirmó: "Un token olvidado permitió que los atacantes obtuvieran acceso a nuestros repositorios GitHub." Codebase privada robada. Rescate exigido. Grafana recusó, citando FBI. Microsoft fue alcanzada el mismo día, durabletask, SDK oficial, con 417 mil downloads/mes. Nueve días, cinco empresas de punta, una cadena.
Cuando las herramientas que leen código se tornan el ataque
La superficie de ataque cambió de forma fundamental. No es más solo el código. Son las herramientas que leen el código. El malware de los ataques de 2026 graba persistencia en dos lugares: .claude/settings.json vía hook SessionStart de Claude Code, y .vscode/tasks.json vía directiva folderOpen. Toda vez que un desarrollador abre el repositorio, el malware ejecuta. Sin prompt. Sin aprobación.
Los commits son autorizados como [email protected] con mensaje "chore: update dependencies", indistinguible de actividad normal de IA. Desinstalar el módulo no remueve el malware. Él persiste en las configuraciones de la IDE y del agente de IA. Quien clona el repositorio hereda la infección. En el caso del Nx Console, el atacante instaló gh-token-monitor vía systemd/launchctl que monitorea el token cada 60 segundos. Si detecta revocación, dispara recursive file deletion. El orden de remediación importa: remover persistencia ANTES de revocar tokens. Invertir es catastrófico.
El worm se auto-propaga entre ecosistemas. ¿Token npm con permiso de publish? El malware enumera paquetes de la víctima, inyecta el payload, republica con versión incrementada. ¿Credenciales PyPI en el ambiente? Salta para Python. Es el primer worm documentado que cruza de NPM para PyPI. En CI runners, lee /proc//mem de GitHub Actions para extraer secrets de la memoria del runner, bypaseando toda máscara de logs.
El ataque que no toca el código-fuente
El 22 de mayo, Laravel Lang, paquete de localización con 7.800 estrellas, tuvo todas sus 502 tags reescritas para apuntar a commits en forks controlados por el atacante. ~700 versiones envenenadas. El código ejecutaba en cada request PHP sin que nadie percibiera. La causa raíz: un PAT de miembro de la organización, probablemente del leak de GitHub, el mismo incidente de los 3.800 repos vía Nx Console.
La técnica es elegante y difícil de detectar. El atacante no modificó el código-fuente oficial. Ningún commit en el repositorio legítimo. Exploró una feature de GitHub: tags pueden apuntar a commits en forks, y Packagist resuelve esas tags como releases legítimas. composer install descargaba código del fork. Parecía legítimo. No era.
El payload usa autoload.files de Composer, todo archivo en esa lista corre en cada request PHP. Commands, workers, queues, cron, todo ejecuta el helpers.php. El C2 domain es construido en runtime vía array_map('chr', [...]) para evadir static scanners. El stealer tiene ~5.900 líneas de PHP, 15 módulos, es cross-platform. Roba cloud keys vía metadata 169.254.169.254, Kubernetes kubeconfig, Vault tokens, SSH keys, .env, docker-compose.yml, secrets.yaml, browser data, password managers, crypto wallets. En Windows, DebugChromium.exe roba App-Bound Encryption keys de Chrome/Brave/Edge. Todo cifrado con AES-256 y exfiltrado. Auto-se elimina después.
Pipelines: el nuevo blanco de escala
El 18 de mayo, Megalodon comprometió 5.561 repositorios GitHub con 5.718 commits maliciosos en 6 horas. Ningún código de aplicación fue modificado. El blanco era exclusivamente la capa de CI/CD, los workflows que corren dentro de cada repo.
Credenciales comprometidas, 33% de los usernames encontrados en logs de infostealers según análisis de threat intelligence, para pushear commits directos vía PAT. Identidades forjadas: build-bot, ci-bot, auto-ci con emails como [email protected]. Commit message: "ci: add build optimization step". Contenido: YAML en .github/workflows/. Ningún PR. Push directo para master.
Dos variantes. SysDiag: ejecución en masa con trigger en push + pull_request_target, que corre con secrets del repo base aun cuando el PR viene de fork externo. Optimize-Build: backdoor dormente que sustituye workflows por versiones con workflow_dispatch, activable vía GitHub API. Cero builds fallando. Cero logs sospechosos. Ambos piden id-token: write, el permiso que permite solicitar OIDC tokens para impersonar identidades en AWS, GCP y Azure sin credenciales persistentes.
El caso Tiledesk ilustra el problema: el mantenedor publicó versiones 2.18.6-2.18.12 en npm sin saber que el repo estaba comprometido. El backdoor estaba en la capa de CI/CD, invisible para code review y scanners que analizan apenas código-fuente. El atacante nunca tocó la cuenta npm. Comprometió el repositorio. El mantenedor publicó de la fuente envenenada.
Qué cambia a partir de ahora
En Tech86, la lección que sacamos de 2026 es clara: la defensa perimetral tradicional no alcanza la cadena de supply chain. WAF bloquea tráfico malicioso en el borde, pero no intercepta un npm install que ejecuta código con permisos de CI. Es por eso que combinamos Blindaje Perímetro WAF con monitoreo de integridad de pipelines, porque el ataque de hoy entra por el pipeline, no por la puerta de enfrente.
SLSA provenance necesita evolucionar para codificar qué step ejecutó qué acción, no apenas qué workflow. Cache de CI/CD necesita segregación obligatoria entre jobs de PR y jobs de release. Permisos de OIDC e id-token necesitan restricción explícita por job y por ambiente. Y la industria necesita aceptar que provenancia y seguridad son problemas diferentes. Mientras tratamos atestación de origen como garantía de seguridad, atacantes continuarán usando nuestra propia infraestructura de confianza contra nosotros.