GitHub-Repos legen über 543.000 gültige Zugangsdaten offen

Öffentliche GitHub-Repositories enthalten noch immer Hunderttausende funktionierende Geheimnisse, obwohl die Plattform Werkzeuge eingeführt hat, die versehentliche Lecks verhindern sollen. Eine neue Analyse von Truffle Security fand 543.699 eindeutige Zugangsdaten, die im Juli noch gültig waren.

Die Forscher durchsuchten 224 Millionen Repositories und mehr als 58 Milliarden Dateien. Dabei stellten sie fest, dass ein typisches geleaktes Zugangsdatum im Median 784 Tage lang öffentlich zugänglich blieb, bevor jemand es bemerkte oder handelte.

Bemerkenswert ist das Alter mancher dieser Geheimnisse. Rund 10 % der funktionierenden Zugangsdaten waren älter als 6,3 Jahre, das älteste noch gültige stammt aus dem Jahr 2009. Die 543.699 eindeutigen Geheimnisse tauchten immer wieder in mehr als 1,1 Millionen Dateien und Repositories auf, darunter auch als Kopien in Forks.

Woher die Daten stammen

Für diese Studie hat Truffle Security GitHub nicht selbst durchsucht. Das Unternehmen arbeitete mit einem Datensatz, der zum Training großer Sprachmodelle erstellt wurde und auf einem Crawl basiert, der am 7. August 2025 endete.

Die Zahl für GitHub ist mehr als doppelt so hoch wie das, was dasselbe Team im August bei der Untersuchung von Hugging Face fand. Dort wurden 221.303 funktionierende Zugangsdaten entdeckt.

Die Untersuchung zeigt außerdem, dass Geheimnisse immer häufiger im Code auftauchen. Die Zahl funktionierender Zugangsdaten stieg von 3,72 pro Million Dateien im Jahr 2015 auf einen Höchstwert von 11,62 pro Million Dateien im Jahr 2025.

Push Protection hilft, aber nur begrenzt

GitHubs wichtigster Schutz gegen dieses Problem ist Push Protection. Die Funktion stand ab April 2022 zunächst Kunden von Advanced Security zur Verfügung, wurde im Mai 2023 auf öffentliche Repositories ausgeweitet und später standardmäßig aktiviert.

Die Funktion prüft eingehenden Code auf Muster von Geheimnissen wie API-Schlüssel und Zugriffstoken und blockiert den Push, wenn sie einen Treffer findet. Zugangsdaten, die bereits vor ihrem Eingreifen offengelegt wurden, widerruft sie jedoch nicht.

Laut Truffle Security wurden 199.843 der aktiven Zugangsdaten, also etwa 36,8 % der Gesamtzahl, offengelegt, nachdem GitHub Push Protection im Februar 2024 für alle Nutzer eingeschaltet hatte.

Etwas mehr als die Hälfte (51,8 %) der funktionierenden Geheimnisse gehörte zu Kategorien, die Push Protection in der Standardeinstellung nicht blockiert. Dazu zählen Verbindungszeichenfolgen für Datenbanken und Google-API-Schlüssel.

In den abgedeckten Kategorien scheint die Funktion zu wirken. Die Rate offengelegter Zugangsdaten in geschützten Kategorien sank um 53 %, nachdem GitHub sie standardmäßig aktiviert hatte.

Manche Dienste räumen schneller auf als andere

Ob ein geleaktes Geheimnis noch funktioniert, hängt stark vom Dienst dahinter ab. Von 101.886 npm-Tokens, die in öffentliche Repositories eingecheckt wurden, fanden die Forscher nur eines, das noch aktiv war.

Bei Zugangsdaten für Google-Cloud-Dienstkonten sah es ganz anders aus. Von 126.963 offengelegten Schlüsseln waren 69.041 noch gültig, als Truffle Security sie überprüfte.

Betroffenen wird geraten, offengelegte Zugangsdaten sofort auszutauschen, die Repositories zu bereinigen, den gesamten Commit-Verlauf zu durchsuchen und für alle aktiven Geheimnisse ein automatisches Ablaufdatum festzulegen.

Die Studie zeigt, wie viele funktionierende Geheimnisse in öffentlichem Code schlummern. Sie zeigt nicht, wie viele davon tatsächlich von Angreifern gefunden und missbraucht wurden.

Warum das wichtig ist

Für Entwickler und Sicherheitsteams ist die wichtigste Erkenntnis, dass das Blockieren neuer Lecks nicht dasselbe ist wie das Beheben alter. Push Protection scheint die Offenlegungen in den abgedeckten Kategorien zu verringern, doch Hunderttausende ältere und nicht erfasste Geheimnisse bleiben aktiv. Das deutet darauf hin, dass das Durchsuchen des Verlaufs und das Widerrufen von Schlüsseln weiterhin größtenteils den Repository-Inhabern überlassen bleibt.

Aufschlussreich ist auch der Unterschied zwischen npm-Tokens und Google-Cloud-Zugangsdaten. Er zeigt, dass Erkennung und automatischer Widerruf auf Anbieterseite viel bewirken können und dass Dienste ohne solche Mechanismen die Last bei den Nutzern lassen.

Die Ergebnisse passen in ein größeres Muster, bei dem sensible Daten in öffentlichem Code landen, von KI-Agenten, die Screenshots auf GitHub leaken, bis hin zu offengelegten GitLab-E-Mail-Adressen, mit denen sich Code pushen lässt. Es lohnt sich zu beobachten, ob GitHub Push Protection auf Verbindungszeichenfolgen für Datenbanken und Google-API-Schlüssel ausweitet und ob weitere Cloud-Anbieter einen automatischen Widerruf für geleakte Zugangsdaten einführen.