GitHub Zugangsdaten: 543.699 gültige Secrets in öffentlichen Repos

GitHub Zugangsdaten in öffentlichem Code sind kein neues Thema – neu ist die Größenordnung. Truffle Security hat 224 Millionen öffentliche GitHub-Repositories durchsucht und 543.699 datierbare Zugangsdaten gefunden, die im Juli 2026 beim jeweiligen Anbieter noch funktionierten. Der Befund vom 29. September 2026 ist unangenehm präzise: Das Problem ist nicht das Hochladen. Das Problem ist, dass niemand die Schlüssel zurückzieht.

Die Zahlen hinter den GitHub Zugangsdaten

Grundlage ist „The Stack v3″, ein für das Training von Sprachmodellen zusammengestellter Abzug öffentlichen Codes: 224.553.295 Repositories und über 58 Milliarden Dateien, Crawl-Ende 7. August 2025. Am 27. und 28. Juli 2026 prüften die Forscher jeden Kandidaten gegen den ausgebenden Dienst. Ergebnis:

• 543.699 eindeutige, noch gültige und datierbare Zugangsdaten – verteilt auf 1.103.438 einzelne Fundstellen inklusive Forks. Insgesamt verifizierte der Scan 544.069 gültige Schlüssel; 543.699 davon ließen sich einer Datei mit brauchbarem Datum zuordnen.
• 784 Tage Medianalter, gemessen von der letzten Änderung der Datei bis zur Prüfung.
• 6,3 Jahre beim 90. Perzentil; die älteste noch funktionierende Zugangsdaten-Kombination steckt in einer Datei, die zuletzt am 13. Juni 2009 geändert wurde – 16,1 Jahre später war sie noch gültig. Ein Commit-Datum kennt der Datensatz nicht.
• Mehr als das Doppelte der 221.303 gültigen Schlüssel, die dasselbe Team im August in Hugging-Face-Trainingsdaten fand.

Die Dichte steigt zudem: von 3,72 gültigen Zugangsdaten je Million Dateien im Jahr 2014 auf 11,62 im Jahr 2025 – der höchste Wert im gesamten Datensatz. 2025 deckt dabei nur sieben Monate bis zum Crawl-Ende ab, weshalb nur die Dichte je Million Dateien vergleichbar ist, nicht die Rohzahl.

AD-Checkliste

Dein AD härten: 12 Sofortmaßnahmen

Das PDF mit Bordmitteln, PowerShell-Prüfbefehlen und 30-Tage-Reihenfolge – per Mail, sobald du deine Anmeldung zum Tech-&-Tacheles-Newsletter bestätigst.

E-Mail-Adresse *

Mit der Anmeldung erhältst du die AD-Checkliste als PDF und danach den Tech-&-Tacheles-Newsletter mit Einordnungen zu Security, KI und Crypto sowie gelegentlichen Hinweisen auf meine Bücher und Produktempfehlungen (auch Affiliate-Links) – eingetragen bist du erst nach Klick auf den Bestätigungslink in der E-Mail (Double-Opt-in). Abmeldung jederzeit über den Link in jeder E-Mail, Details in der Datenschutzerklärung.

Push Protection wirkt an der Tür, nicht dahinter

GitHub kündigte am 29. Februar 2024 an, Pushes in öffentliche Repos künftig standardmäßig zu blockieren, wenn ein erkanntes Secret enthalten ist, und begann noch in derselben Woche einen gestaffelten Rollout. Das wirkt messbar: Im Fenster von zwölf Monaten um den Rollout fiel die Leak-Rate bei den abgedeckten Mustern um 53 Prozent, bei den nicht abgedeckten nur um 7 Prozent. Die Studie bezeichnet die 53 Prozent selbst als Untergrenze, weil generische Muster pro Organisation einschaltbar sind und die Kontrollgruppe damit teils mitbehandelt war. Trotzdem stammen 199.843 der gefundenen gültigen Zugangsdaten – rund 36,8 Prozent – aus der Zeit nach dieser Umstellung.

Der Grund ist die Mustererkennung. Blockiert werden Anbieter-Token mit eindeutigem Präfix. Nicht blockiert werden standardmäßig Datenbank-Verbindungsstrings, private Schlüssel und Google-API-Keys. Zusammen sind das 51,8 Prozent aller gefundenen gültigen Zugangsdaten. Besonders deutlich wird es bei Google: Ein Gemini-API-Key ist eine abrechenbare Zugangsdatei, ein Maps-Key mit identischem AIzaSy-Präfix gehört in jede Webseite. Ein Muster kann beides nicht unterscheiden – also wird nichts blockiert. Truffle fand 31.374 gültige Gemini-Keys.

