GitHub No Fue Hackeado, Pero Tu Pipeline Sí Podría Serlo: Lo Que Revelan Grafana, CISA y Shai-Hulud 2.0

El 19 de mayo de 2026 no hackearon GitHub. github.com está operativo, todas sus métricas en verde. Pero en el mismo ciclo de noticias coincidieron tres incidentes que comparten una herida idéntica: tokens, credenciales y secretos abandonados en pipelines de CI/CD.

Grafana Labs perdió su codebase completo. CISA, la agencia de ciberseguridad de Estados Unidos, expuso contraseñas y llaves de nube en texto plano en un repo público. Y Shai-Hulud 2.0, un gusano que empezó en noviembre de 2025, ya infectó más de 30,000 repositorios y robó más de 500 credenciales de GitHub.

Tres historias. Un mismo patrón. El enemigo no está rompiendo la puerta. Está usando las llaves que dejamos en el felpudo.

1. Grafana Labs — Cómo un Token de GitHub Actions Entregó Todo el Codebase

Lo que pasó

Grafana Labs, la empresa detrás del popular stack de observabilidad open-source, reveló el 16 de mayo que un atacante obtuvo acceso a su entorno de GitHub y descargó su codebase privado completo. El grupo de extorsión CoinbaseCartel — un offshoot de ShinyHunters, Scattered Spider y LAPSUS$ — se adjudicó el ataque y exigió un rescate. Grafana se negó a pagar.

Cómo entraron

El vector fue quirúrgico. Los atacantes no reventaron contraseñas ni hicieron phishing. Explotaron una vulnerabilidad conocida como "Pwn Request" en GitHub Actions:

1. Encontraron un workflow con pull_request_target mal configurado. Este evento de GitHub Actions se ejecuta en el contexto del repositorio base — no del fork — y tiene acceso a secretos del repositorio original. Si no está sanitizado, cualquier persona puede hacer un fork, modificar el workflow y ejecutar código arbitrario con permisos privilegiados.




2. Hicieron fork de un repo público de Grafana y modificaron el workflow para inyectar un comando curl que exfiltraba variables de entorno a un archivo, cifrándolo con una clave privada del atacante.




3. Las variables de entorno contenían el token privilegiado. Un token de acceso a GitHub que permitía clonar repositorios privados. Una vez obtenido, replicaron el ataque contra otros cuatro repositorios internos y descargaron todo el codebase.




4. Borrado de huellas. Eliminaron el fork inmediatamente después del ataque.

Cómo lo detectaron

Grafana tenía canary tokens desplegados — señuelos que, al ser utilizados, disparan una alerta automática al equipo de seguridad. Uno de esos tokens se activó durante la exfiltración, y eso permitió contener el incidente rápidamente.

Lo que Grafana hizo bien

• Invalidó las credenciales comprometidas de inmediato.


• Eliminó el GitHub Action vulnerable.


• Deshabilitó todos los workflows en repositorios públicos.


• Fue transparente: comunicó el incidente en un hilo de X en menos de 48 horas.


• Siguió la guía del FBI: no pagó rescate.

2. CISA — La Agencia de Ciberseguridad de EEUU Expuso Sus Propias Llaves

La ironía es casi literaria. La Cybersecurity and Infrastructure Security Agency (CISA), responsable de proteger la infraestructura digital del gobierno estadounidense, expuso credenciales en texto plano en un repositorio público de GitHub.

Lo que pasó

Un contratista de CISA subió spreadsheets con contraseñas, llaves de AWS GovCloud, tokens de acceso y otros secretos a un repositorio accesible públicamente. El investigador Guillaume Valadon, de GitGuardian, los encontró antes que cualquier atacante. Probó algunas llaves — y eran válidas. Tenían acceso a sistemas de CISA y del Department of Homeland Security.

Valadon reportó el hallazgo al periodista Brian Krebs porque el contratista de CISA no respondió a las alertas de GitGuardian.

Lo que revela

Esto no fue un ataque sofisticado. Fue negligencia operativa básica: credenciales en archivos sin protección, en un repo sin controles de acceso, mantenido por un contratista externo sin supervisión. CISA — que emite guías de ciberseguridad para todo el gobierno federal — violó su propia primera regla.

CISA declaró que "no hay indicios de que datos sensibles hayan sido comprometidos." Pero el hecho de que las llaves estuvieran válidas cuando Valadon las encontró significa que la ventana de exposición fue real.

3. Shai-Hulud 2.0 — El Gusano Silencioso que Infectó 30,000 Repos

Lo que pasó

Shai-Hulud 2.0 es una campaña de malware de supply chain que comenzó en noviembre de 2025 y sigue activa. A mayo de 2026, Wiz Research rastrea:

• 30,000+ repositorios comprometidos


• 500+ credenciales de GitHub expuestas


• 60% de tokens npm robados aún válidos


• Paquetes maliciosos publicados bajo las cuentas legítimas de las víctimas

Cómo funciona

El gusano se propagó a través de paquetes npm maliciosos — especialmente @postman/[email protected] y @asyncapi/[email protected]. Una vez instalado en un runner de CI/CD (principalmente GitHub Actions), el malware:

1. 
   Escanea el entorno en busca de tokens de GitHub, npm, y credenciales cloud.


2. 
   Usa TruffleHog para extraer secretos de archivos.


