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

Este repositório contém a prova de conceito para CVE-2026-44590, uma injeção de comandos no workflow validate_modified_targets.yml do GitHub Actions de sherlock-project/sherlock. Qualquer usuário do GitHub pode abrir um pull request que dispara a execução arbitrária de comandos no contexto privilegiado do CI, exfiltrar o GITHUB_TOKEN do workflow e auto-aprovar o PR malicioso, tudo sem qualquer interação humana.

Para o artigo técnico completo (análise de causa raiz, passo a passo da exploração, discussão de impacto e um capítulo sobre o que um atacante poderia fazer em cenários do mundo real), consulte o post do blog:

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

Este README foca exclusivamente no script PoC: o que ele faz, como executá-lo e o que esperar.

Sobre o poc.py

poc.py é um único script Python autocontido (apenas stdlib) que automatiza toda a cadeia de ataque de ponta a ponta:

• faz fork de sherlock-project/sherlock se necessário
• (opcionalmente) reverte o master do fork para o commit pré-correção para que o bug possa ser reproduzido mesmo após a correção upstream
• inicia um listener OAST (interactsh-client)
• cria e envia um branch de PR malicioso
• dispara o workflow vulnerável
• extrai o GITHUB_TOKEN do callback OAST (no --mode exfil) e o decodifica em texto claro
• usa o token roubado para auto-aprovar o mesmo PR via API do GitHub
• imprime um veredito final claro: VULNERABILITY CONFIRMED ou FIX VERIFIED
• faz a limpeza após a execução (exclui o branch do PoC, encerra o interactsh-client)

Existe exatamente um passo manual necessário (clicar no banner "I understand my workflows" do GitHub na primeira vez por fork), porque não existe API pública para dispensá-lo. O script detecta esse caso e pausa com um prompt claro.

Início rápido

Verificar se a correção upstream funciona (comportamento padrão)

Faz fork do repositório (se necessário), sincroniza com o upstream (master corrigido), abre um PR malicioso, executa a cadeia de ataque e reporta FIX VERIFIED porque o workflow corrigido bloqueia o payload antes que qualquer comando shell seja executado.

Reproduzir a vulnerabilidade original

Igual ao anterior, mas primeiro reverte o master do fork para o commit pré-correção (271608fb). Veredito esperado: VULNERABILITY CONFIRMED.

Demonstrar o impacto completo (exfiltração de token + auto-aprovação de PR)

O payload de exfiltração despeja git config --list no OAST e dorme por 180 segundos para manter o workflow (e, portanto, o GITHUB_TOKEN) ativo. Enquanto o workflow está dormindo, o script extrai o token do log OAST, o decodifica e imediatamente chama a API do GitHub para aprovar o PR. O PR termina aprovado por github-actions[bot].

Requisitos

• Python 3.8+ (sem dependências de terceiros, apenas stdlib)
• gh (GitHub CLI), autenticado:
  root@kitploit:~

  gh auth login
  

• git
• interactsh-client (opcional, mas recomendado). Quando instalado, o script o inicia automaticamente e verifica o callback dentro do próprio script:
  root@kitploit:~

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

  Se preferir usar seu próprio endpoint OAST (Burp Collaborator, oast.fun via interface web, requestbin, etc.), passe-o com --oast-url e a etapa de verificação automática será ignorada.

O script não exige que um fork exista previamente; ele cria um automaticamente.

Modos

--mode harmless (padrão)

O payload é um único POST curl com uma string de confirmação estática. Nenhum segredo é lido, nenhuma chamada de API é feita; o único efeito colateral é o callback OAST. Use isso para confirmar que a vulnerabilidade existe sem expor nenhuma credencial.

--mode exfil

O payload despeja git config --list (que contém o GITHUB_TOKEN codificado em base64 sob http.https://github.com/.extraheader) no OAST e depois dorme por 180 segundos. O script então:

1. Consulta o log OAST até o despejo chegar.
2. Extrai o blob base64 com uma regex.
3. Decodifica e imprime a credencial em texto claro: x-access-token:ghs_XXXXXXXX....
4. Remove o prefixo x-access-token: e usa o token bruto para chamar POST /repos/<fork>/pulls/<n>/reviews com o payload de aprovação padrão ({"event":"APPROVE","body":"All checks passed. LGTM!"}).
5. O PR aparece como aprovado por github-actions[bot], indistinguível de automação legítima de CI.

Uma vez registrada a aprovação, o script pula o restante do sono de 180 segundos do workflow, já que a cadeia de ataque está completa e esperar o runner expirar não acrescenta nada.

Opções

Por que o PR tem como alvo o fork, não o repositório upstream

Por design, o PoC abre o PR de um branch no fork para o master do mesmo fork. Ele não tem como alvo sherlock-project/sherlock diretamente. Há duas razões para isso.

1. Evitar a divulgação pública de um exploit

Um pull request em um repositório público é visível para qualquer pessoa. O diff permanece indexado mesmo após o PR ser fechado, e os logs do GitHub Actions são acessíveis pela interface web. Abrir um PR com um payload funcional de injeção de comandos no repositório upstream efetivamente publicaria um exploit funcional antes que os mantenedores tivessem a chance de lançar uma correção. Qualquer pessoa observando o repositório poderia copiar o payload, trocar o callback OAST por um endpoint malicioso e usá-lo para exfiltrar o GITHUB_TOKEN real.

O PoC usa um PR de fork para fork para manter o exploit fora da vista do público, enquanto ainda demonstra o bug de ponta a ponta.

2. Reproduzir o comportamento vulnerável exato

Quando você faz fork de sherlock-project/sherlock, o arquivo de workflow validate_modified_targets.yml é incluído no fork. Abrir um PR com alvo no master do fork dispara o workflow sob o contexto do fork, com um GITHUB_TOKEN emitido para o fork. A mecânica é idêntica ao ataque original:

• O gatilho pull_request_target dispara automaticamente
• O workflow é executado no contexto do repositório base (neste caso, o fork)
• O workflow tem acesso ao seu próprio GITHUB_TOKEN
• actions/checkout grava o token em .git/config via a configuração http.https://github.com/.extraheader
• O payload injetado pode extrair ou usar o token

A única diferença é o raio de impacto: o token pertence ao fork, não a sherlock-project/sherlock. A vulnerabilidade é reproduzida; o impacto é contido.

O único passo manual

O GitHub desativa o Actions em forks recém-criados atrás de um banner de interface:

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.

Não existe API pública para dispensar esse banner. O script detecta essa condição (fork recém-criado OU zero execuções históricas de workflow) e pausa com um prompt claro:

Depois de clicar no banner uma vez em um determinado fork, o script não solicitará novamente em execuções subsequentes contra o mesmo fork.

Exemplo de saída (vulnerável, modo exfil)

Exemplo de saída (corrigido, modo exfil)

Aviso legal

Este repositório é publicado apenas para fins educacionais e de pesquisa em segurança. A vulnerabilidade foi divulgada de forma responsável aos mantenedores, corrigida no upstream, e um CVE foi solicitado. Não execute este PoC contra repositórios que você não possui ou para os quais não tem permissão explícita de teste. O autor não é responsável por qualquer uso indevido.

Licença

MIT