Was das für dich bedeutet

Die eigentliche Lehre dieses Berichts steckt nicht in der Rekordzahl, sondern in einem Vergleich, den man leicht überliest. Gemessen an den strukturell eindeutigen Treffern – Anbieter-Präfix, Verbindungsstring mit Passwort, Service-Account-JSON – funktionierte von 101.886 npm-Tokens genau eines noch. Von 126.963 Google-Cloud-Service-Account-Schlüsseln funktionierten 69.041. Bei Postgres-Verbindungsstrings waren 11.465 von 12.985 noch aktiv. Der Unterschied liegt nicht am Entwickler und nicht an GitHub – sondern daran, ob der Anbieter geleakte Schlüssel automatisch ungültig macht. npm und GitHub tun das. Eine Datenbank-URL zieht niemand zurück.

Aus Identity-Sicht ist das ein alter Bekannter in neuem Gewand. Der Schaden entsteht nicht durch das Bekanntwerden eines Geheimnisses, sondern durch seine unbegrenzte Lebensdauer. Die Studie stellt Push Protection deshalb ausdrücklich nicht in Frage: Der Block hält Secrets an der Tür auf, er hat nur nichts über die halbe Million zu sagen, die schon drin ist. Genau deshalb ist die Diskussion „Wie verhindern wir, dass Secrets in Git landen?“ nur die halbe Aufgabe. Die andere Hälfte lautet: Wie kurz lebt ein Secret, und wer kann es in Minuten abschalten? Ein Passwort ohne Ablaufdatum ist in einem Repository dasselbe wie in einem Active Directory – eine dauerhaft offene Tür, die niemand mehr auf dem Radar hat.

Zwei Einschränkungen gehören zur Fairness dazu. Erstens ist der Datensatz ein Abzug von 2025 mit nur einem Branch pro Repository; alles, was per Force-Push verschwand, ist unsichtbar – die echte Zahl dürfte höher liegen. Zweitens sagt die Studie ausdrücklich nicht, welcher Anteil dieser Schlüssel tatsächlich von Angreifern missbraucht wurde. Das ist kein Grund zur Entspannung, aber ein Grund, nüchtern zu bleiben.

Konkrete Schritte für dein eigenes Repo

• Erst rotieren, dann aufräumen: Ein einmal committetes Secret gilt als verbrannt – auch wenn nichts Alarm geschlagen hat. Die History zu putzen ist Schritt zwei, nicht Schritt eins.
• Eigene History scannen: Alles, was vor Februar 2024 committet wurde, war für die Push-Blockade nie im Blick. Open-Source-Scanner wie TruffleHog oder Gitleaks laufen über die komplette Historie, nicht nur über den aktuellen Stand.
• Ablaufdatum erzwingen: Kurzlebige Tokens oder Workload Identity statt statischer Keys. Der größte Teil der gefundenen Zugangsdaten wäre harmlos verfallen, hätte er überhaupt eine Lebensdauer gehabt.
• Generische Muster aktivieren: Verbindungsstrings und private Schlüssel blockiert GitHub nur, wenn eine Organisation das bewusst einschaltet. Genau dort liegt über die Hälfte des Problems.
• Anbieter prüfen: Nimmt dein Dienst am Revocation-Programm teil? Erkennung ohne Sperrung lässt den Schlüssel funktionsfähig.

Für persönliche Konten gilt derselbe Gedanke eine Ebene höher: Ein geleakter Token nützt Angreifern vor allem dann, wenn danach kein zweiter Faktor kommt. Wer seine Entwickler- und Admin-Zugänge mit einem Hardware-Security-Key nach FIDO2 absichert, nimmt einem gestohlenen Geheimnis einen großen Teil seiner Wirkung. Und wer wissen will, wie schnell aus einem offenen Schlüssel ein echter Zugriff wird, findet den Mechanismus im Fall Langflow sauber dokumentiert.

Quellen

• Truffle Security: GitHub Repos Exposed 543,699 Credentials. Nobody Revoked Them. (29.09.2026)
• BleepingComputer: Over 543,000 valid credentials exposed in public GitHub repositories (30.09.2026)
• GitHub Docs: Supported secret scanning patterns