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

Dieses Repository enthält den Proof-of-Concept für CVE-2026-44590, eine Command Injection im GitHub-Actions-Workflow validate_modified_targets.yml von sherlock-project/sherlock. Jeder GitHub-Benutzer kann einen Pull Request eröffnen, der die Ausführung beliebiger Befehle im privilegierten CI-Kontext auslöst, das GITHUB_TOKEN des Workflows exfiltriert und den bösartigen PR automatisch genehmigt – alles ohne menschliche Interaktion.

Für den vollständigen technischen Bericht (Root-Cause-Analyse, Exploitation-Walkthrough, Auswirkungsanalyse und ein Kapitel darüber, was ein Angreifer in realen Szenarien tun könnte) siehe den Blogbeitrag:

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

Diese README konzentriert sich ausschließlich auf das PoC-Skript: was es tut, wie man es ausführt und was man erwarten kann.

Über poc.py

poc.py ist ein einzelnes, eigenständiges Python-Skript (nur stdlib), das die gesamte Angriffskette Ende-zu-Ende automatisiert:

• forkt sherlock-project/sherlock, falls nötig
• setzt (optional) den master-Zweig des Forks auf den Pre-Fix-Commit zurück, sodass der Fehler auch nach dem Upstream-Fix reproduziert werden kann
• startet einen OAST-Listener (interactsh-client)
• erstellt und pusht einen bösartigen PR-Zweig
• löst den verwundbaren Workflow aus
• extrahiert das GITHUB_TOKEN aus dem OAST-Callback (im --mode exfil) und dekodiert es im Klartext
• verwendet das gestohlene Token, um denselben PR über die GitHub-API automatisch zu genehmigen
• gibt ein klares Endurteil aus: VULNERABILITY CONFIRMED oder FIX VERIFIED
• räumt nach sich selbst auf (löscht den PoC-Zweig, beendet interactsh-client)

