543.699 gültige Zugangsdaten auf GitHub — die älteste seit 2009

Entwickler committen versehentlich Zugangsdaten — das ist nichts Neues. Neu ist das Ausmaß, in dem diese Daten Jahre später noch funktionieren. Eine Untersuchung von Truffle Security hat 224 Millionen öffentliche GitHub-Repositories durchsucht und 543.699 Zugangsdaten gefunden, die zum Testzeitpunkt noch gültig waren. Niemand hatte sie widerrufen.

Der Umfang

Die Forscher arbeiteten mit einem Datensatz von 224.553.295 Repositories und 58,4 Milliarden Dateien. Entscheidend ist die Methodik: Es wurde nicht nur nach Mustern gesucht, sondern jeder Fund live gegen den jeweiligen Anbieter geprüft. Gezählt wurden ausschließlich Zugangsdaten, die am 27. und 28. Juli 2026 tatsächlich noch funktionierten.

Ergebnis: 543.699 gültige Zugangsdaten, verteilt auf über 1,1 Millionen einzelne Fundstellen — dieselben Daten tauchen also mehrfach auf, etwa in Forks.

Was gefunden wurde

Die Spitzenposition der Google-Dienste ist kein Zufall: Service-Account-Schlüssel kommen als JSON-Datei und landen schnell mit im Repository, wenn die .gitignore unvollständig ist. Datenbank-Verbindungsstrings wiederum stehen oft in Konfigurationsdateien, die jemand „nur kurz zum Testen“ eingecheckt hat.

Der eigentliche Skandal: das Alter

Nicht die Zahl ist das Beunruhigende, sondern wie lange diese Daten schon offen liegen:

• Median: 784 Tage. Die Hälfte aller noch funktionierenden Zugangsdaten liegt länger als zwei Jahre offen.
• 90. Perzentil: 6,3 Jahre. Jede zehnte aktive Zugangsdatei ist älter als sechs Jahre.
• Der älteste Fund stammt von Juni 2009 — über 16 Jahre alt und immer noch gültig.

Das heißt: Es geht nicht um Schlüssel, die gestern versehentlich hochgeladen wurden und morgen rotiert werden. Es geht um Zugänge, die seit Jahren für jeden abrufbar sind, der danach sucht — und die niemand je gesperrt hat.

Warum GitHubs Schutz nicht greift

GitHub hat seit Februar 2024 die Push Protection standardmäßig aktiviert. Sie erkennt bekannte Schlüsselformate beim Hochladen und blockiert den Push. Das klingt nach einer Lösung — die Zahlen sagen etwas anderes.

199.843 der gefundenen Zugangsdaten wurden gepusht, nachdem die Push Protection standardmäßig lief. Das sind 36,8 Prozent aller Funde.

Der Grund liegt in der Funktionsweise: Push Protection erkennt nur Muster, die sie kennt. 51,8 Prozent der gefundenen aktiven Zugangsdaten haben Formate, die standardmäßig nicht blockiert werden — darunter Datenbank-Verbindungsstrings, private Schlüssel und Google API Keys. Ein String wie postgres://user:passwort@host:5432/db ist für einen Mustererkenner schwer von einer harmlosen URL zu unterscheiden.

Dazu kommt: Die Push Protection wirkt nur nach vorn. Alles, was vor Februar 2024 committet wurde, war nie davon erfasst — und liegt bis heute da.

Was das praktisch bedeutet

Ein öffentlich einsehbarer Datenbank-Verbindungsstring ist kein theoretisches Risiko. Wer ihn findet, hat Lesezugriff auf die Datenbank, oft auch Schreibzugriff. Ein Google-Service-Account-Schlüssel kann je nach Berechtigung Cloud-Ressourcen starten — auf Rechnung des Eigentümers. Und ein SendGrid-Key erlaubt den Versand von E-Mails unter fremdem Absender, was Phishing deutlich glaubwürdiger macht.

Entscheidend ist dabei ein Punkt, den viele unterschätzen: Einen Commit nachträglich zu löschen, hilft nicht. Der alte Zustand bleibt in der Git-Historie, in Forks, in Caches und in Archivdiensten. Sobald ein Geheimnis einmal öffentlich war, ist es verbrannt.

Was zu tun ist

Die Empfehlungen der Forscher sind unspektakulär, aber wirksam:

1. Sofort rotieren, nicht löschen. Wer merkt, dass ein Schlüssel im Repository gelandet ist, erzeugt einen neuen und sperrt den alten — unabhängig davon, ob eine Warnung kam.
2. Die eigene Historie scannen. Push Protection greift erst ab Februar 2024. Was davor liegt, muss man selbst prüfen, etwa mit TruffleHog oder Gitleaks — und zwar über die gesamte Historie, nicht nur den aktuellen Stand.
3. Ablaufende Zugangsdaten verwenden. Ein Schlüssel, der nach 90 Tagen automatisch ungültig wird, begrenzt den Schaden von allein.
4. Secrets gar nicht erst in Dateien legen. Umgebungsvariablen, ein Secret-Manager oder zumindest eine konsequent gepflegte .gitignore.

Einordnung

Die Studie zeigt weniger ein GitHub-Problem als ein Prozessproblem. Die Plattform hat Werkzeuge gebaut, die greifen — aber nur bei bekannten Formaten und nur für neue Commits. Der Rest ist Sache der Entwickler und ihrer Organisationen.

Dass eine Zugangsdatei von 2009 heute noch funktioniert, ist dabei weniger eine Aussage über GitHub als über den Anbieter, der sie seit sechzehn Jahren nicht hat ablaufen lassen.

Quellen: Untersuchung von Truffle Security („GitHub Repos Exposed 543,699 Credentials. Nobody Revoked Them.“), Datengrundlage The Stack v3. Abgerufen am 02.10.2026.