> ## Content Index > Fetch the complete content index at: https://www.sredevops.org/llms.txt > Use this file to discover other available public pages before exploring further. # Vulnerabilidad alta en GitHub Actions: hackerbot-claw usa tu CI/CD como una plataforma de "pwn-as-a-service" - URL: https://www.sredevops.org/es/vulnerabilidad-alta-en-github-actions-hackerbot-claw-usa-tu-ci-cd-como-una-plataforma-de-pwn-as-a-service/ - Published: 2026-03-04T03:33:08.000Z - Updated: 2026-03-04T03:33:08.000Z - Description: Una campaña de ataque autónoma, rastreada como "hackerbot-claw", está acechando actualmente repositorios públicos. ¿Su misión? Encontrar workflows de GitHub Actions inseguros y convertirlos en puertas de enlace para la ejecución de código arbitrario y la exfiltración de credenciales. - Author: Nicolás Georger - Tags: Security, DevSecOps, Github, CI-CD, Pipelines, Español ## Resumen (Overview) Resulta que automatizar tus flujos de trabajo también hace que sea increíblemente fácil para los atacantes automatizar tu perdición. Una campaña de ataque autónoma, rastreada como **"hackerbot-claw"**, está acechando actualmente repositorios públicos. ¿Su misión? Encontrar workflows de GitHub Actions inseguros y convertirlos en puertas de enlace para la ejecución de código arbitrario y la exfiltración de credenciales. Esta campaña no es solo el proyecto de fin de semana de un *script-kiddie*; ha logrado comprometer con éxito varios proyectos de código abierto de alto perfil. Al abusar de configuraciones erróneas comunes, el bot efectivamente vuelve tu pipeline de CI/CD en tu contra. Si has estado tratando tus triggers de `pull_request_target` con la imprudencia de un desarrollador en su quinto café del día, es hora de prestar atención. La Linux Foundation y la OpenSSF están "triagiando" (triage) activamente las consecuencias, pero el bot trabaja más rápido que un comité. ## Anatomía del ataque El bot "hackerbot-claw" no está reinventando la rueda; simplemente está usando la rueda para pasarte por encima. Se dirige específicamente a workflows que: - Utilizan triggers privilegiados como `pull_request_target`. - Ejecutan código no confiable de *pull requests* (PRs) forkeados sin aislamiento. - Incluyen scripts de shell *inline* que confían ciegamente en inputs controlados por el usuario. - Carecen de cualquier forma de verificación de autorización antes de disparar *runners* costosos (y peligrosos). ### Patrones de ataque observados 1. **Inyección directa de scripts:** Los atacantes modifican un script dentro de un PR. Si el workflow ejecuta ese script con privilegios del repositorio, el atacante efectivamente se adueña del *runner*. 2. **"Pwn request" (abuso de `pull_request_target`):** Este trigger es el "Modo Dios" de GitHub Actions. Cuando se usa para hacer *checkout* y ejecutar código desde un *fork*, otorga a ese código no confiable acceso a secretos y a un `GITHUB_TOKEN` con permisos de escritura. 3. **Inyección de contexto:** Los *payloads* maliciosos se ocultan en nombres de ramas, títulos de PR o rutas de archivos. Si tu workflow hace algo como `echo "Checking out ${{ github.head_ref }}"`, podrías encontrarte ejecutando `echo "Checking out "; rm -rf / #`. ### Una víctima del mundo real: project-akri/akri En un caso documentado que involucró a `project-akri/akri`, un PR malicioso introdujo un *payload* de inyección de shell en un script. Debido a que el workflow carecía de salvaguardas, ejecutó obedientemente los comandos del atacante, demostrando una vez más que las computadoras harán exactamente lo que les digas, incluso si es un suicidio profesional. ## Mitigaciones recomendadas Si no quieres que tu repositorio se convierta en un minero de criptomonedas para alguien más o en un punto de pivote para un ataque a la cadena de suministro, implementa estos controles de inmediato. ### 1\. Refuerza (harden) tus workflows Deja de usar `pull_request_target` a menos que sea absolutamente necesario. Si debes usarlo, **nunca** hagas *checkout* del código no confiable desde el *head* del PR. ```yaml # MAL: Esto le da al código del fork acceso a tus secretos on: pull_request_target jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: ref: ${{ github.event.pull_request.head.sha }} # PELIGRO ``` ### 2\. Aplica el principio de menor privilegio Limita los permisos del `GITHUB_TOKEN` en la parte superior de tu archivo de workflow. Si un *job* solo necesita leer el código, indícalo explícitamente. ```yaml permissions: contents: read pull-requests: read ``` ### 3\. Sanitiza los inputs como si tu vida dependiera de ello Nunca interpoles variables de contexto de GitHub directamente en scripts de shell. Usa variables de entorno en su lugar. ```yaml # MAL: Vulnerable a inyección run: echo "Procesando rama: ${{ github.head_ref }}" # BIEN: Manejado como datos, no como código run: echo "Procesando rama: $BRANCH_NAME" env: BRANCH_NAME: ${{ github.head_ref }} ``` ### 4\. Pinnea tus actions No confíes en etiquetas (tags) como `@v1`. Los tags pueden ser movidos. Usa el SHA completo del commit para asegurar que el código que estás ejecutando es el código que revisaste. ```yaml - uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608 # v4.1.0 ``` ## Alineación con el OpenSSF OSPS Baseline La campaña actual "hackerbot-claw" apunta exactamente a las brechas abordadas por el [OpenSSF OSPS (Open Source Project Security) Baseline](https://best.openssf.org/SCM-BestPractices?ref=sredevops.org). Los proyectos que siguen estas pautas son significativamente más difíciles de comprometer. - **Menor Privilegio:** Restringir el `GITHUB_TOKEN` y usar OIDC para credenciales de nube de corta duración. - **CI/CD Protegido:** Requerir la aprobación de un mantenedor para todos los colaboradores primerizos antes de que se ejecuten los workflows. - **Revisión por Pares:** Usar `CODEOWNERS` para exigir que cualquier cambio en `.github/workflows/` sea revisado por un humano consciente de la seguridad, no solo por un mantenedor cansado. ## Lecturas adicionales y recursos - [Guía oficial de GitHub sobre inyección de scripts](https://docs.github.com/en/actions/concepts/security/script-injections?ref=sredevops.org) - [OpenSSF: Mitigando vectores de ataque en workflows de GitHub](https://openssf.org/blog/2024/08/12/mitigating-attack-vectors-in-github-workflows?ref=sredevops.org) - [Wiz.io: Guía de seguridad de GitHub Actions](https://www.wiz.io/blog/github-actions-security-guide?ref=sredevops.org) - [Mejores prácticas de OpenSSF SCM](https://best.openssf.org/SCM-BestPractices?ref=sredevops.org) --- **Fuente:** Christopher "CRob" Robinson, Chief Technology Officer & Chief Security Architect en OpenSSF / The Linux Foundation. [GitHub](https://github.com/SecurityCRob?ref=sredevops.org) | [LinkedIn](https://www.linkedin.com/in/darthcrob?ref=sredevops.org)