Registro CVE: https://www.cve.org/CVERecord?id=CVE-2026-44590

Este repositorio contiene la prueba de concepto para CVE-2026-44590, una inyección de comandos en el flujo de trabajo validate_modified_targets.yml de GitHub Actions de sherlock-project/sherlock. Cualquier usuario de GitHub puede abrir una pull request que desencadena la ejecución arbitraria de comandos en el contexto privilegiado del CI, exfiltrar el GITHUB_TOKEN del flujo de trabajo y auto-aprobar la PR maliciosa, todo sin ninguna interacción humana.

Para el informe técnico completo (análisis de causa raíz, recorrido de explotación, discusión de impacto y un capítulo sobre lo que un atacante podría hacer en escenarios del mundo real), consulta la publicación del blog:

nstsec.com/en/posts/sherlock-rce-pull-request-target-cve-2026-44590

Este README se centra exclusivamente en el script PoC: qué hace, cómo ejecutarlo y qué esperar.

Acerca de poc.py

poc.py es un script de Python autónomo (solo stdlib) que automatiza toda la cadena de ataque de principio a fin:

• bifurca (fork) sherlock-project/sherlock si es necesario
• (opcionalmente) revierte el master del fork al commit anterior al fix para que el bug pueda reproducirse incluso después del fix upstream
• inicia un listener OAST (interactsh-client)
• crea y envía una rama de PR maliciosa
• desencadena el flujo de trabajo vulnerable
• extrae el GITHUB_TOKEN de la devolución de llamada OAST (en --mode exfil) y lo decodifica en texto claro
• usa el token robado para auto-aprobar la misma PR mediante la API de GitHub
• imprime un veredicto final claro: VULNERABILITY CONFIRMED o FIX VERIFIED
• limpia después de sí mismo (elimina la rama PoC, termina interactsh-client)

Hay exactamente un paso manual requerido (hacer clic en el banner "I understand my workflows" de GitHub la primera vez por fork), porque no existe una API pública para descartarlo. El script detecta este caso y se pausa con un aviso claro.

Inicio rápido

Verificar que el fix upstream funciona (comportamiento predeterminado)

Bifurca el repositorio (si es necesario), sincroniza con upstream (master parcheado), abre una PR maliciosa, ejecuta la cadena de ataque y reporta FIX VERIFIED porque el flujo de trabajo parcheado bloquea el payload antes de que se ejecute cualquier comando de shell.

Reproducir la vulnerabilidad original

Igual que arriba, pero primero revierte el master del fork al commit anterior al fix (271608fb). Veredicto esperado: VULNERABILITY CONFIRMED.

Demostrar el impacto completo (exfiltración de token + auto-aprobación de PR)

El payload de exfiltración vuelca git config --list al OAST y duerme durante 180 segundos para mantener vivo el flujo de trabajo (y por tanto el GITHUB_TOKEN). Mientras el flujo de trabajo duerme, el script extrae el token del registro OAST, lo decodifica e inmediatamente llama a la API de GitHub para aprobar la PR. La PR termina aprobada por github-actions[bot].

Requisitos

• Python 3.8+ (sin dependencias de terceros, solo stdlib)
• gh (GitHub CLI), autenticado:
  root@kitploit:~

  gh auth login
  

• git
• interactsh-client (opcional pero recomendado). Cuando está instalado, el script lo inicia automáticamente y verifica la devolución de llamada dentro del script:
  root@kitploit:~

  go install github.com/projectdiscovery/interactsh/cmd/interactsh-client@latest
  

  Si prefieres usar tu propio endpoint OAST (Burp Collaborator, oast.fun mediante interfaz web, requestbin, etc.), pásalo con --oast-url y se omitirá el paso de verificación automática.

El script no requiere que exista un fork de antemano, lo crea automáticamente.

Modos

--mode harmless (predeterminado)

El payload es un único curl POST con una cadena de confirmación estática. No se leen secretos, no se realizan llamadas a la API, el único efecto secundario es la devolución de llamada OAST. Úsalo para confirmar que la vulnerabilidad existe sin exponer ninguna credencial.

