{"id":183679,"date":"2026-10-07T22:54:32","date_gmt":"2026-10-07T20:54:33","guid":{"rendered":"https:\/\/prohoster.info\/blog\/news\/v-github-vyyavleno-543-tysyachi-ostavlennyh-v-repozitoriyah-dejstvuyushhih-tokenov-klyuchej-i-parolej"},"modified":"2026-10-07T22:54:38","modified_gmt":"2026-10-07T20:54:38","slug":"543000-active-tokens-keys-and-passwords-found-in-github-repositories","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/543000-active-tokens-keys-and-passwords-found-in-github-repositories","title":{"rendered":"Auf GitHub wurden 543.000 aktive Tokens, Schl\u00fcssel und Passw\u00f6rter in Repositories gefunden","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Das Unternehmen Truffle Security hat die Ergebnisse einer Analyse von Datenlecks in Repositories, die auf GitHub gehostet sind, ver\u00f6ffentlicht. Bei der Durchsuchung von 224 Millionen Repositories, die insgesamt 58 Milliarden Dateien enthalten, wurden 543.000 einzigartige Zugangsdaten (Token, Schl\u00fcssel und Passw\u00f6rter) gefunden, die weiterhin g\u00fcltig sind. Die g\u00fcltigen Zugangsdaten waren seit mindestens einem Jahr in den Repositories, da in der Untersuchung ein Snapshot des GitHub-Stands vom 7. August des letzten Jahres verwendet wurde und die \u00dcberpr\u00fcfung der G\u00fcltigkeit der Zugangsdaten, die durch Testaufrufe an API, Netzwerkdienste und Hosts durchgef\u00fchrt wurde, Ende Juli dieses Jahres stattfand. <\/p>\n
Die mediane Zeit, in der Zugangsdaten \u00f6ffentlich zug\u00e4nglich waren, wurde auf 784 Tage gesch\u00e4tzt, wobei die \u00e4ltesten noch g\u00fcltigen Zugangsschl\u00fcssel auf das Jahr 2009 datiert wurden. Etwa 200.000 gefundene g\u00fcltige Zugangsdaten wurden in Repositories platziert, nachdem GitHub standardm\u00e4\u00dfig ein System zur Blockierung von Datenlecks und Zugangstoken aktiviert hat, das w\u00e4hrend des Push-Vorgangs eine \u00dcberpr\u00fcfung durchf\u00fchrt. Datenlecks wurden nicht erkannt, da sie in Formaten vorlagen, die von der implementierten Sicherheit nicht unterst\u00fctzt wurden, w\u00e4hrend die direkte Aktivierung von Filtern die erkannten Datenlecks etwa halbierte. <\/p>\n
Es stellte sich heraus, dass GitHub erfolgreich Token-Lecks zu weit verbreiteten Diensten wie GitHub, AWS, Slack, SendGrid, Stripe und GCP erkennt, aber die im Code hinterlassenen Datenbankverbindungsparameter, API-Token von Google und private Schl\u00fcssel \u00fcbersieht. Datenbankverbindungsparameter und private Schl\u00fcssel werden standardm\u00e4\u00dfig nicht blockiert, um Fehlalarme zu vermeiden. Die API-Schl\u00fcssel von Google werden nicht blockiert, da sie mit dem Pr\u00e4fix AIzaSy versehen sind, \u00e4hnlich wie offene API-Schl\u00fcssel von Google Maps, die f\u00fcr die Integration auf Webseiten vorgesehen sind. <\/p>\n
Bei den gefundenen Anmeldedaten, die nicht funktionieren, handelt es sich gr\u00f6\u00dftenteils um Zugriffstoken und Schl\u00fcssel f\u00fcr Dienste, die einen Widerrufsmechanismus anbieten. Zum Beispiel wurde von 101886 NPM-Token nur ein einziges als g\u00fcltig identifiziert (0,001 %), von 73048 GitHub-Token waren es 260 (0,35 %), und von 30437 Hugging Face-Token waren 15 (0,05 %) aktiv. Bei den Stripe-Schl\u00fcsseln lag die \u00dcberlebensrate bei 4 %, bei AWS bei 8 %, bei GCP bei 8 %, bei Slack bei 2 % und bei GitLab bei 0,64 %. Zum Vergleich: Von 12985 ermittelten Verbindungsparametern zu PostgreSQL-Datenbanken blieben 11465 aktiv (88 %), von 2421 Verbindungsparametern zu MySQL waren 1806 (74 %) aktiv, von 126963 Google Cloud-Servicekonten blieben 69041 (54 %) aktiv, von 3790 Docker Hub-Token waren 1244 (33 %) aktiv, und von 22800 SendGrid-Schl\u00fcsseln waren 9189 (40 %) aktiv. <\/p>\n