3. 
   Crea repositorios públicos automáticamente bajo la cuenta de la víctima, llenos con datos robados.


4. 
   Se replica usando tokens de una víctima para infectar bajo la identidad de otra — lo que Wiz llama "cross-victim exfiltration". Esto hace que rastrear el origen sea extremadamente difícil.

El 77% de las infecciones ocurrieron en runners de CI/CD, no en máquinas de desarrolladores. Los entornos automatizados son el blanco porque son los que tienen acceso a secretos.

El Patrón: Tu Pipeline de CI/CD Es Tu Nuevo Perímetro de Seguridad

Pongamos los tres incidentes en perspectiva:

Tres vectores distintos. La misma vulnerabilidad raíz: el pipeline de CI/CD tiene acceso a secretos de producción y casi nadie lo está auditando con la misma disciplina que audita el código que corre en producción.

El pipeline es el nuevo perímetro. Y en la mayoría de las empresas, está desprotegido.

Checklist: ¿Está Expuesto Tu Pipeline?

Audita tus repositorios y workflows de GitHub Actions con estas preguntas. Si la respuesta a cualquiera es "no sé" o "no", hay un riesgo que atender:

1. ¿Usas pull_request_target en workflows públicos? Si la respuesta es sí, ¿está cada paso explícitamente sanitizado para no ejecutar código del fork? Si no puedes responder con certeza, deshabilítalo hasta auditarlo.




2. ¿Tus workflows públicos tienen acceso a secretos? Los workflows en repos públicos jamás deberían tener acceso a tokens que puedan clonar repos privados, publicar paquetes o modificar infraestructura. Usa ambientes separados con aprobación manual.




3. ¿Rotas tus secretos de CI/CD periódicamente? Un token que no rota es una llave maestra sin fecha de vencimiento. Si un token se filtró hace 6 meses, el hecho de que no haya pasado nada no significa que esté seguro — significa que el atacante no lo ha usado aún.




4. ¿Tienes detección de secretos en todos tus repos? GitGuardian, TruffleHog, GitHub Secret Scanning — usa al menos uno. Pero no solo escanees código fuente: escanea también issues, wikis, pull requests y GitHub Actions logs. Los secretos aparecen donde menos lo esperas.




5. ¿Has implementado canary tokens? La lección de Grafana: los canary tokens convierten un robo silencioso en una detección inmediata. Son baratos de implementar y no tienen falsos positivos — si se disparan, es real.




6. ¿Revisas las dependencias de tus workflows? Cada acción de terceros que usas en tu pipeline (actions/checkout, docker/login-action, etc.) es una superficie de ataque. Pinealas a un commit específico, no a una rama o tag mutable.




7. ¿Tus runners de CI/CD están aislados de producción? Un runner de CI no debería tener acceso de red a tus bases de datos de producción, clusters de Kubernetes o APIs internas. Si el runner se compromete, el daño debe estar contenido.




8. ¿Sabes qué tokens tiene cada colaborador externo? Los contratistas, freelancers y agencias externas son un vector de riesgo subestimado. CISA lo aprendió por las malas. Audita los permisos de cada colaborador externo con acceso a tus repos.

Cómo Guayoyo Tech Puede Ayudarte

En Guayoyo Tech no somos una empresa de ciberseguridad tradicional — y ese es justamente el punto. No te vendemos un SOC de $15,000 al mes. Te ayudamos con lo que realmente necesitas: blindar tus pipelines de desarrollo sin paralizar tu equipo.

Auditoría de Seguridad de GitHub Actions y CI/CD

• Revisamos todos tus workflows públicos y privados.


• Identificamos permisos excesivos, secretos mal gestionados y superficies de ataque como pull_request_target sin sanitizar.


• Entregamos un informe ejecutivo con acciones priorizadas — no un PDF de 200 páginas, sino lo que tienes que arreglar mañana.

Implementación de Detección Continua de Secretos

• Configuramos GitGuardian, GitHub Secret Scanning o TruffleHog en tus repos.


• Automatizamos alertas para que un secreto expuesto no sobreviva más de minutos.


• Integramos la detección en tu pipeline: si un commit contiene una credencial, el build falla.

Canary Tokens y Monitoreo de Integridad

• Desplegamos canary tokens en tus repositorios y entornos de CI/CD.


• Configuramos alertas automáticas cuando un token señuelo es accedido.


• Monitoreamos actividad anómala en tus workflows: ejecuciones desde forks no autorizados, cambios en variables de entorno, accesos fuera de horario.

Rotación Automatizada de Secretos

• Implementamos rotación periódica de tokens de GitHub, npm, Docker Hub y cloud providers.


• Integramos con HashiCorp Vault o GitHub Secrets Manager para que ningún secreto viva más de 90 días.

No necesitas ser Grafana para que te pase. Solo necesitas un token mal puesto en el lugar equivocado.

La diferencia entre Grafana y la mayoría de las empresas no es que ellos fueran más vulnerables — es que ellos tenían canary tokens y pudieron detectarlo. La mayoría de las empresas no se enteran hasta que el código ya está en un foro de extorsión.

En Guayoyo Tech auditamos pipelines de CI/CD y blindamos entornos de desarrollo. Sin vender miedo. Vendiendo prevención real.

Agenda una llamada de exploración gratuita. Revisamos tus workflows de GitHub Actions y te decimos exactamente qué arreglar, sin compromiso.