--mode exfil

El payload vuelca git config --list (que contiene el GITHUB_TOKEN codificado en base64 bajo http.https://github.com/.extraheader) al OAST, y luego duerme durante 180 segundos. El script entonces:

1. Consulta el registro OAST hasta que llega el volcado.
2. Extrae el blob base64 con una expresión regular.
3. Lo decodifica e imprime la credencial en texto claro: x-access-token:ghs_XXXXXXXX....
4. Elimina el prefijo x-access-token: y usa el token crudo para llamar a POST /repos/<fork>/pulls/<n>/reviews con el payload de aprobación estándar ({"event":"APPROVE","body":"All checks passed. LGTM!"}).
5. La PR aparece como aprobada por github-actions[bot], indistinguible de la automatización legítima del CI.

Una vez registrada la aprobación, el script omite el resto de los 180 segundos de sueño del flujo de trabajo, ya que la cadena de ataque está completa y esperar a que el runner agote el tiempo no añade nada.

Opciones

Por qué la PR apunta al fork, no al repositorio upstream

Por diseño, el PoC abre la PR desde una rama del fork hacia el master del mismo fork. No apunta directamente a sherlock-project/sherlock. Hay dos razones para esto.

1. Evitar la divulgación pública de un exploit

Una pull request en un repositorio público es visible para cualquiera. El diff permanece indexado incluso después de que la PR se cierre, y los registros de GitHub Actions son accesibles mediante la interfaz web. Abrir una PR con un payload funcional de inyección de comandos en el repositorio upstream publicaría efectivamente un exploit funcional antes de que los mantenedores tuvieran la oportunidad de lanzar un fix. Cualquiera que observara el repositorio podría copiar el payload, cambiar la devolución de llamada OAST por un endpoint malicioso y usarlo para exfiltrar el GITHUB_TOKEN real.

El PoC utiliza una PR de fork a fork para mantener el exploit fuera de la vista pública mientras demuestra el bug de principio a fin.

2. Reproducir el comportamiento vulnerable exacto

Cuando bifurcas sherlock-project/sherlock, el archivo de flujo de trabajo validate_modified_targets.yml se incluye en el fork. Abrir una PR dirigida al master del fork desencadena el flujo de trabajo bajo el contexto del fork, con un GITHUB_TOKEN emitido para el fork. La mecánica es idéntica al ataque original:

• El disparador pull_request_target se activa automáticamente
• El flujo de trabajo se ejecuta en el contexto del repositorio base (en este caso, el fork)
• El flujo de trabajo tiene acceso a su propio GITHUB_TOKEN
• actions/checkout escribe el token en .git/config mediante el ajuste http.https://github.com/.extraheader
• El payload inyectado puede extraer o usar el token

La única diferencia es el radio de explosión: el token pertenece al fork, no a sherlock-project/sherlock. La vulnerabilidad se reproduce; el impacto está contenido.

El único paso manual

GitHub desactiva Actions en forks recién creados detrás de un banner de interfaz:

Workflows aren't being run on this forked repository Because this repository contained workflow files when it was forked, we have disabled them from running on this fork. Make sure you understand the configured workflows and their expected usage before enabling Actions on this repository.

No existe una API pública para descartar este banner. El script detecta esta condición (fork recién creado O con cero ejecuciones históricas de flujos de trabajo) y se pausa con un aviso claro:

Después de hacer clic en el banner una vez en un fork determinado, el script no volverá a preguntar en ejecuciones posteriores contra el mismo fork.

Salida de ejemplo (vulnerable, modo exfil)

Salida de ejemplo (parcheado, modo exfil)

Aviso legal

Este repositorio se publica solo con fines educativos y de investigación en seguridad. La vulnerabilidad ha sido divulgada de manera responsable a los mantenedores, corregida en upstream, y se ha solicitado un CVE. No ejecutes este PoC contra repositorios que no poseas o para los que no tengas permiso explícito de prueba. El autor no es responsable de ningún uso indebido.

Licencia

MIT