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

Questo repository contiene la proof-of-concept per CVE-2026-44590, un'iniezione di comandi nel workflow GitHub Actions validate_modified_targets.yml di sherlock-project/sherlock. Qualsiasi utente GitHub può aprire una pull request che innesca l'esecuzione arbitraria di comandi nel contesto CI privilegiato, esfiltrare il GITHUB_TOKEN del workflow e auto-approvare la PR dannosa, tutto senza alcuna interazione umana.

Per l'analisi tecnica completa (analisi della causa principale, walkthrough dello sfruttamento, discussione dell'impatto e un capitolo su cosa un attaccante potrebbe fare in scenari reali) consulta il post del blog:

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

Questo README si concentra esclusivamente sullo script PoC: cosa fa, come eseguirlo e cosa aspettarsi.

Informazioni su poc.py

poc.py è un singolo script Python autonomo (solo stdlib) che automatizza l'intera catena di attacco end-to-end:

• crea un fork di sherlock-project/sherlock se necessario
• (opzionalmente) riporta il ramo master del fork al commit pre-fix così il bug può essere riprodotto anche dopo il fix upstream
• avvia un listener OAST (interactsh-client)
• crea e pusha un ramo PR dannoso
• innesca il workflow vulnerabile
• estrae il GITHUB_TOKEN dal callback OAST (in --mode exfil) e lo decodifica in chiaro
• usa il token rubato per auto-approvare la stessa PR tramite l'API GitHub
• stampa un verdetto finale chiaro: VULNERABILITY CONFIRMED o FIX VERIFIED
• esegue la pulizia (elimina il ramo PoC, termina interactsh-client)

C'è esattamente un passaggio manuale richiesto (cliccare il banner "I understand my workflows" di GitHub la prima volta per ogni fork), perché non esiste un'API pubblica per eliminarlo. Lo script rileva questo caso e si mette in pausa con un prompt chiaro.

Avvio rapido

Verifica che il fix upstream funzioni (comportamento predefinito)

Crea il fork del repo (se necessario), sincronizza con upstream (master patchato), apre una PR dannosa, esegue la catena di attacco e riporta FIX VERIFIED perché il workflow patchato blocca il payload prima che qualsiasi comando shell venga eseguito.

Riproduci la vulnerabilità originale

Come sopra, ma prima riporta il ramo master del fork al commit pre-fix (271608fb). Verdetto atteso: VULNERABILITY CONFIRMED.

Dimostra l'impatto completo (esfiltrazione del token + auto-approvazione PR)

Il payload di esfiltrazione invia git config --list all'OAST e dorme per 180 secondi per mantenere vivo il workflow (e quindi il GITHUB_TOKEN). Mentre il workflow dorme, lo script estrae il token dal log OAST, lo decodifica e chiama immediatamente l'API GitHub per approvare la PR. La PR risulta approvata da github-actions[bot].

Requisiti

• Python 3.8+ (nessuna dipendenza di terze parti, solo stdlib)
• gh (GitHub CLI), autenticato:
  root@kitploit:~

  gh auth login
  

• git
• interactsh-client (opzionale ma consigliato). Quando installato, lo script lo avvia automaticamente e verifica il callback nello script:
  root@kitploit:~

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

  Se preferisci usare il tuo endpoint OAST (Burp Collaborator, oast.fun tramite web UI, requestbin, ecc.), passalo con --oast-url e il passaggio di verifica automatica verrà saltato.

Lo script non richiede che un fork esista già, lo crea automaticamente.

Modalità

--mode harmless (predefinita)

Il payload è una singola POST curl con una stringa di conferma statica. Nessun segreto viene letto, nessuna chiamata API viene effettuata, l'unico effetto collaterale è il callback OAST. Usa questa modalità per confermare che la vulnerabilità esiste senza esporre alcuna credenziale.

--mode exfil

Il payload invia git config --list (che contiene il GITHUB_TOKEN codificato in base64 sotto http.https://github.com/.extraheader) all'OAST, poi dorme per 180 secondi. Lo script quindi:

1. Interroga il log OAST finché non arriva il dump.
2. Estrae il blob base64 con una regex.
3. Lo decodifica e stampa la credenziale in chiaro: x-access-token:ghs_XXXXXXXX....
4. Rimuove il prefisso x-access-token: e usa il token grezzo per chiamare POST /repos/<fork>/pulls/<n>/reviews con il payload di approvazione standard ({"event":"APPROVE","body":"All checks passed. LGTM!"}).
5. La PR risulta approvata da github-actions[bot], indistinguibile dall'automazione CI legittima.

Una volta registrata l'approvazione, lo script salta il resto del sonno di 180 secondi del workflow, poiché la catena di attacco è completa e attendere il timeout del runner non aggiunge nulla.

Opzioni

Perché la PR punta al fork, non al repository upstream

Per progettazione, la PoC apre la PR da un ramo sul fork al master dello stesso fork. Non punta direttamente a sherlock-project/sherlock. Ci sono due ragioni per questo.

1. Evitare la divulgazione pubblica di un exploit

Una pull request su un repository pubblico è visibile a chiunque. Il diff rimane indicizzato anche dopo la chiusura della PR, e i log di GitHub Actions sono accessibili tramite la web UI. Aprire una PR con un payload funzionante di iniezione di comandi sul repository upstream pubblicherebbe di fatto un exploit funzionante prima che i maintainer avessero la possibilità di distribuire un fix. Chiunque osservasse il repository potrebbe copiare il payload, sostituire il callback OAST con un endpoint dannoso e usarlo per esfiltrare il vero GITHUB_TOKEN.

La PoC usa una PR fork-to-fork per mantenere l'exploit fuori dalla vista pubblica dimostrando comunque il bug end-to-end.

2. Riprodurre l'esatto comportamento vulnerabile

Quando crei un fork di sherlock-project/sherlock, il file del workflow validate_modified_targets.yml è incluso nel fork. Aprire una PR che punta al master del fork innesca il workflow nel contesto del fork, con un GITHUB_TOKEN emesso per il fork. I meccanismi sono identici all'attacco originale:

• Il trigger pull_request_target si attiva automaticamente
• Il workflow viene eseguito nel contesto del repository di base (in questo caso, il fork)
• Il workflow ha accesso al proprio GITHUB_TOKEN
• actions/checkout scrive il token in .git/config tramite l'impostazione http.https://github.com/.extraheader
• Il payload iniettato può estrarre o usare il token

L'unica differenza è il raggio d'esplosione: il token appartiene al fork, non a sherlock-project/sherlock. La vulnerabilità è riprodotta; l'impatto è contenuto.

L'unico passaggio manuale

GitHub disabilita le Actions sui fork appena creati dietro un banner UI:

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.

Non esiste nessuna API pubblica per eliminare questo banner. Lo script rileva questa condizione (fork appena creato OPPURE zero esecuzioni di workflow storiche) e si mette in pausa con un prompt chiaro:

Dopo aver cliccato il banner una volta su un dato fork, lo script non richiederà più il prompt nelle esecuzioni successive contro lo stesso fork.

Output di esempio (vulnerabile, modalità exfil)

Output di esempio (patchato, modalità exfil)

Disclaimer

Questo repository è pubblicato solo per scopi educativi e di ricerca sulla sicurezza. La vulnerabilità è stata divulgata responsabilmente ai maintainer, corretta in upstream, ed è stato richiesto un CVE. Non eseguire questa PoC contro repository che non possiedi o per cui non hai esplicita autorizzazione a testare. L'autore non è responsabile per qualsiasi uso improprio.

Licenza

MIT