Es gibt genau einen manuellen Schritt (Klicken auf das „I understand my workflows"-Banner von GitHub beim ersten Mal pro Fork), da keine öffentliche API existiert, um es zu schließen. Das Skript erkennt diesen Fall und pausiert mit einer klaren Eingabeaufforderung.

Schnellstart

Überprüfen, ob der Upstream-Fix funktioniert (Standardverhalten)

Forkt das Repository (falls nötig), synchronisiert mit Upstream (gepatchter master), eröffnet einen bösartigen PR, führt die Angriffskette aus und meldet FIX VERIFIED, weil der gepatchte Workflow die Payload blockiert, bevor irgendein Shell-Befehl ausgeführt wird.

Die ursprüngliche Schwachstelle reproduzieren

Wie oben, setzt aber zuerst den master-Zweig des Forks auf den Pre-Fix-Commit (271608fb) zurück. Erwartetes Urteil: VULNERABILITY CONFIRMED.

Die volle Auswirkung demonstrieren (Token-Exfiltration + PR-Autogenehmigung)

Die Exfil-Payload gibt git config --list an den OAST aus und schläft 180 Sekunden, um den Workflow (und damit das GITHUB_TOKEN) am Leben zu halten. Während der Workflow schläft, extrahiert das Skript das Token aus dem OAST-Log, dekodiert es und ruft sofort die GitHub-API auf, um den PR zu genehmigen. Der PR wird am Ende von github-actions[bot] genehmigt.

Anforderungen

• Python 3.8+ (keine Drittanbieter-Abhängigkeiten, nur stdlib)
• gh (GitHub CLI), authentifiziert:
  root@kitploit:~

  gh auth login
  

• git
• interactsh-client (optional, aber empfohlen). Wenn installiert, startet das Skript ihn automatisch und verifiziert den Callback im Skript:
  root@kitploit:~

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

  Wenn du lieber deinen eigenen OAST-Endpunkt verwenden möchtest (Burp Collaborator, oast.fun über Web-UI, requestbin usw.), übergib ihn mit --oast-url und der Schritt der automatischen Verifizierung wird übersprungen.

Das Skript benötigt keinen bereits vorhandenen Fork, es erstellt automatisch einen.

Modi

--mode harmless (Standard)

Die Payload ist ein einzelner curl-POST mit einer statischen Bestätigungszeichenfolge. Es werden keine Geheimnisse gelesen, keine API-Aufrufe getätigt, der einzige Nebeneffekt ist der OAST-Callback. Verwende dies, um zu bestätigen, dass die Schwachstelle existiert, ohne irgendeine Anmeldeinformation preiszugeben.

--mode exfil

Die Payload gibt git config --list (das das base64-kodierte GITHUB_TOKEN unter http.https://github.com/.extraheader enthält) an den OAST aus und schläft dann 180 Sekunden. Das Skript führt dann Folgendes aus:

1. Pollt das OAST-Log, bis der Dump eintrifft.
2. Extrahiert den base64-Block mit einem Regex.
3. Dekodiert ihn und gibt die Anmeldeinformation im Klartext aus: x-access-token:ghs_XXXXXXXX....
4. Entfernt das Präfix x-access-token: und verwendet das rohe Token, um POST /repos/<fork>/pulls/<n>/reviews mit der Standard-Genehmigungs-Payload aufzurufen ({"event":"APPROVE","body":"All checks passed. LGTM!"}).
5. Der PR erscheint als von github-actions[bot] genehmigt, nicht unterscheidbar von legitimer CI-Automatisierung.

Sobald die Genehmigung aufgezeichnet ist, überspringt das Skript den Rest des 180-Sekunden-Schlafs des Workflows, da die Angriffskette abgeschlossen ist und das Warten auf den Timeout des Runners nichts hinzufügt.

Optionen

Warum der PR auf den Fork abzielt, nicht auf das Upstream-Repository

Absichtlich eröffnet der PoC den PR von einem Zweig auf dem Fork zum master desselben Forks. Er zielt nicht direkt auf sherlock-project/sherlock ab. Dafür gibt es zwei Gründe.

1. Vermeidung der öffentlichen Offenlegung eines Exploits

Ein Pull Request auf einem öffentlichen Repository ist für jeden sichtbar. Der Diff bleibt auch nach dem Schließen des PR indiziert, und die GitHub-Actions-Logs sind über die Web-UI zugänglich. Das Eröffnen eines PR mit einer funktionierenden Command-Injection-Payload auf dem Upstream-Repository würde effektiv einen funktionierenden Exploit veröffentlichen, bevor die Maintainer die Möglichkeit haben, einen Fix auszuliefern. Jeder, der das Repository beobachtet, könnte die Payload kopieren, den OAST-Callback gegen einen bösartigen Endpunkt austauschen und damit das echte GITHUB_TOKEN exfiltrieren.

Der PoC verwendet einen Fork-zu-Fork-PR, um den Exploit aus der öffentlichen Sicht zu halten und dennoch den Fehler Ende-zu-Ende zu demonstrieren.

2. Reproduktion des exakten verwundbaren Verhaltens

Wenn du sherlock-project/sherlock forkt, ist die Workflow-Datei validate_modified_targets.yml im Fork enthalten. Das Eröffnen eines PR, der auf den master des Forks abzielt, löst den Workflow im Kontext des Forks aus, mit einem GITHUB_TOKEN, das für den Fork ausgestellt wurde. Die Mechanik ist identisch mit dem ursprünglichen Angriff:

• Der pull_request_target-Trigger feuert automatisch
• Der Workflow läuft im Kontext des Basis-Repositorys (in diesem Fall des Forks)
• Der Workflow hat Zugriff auf sein eigenes GITHUB_TOKEN
• actions/checkout schreibt das Token über die Einstellung http.https://github.com/.extraheader in .git/config
• Die injizierte Payload kann das Token extrahieren oder verwenden

Der einzige Unterschied ist der Schadensradius: Das Token gehört dem Fork, nicht sherlock-project/sherlock. Die Schwachstelle wird reproduziert; die Auswirkung ist eingedämmt.

Der eine manuelle Schritt

GitHub deaktiviert Actions auf frisch erstellten Forks hinter einem UI-Banner:

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.

Es gibt keine öffentliche API, um dieses Banner zu schließen. Das Skript erkennt diesen Zustand (Fork wurde gerade erstellt ODER hat null historische Workflow-Runs) und pausiert mit einer klaren Eingabeaufforderung:

Nachdem das Banner einmal auf einem bestimmten Fork angeklickt wurde, wird das Skript bei nachfolgenden Läufen gegen denselben Fork nicht erneut auffordern.

Beispielausgabe (verwundbar, Exfil-Modus)

Beispielausgabe (gepatcht, Exfil-Modus)

Haftungsausschluss

Dieses Repository wird nur für Bildungs- und Sicherheitsforschungszwecke veröffentlicht. Die Schwachstelle wurde den Maintainern verantwortungsvoll offengelegt, im Upstream behoben und eine CVE wurde beantragt. Führe diesen PoC nicht gegen Repositorys aus, die dir nicht gehören oder für die du keine ausdrückliche Erlaubnis zum Testen hast. Der Autor ist nicht für Missbrauch verantwortlich.

Lizenz

MIT