Home Depot und der „ein Jahr offene Seiteneingang“: Wie ein geleakter GitHub-Token interne Systeme angreifbar machte
Der Moment, in dem ein einzelner String gefährlicher wird als ein Exploit
Es gibt Cybervorfälle, die nach High-Tech klingen: Zero-Days, Supply-Chain-Injektionen, Kernel-RCE. Und dann gibt es jene, die unangenehm banal sind – gerade deshalb aber so lehrreich. Der Fall Home Depot gehört in diese zweite Kategorie. Kein ausgeklügeltes Malware-Framework, kein raffinierter Umgehungsmechanismus, kein „State Actor“-Narrativ. Stattdessen: ein öffentlich einsehbarer GitHub-Access-Token, der über Monate im Internet verfügbar war – und damit potenziell als Schlüssel zu internen Entwicklungs- und Infrastrukturressourcen diente.
Was diesen Vorfall besonders macht, ist nicht nur die technische Fehlkonfiguration, sondern das Zusammenspiel aus drei Dingen:
- Ein technisches Grundversäumnis (Token-Leak mit weitreichenden Berechtigungen)
- Ein organisatorisches Grundversäumnis (Hinweise eines Security-Researchers bleiben unbeantwortet)
- Ein strukturelles Grundproblem moderner IT (Non-Human Identities und „Secret Sprawl“: Schlüssel sind heute überall)
Wer diesen Fall nur als „peinlichen Ausrutscher“ abtut, übersieht den Kern: In vielen Unternehmen ist ein Token heute die kürzeste Strecke von „Public Internet“ zu „Production Adjacent“.
Was passiert ist – in klaren Worten
Ein Security-Researcher fand einen GitHub-Access-Token, der einem Mitarbeiter von Home Depot zugeordnet war. Der Token war offenbar seit Anfang 2024 öffentlich auffindbar und bot Zugriff auf Hunderte private Repositories. Der Researcher berichtete außerdem, dass der Token Schreibrechte hatte – also nicht nur „lesen“, sondern potenziell Änderungen an Code und Artefakten erlaubte.
Noch brisanter: In der Berichterstattung ist von Repositories und Systembezügen die Rede, die in Richtung Cloud-Infrastruktur, Order-Fulfillment, Inventory Management und Dev-Pipelines zeigen. Das sind nicht „nice-to-have“-Repos, sondern Bereiche, die – je nach Kopplungsgrad – direkten Einfluss auf Deployment und Betriebsrealität haben können.
Als der Researcher versuchte, Home Depot zu warnen, blieb eine Reaktion zunächst aus. Erst nachdem Medien (insbesondere TechCrunch) involviert waren, wurde der Token nach Angaben in der Berichterstattung im Dezember 2025 widerrufen und die Exposition beendet.
Warum ein GitHub-Token so gefährlich ist
Tokens sind „Non-Human Identities“ – und die werden oft zu großzügig behandelt
In klassischen Sicherheitsmodellen dreht sich vieles um Nutzerkonten: MFA, Passwortregeln, SSO, Conditional Access. Tokens funktionieren anders. Sie sind häufig:
- langlebig
- automatisiert genutzt (CI/CD, Scripts, Integrationen)
- breit berechtigt (weil „es sonst nicht funktioniert“)
- schlecht inventarisiert (weil sie nicht wie Benutzerkonten „sichtbar“ sind)
Damit werden Tokens zu einer Art Schattenidentität. Sie hängen an Prozessen, nicht an Menschen – und genau deshalb bleiben sie lange unbemerkt, wenn sie kompromittiert sind.
Ein Token ist nicht „nur Code-Zugriff“
Viele Organisationen unterschätzen, was Code-Zugriff in 2025 tatsächlich bedeutet. In modernen Delivery-Ketten ist Source Code oft eng verzahnt mit:
- Build- und Release-Workflows (Pipelines, Actions, Runner)
- Infrastruktur-as-Code (Terraform, CloudFormation, Helm)
- Secrets- und Konfigurationsartefakten (ENV-Files, Vault-Refs, CI-Variablen)
- Deployment-Mechaniken (Container registries, image tags, rollout configs)
Wenn ein Token Schreibrechte auf Repos hat, ist das ein potenzieller Supply-Chain-Hebel: Ein Angreifer muss nicht „das Rechenzentrum hacken“, er muss nur den Weg finden, wie Code in Artefakte und Artefakte in Produktion gelangen.
Die eigentliche Cyberpanne: Nicht nur der Leak – sondern das „Ignorieren der Alarmklingel“
Wenn ein Researcher einen Token findet und versucht, das Unternehmen zu informieren, ist das keine Störung, sondern ein kostenloses Frühwarnsystem. Dass die Meldung offenbar über Wochen ohne klare Antwort blieb, ist im Kontext von Secrets besonders kritisch.
Warum? Weil bei geleakten Tokens nicht die Frage lautet „Wird jemand das nutzen?“, sondern „Wie oft wurde es bereits genutzt, ohne dass wir es sehen?“.
In dieser Vorfallklasse ist Zeit eine operative Währung:
- Jeder Tag ohne Rotation erhöht die Wahrscheinlichkeit, dass der Token kopiert wird.
- Jede Woche ohne Forensik erhöht die Unsicherheit, ob der Token bereits Teil von Angriffsketten wurde.
- Jeder Monat ohne Disclosure-Prozess erhöht die Wahrscheinlichkeit, dass der nächste Researcher nicht mehr meldet, sondern veröffentlicht.
Wo typischerweise die Kontrollkette reißt
Der Home-Depot-Fall ist eine konzentrierte Demonstration der Stellen, an denen große Organisationen trotz Security-Programme verwundbar bleiben. Meist sind es nicht „fehlende Tools“, sondern fehlende Konsequenz in vier Bereichen.
Secret Hygiene: „Es war bestimmt nur ein Versehen“
Ja, es ist oft ein Versehen. Aber Versehen sind planbar. Ein reifer Prozess verhindert, dass Versehen produktiv werden.
Typische Lücken:
- Kein konsequentes Secret Scanning auf allen Repos (auch Private, auch Legacy, auch Forks)
- Keine Push-Protection (die bereits beim Commit blockt)
- Entwickler nutzen Tokens mit zu breiten Scopes, weil es schneller geht
- Tokens laufen nicht zeitnah ab (oder „nie“)
Least Privilege: „Wir geben lieber zu viel, dann funktioniert es“
Das ist der Klassiker. Funktionalität wird zum Totschlagargument. Ergebnis: Tokens mit Schreibrechten und weitreichenden Repo-/Workflow-Rechten werden zur Norm.
Monitoring: „Wir hätten es doch sehen müssen“
Viele Unternehmen haben Logging – aber nicht die richtigen Alarmmodelle. Ein Token, der plötzlich von ungewöhnlichen IPs genutzt wird, oder in kurzer Zeit ungewöhnlich viele Repos anspricht, sollte auffallen. In der Praxis fehlt oft:
- Baseline-Verständnis („was ist normales Token-Verhalten?“)
- Anomalieerkennung für Non-Human Identitäten
- schnelle Rotation plus Incident-Playbook für Secrets
Responsible Disclosure: „Wir haben keine offizielle Eingangstür“
Wenn ein Unternehmen keinen klaren, verlässlichen Prozess hat, landen Warnungen irgendwo zwischen Info@, Supportformularen und einzelnen Mitarbeiterpostfächern. Das führt zu einem gefährlichen Zustand: Sicherheitsmeldungen werden wie Kundenanfragen behandelt – und verlieren Priorität.
Was ein Angreifer realistisch hätte tun können (ohne Hollywood)
Ein Token mit Repo-Zugriff und Schreibrechten eröffnet typischerweise mehrere realistische Pfade. Nicht jeder Pfad muss eingetreten sein – aber jeder Pfad ist plausibel genug, um ihn in Threat-Modeling und Incident Response ernst zu nehmen.
Mögliche Missbrauchsoptionen
- Code-Exfiltration: interne Repos kopieren, um Architektur, Endpunkte, Integrationen und Schwachstellen zu kartieren
- Credential Harvesting: nach weiteren Secrets in Code, Configs, CI-Files suchen
- Build-/Pipeline-Manipulation: kleine Änderungen in Build-Skripten platzieren, die später Artefakte beeinflussen
- Dependency- oder Update-Tampering: „unauffällige“ Änderungen, die erst Wochen später Wirkung zeigen
- Ransomware-Vorbereitung: Wissensaufbau, Identifikation kritischer Systeme, Vorbereitung lateraler Schritte
Das ist der Punkt, an dem „nur ein Token“ in den Bereich echter Business-Risiken kippt.
Was Unternehmen daraus konkret lernen sollten
Sofort wirksame technische Maßnahmen
Secret Scanning und Push Protection verpflichtend machen
- auf allen Repositories
- auch für private Repos
- mit klaren Policies, was blockiert wird und was nur warnt
Tokens radikal verkürzen und granularisieren
- kurze Laufzeiten statt „langlebig“
- Fine-grained Tokens statt Classic Tokens
- minimale Scopes
- Schreibrechte nur, wenn nachweislich nötig
CI/CD modernisieren
- wo möglich auf kurzlebige, Workload-basierte Authentisierung umstellen (weniger „statische Secrets“)
- Runner und Pipelines als eigene Hochrisiko-Zone behandeln
Monitoring für Non-Human Identities
- Alarm, wenn Tokens ungewöhnlich viele Repos ansprechen
- Alarm, wenn Tokens von neuen Regionen/IP-Bereichen genutzt werden
- Alerting bei massenhaften Clone-/Archive-Aktionen
Organisatorische Maßnahmen, die den Unterschied machen
Eine echte Vulnerability-Intake-Struktur
- klarer Kontaktweg (nicht „Support“)
- definierte SLA für Erstreaktion
- triagefähiges Team
Disclosure-Kultur statt Abwehrhaltung
- Researcher-Hinweise als Signal behandeln, nicht als Störung
- interne Prozesse so bauen, dass Rotation/Investigation sofort startet
Incident Playbook für Secrets
- Token-Revoke + Rotation als Standard
- parallele Forensik: welche Systeme wurden berührt, welche Repos, welche Aktivitäten
- Kommunikation intern und extern: transparent, ohne Spekulation
