Ben Zimmermann hat 7,25 Millionen öffentliche Repositories auf Gitee durchsucht. 26.400 Zugangsdaten funktionierten beim Test noch. Geleakt sind also Cloud- und KI-Zugangsdaten – nicht ein einzelner Fehler, sondern ein Muster. Der unabhängige Sicherheitsforscher veröffentlichte die Ergebnisse am 28. Oktober. Wer Code veröffentlicht, veröffentlicht oft auch den Schlüssel zum dahinterliegenden System.
Der Fall ist kein Ausreißer, sondern zeigt ein strukturelles Problem. Zimmermann kontaktierte nicht die Entwickler, sondern die Anbieter mit den meisten exponierten Schlüsseln. Ob die gemeldeten Zugangsdaten inzwischen widerrufen sind, war bei Veröffentlichung nicht bestätigt. Diese offene Frage betrifft jeden, der selbst Code hostet.
Was der Forscher in 7,25 Millionen Gitee-Repositories fand
Zimmermann scannte die öffentlichen Gitee-Repositories mit zwei Werkzeugen und behielt nur jene Zugangsdaten, die sich beim Test gegen den ausstellenden Dienst noch verwenden ließen. Die größte Gruppe waren 9.473 Alibaba-Cloud-AccessKey-Paare. Danach folgten 3.805 YouTube-API-Keys, 3.170 DeepSeek-Keys, 1.489 Schlüssel für Zhipus BigModel-Plattform und 1.348 OpenAI-Keys. Kleinere Mengen entfielen auf GitHub, AWS, Google Cloud und Gemini. Besonders heikel ist ein aktives Organisations-Admin-Zugangsdatum für eine große Enterprise-KI-Plattform, deren Namen Zimmermann nicht nennt.
Eine Liste ihrer Zugangsdaten ging an die Anbieter mit den meisten exponierten Schlüsseln. Die Entwickler, die die Schlüssel geleakt hatten, kontaktierte er nicht. Zum Zeitpunkt der Veröffentlichung war nicht bestätigt, dass die gemeldeten Zugangsdaten widerrufen worden waren. Wer einen Schlüssel in ein öffentliches Gitee-Repository geschoben hat, kann also nicht davon ausgehen, dass er bereits ungültig ist. Der Scan lief etwa einen Monat, genaue Daten nennt Zimmermann nicht. Ob jemand die Schlüssel missbraucht hat, ist ebenfalls nicht bekannt.
Nach Commit-Datum stammen 12.242 der Zugangsdaten aus dem Jahr 2025, also fast die Hälfte der Gesamtmenge. Einige reichen bis in die späten 2000er zurück. Die 26.400 zählen jeden Zugangsdatensatz einmal, unabhängig davon, in wie vielen Repositories er auftauchte. Diese Zählweise bläht das Ausmaß nicht künstlich auf und redet es auch nicht klein. Ein einziger funktionierender Schlüssel kann genügen, um ein Konto, ein Projekt oder eine Abrechnung zu übernehmen.
Warum ein gelöschter Schlüssel nicht automatisch ungültig ist
Viele glauben, ein Schlüssel sei sicher, sobald er aus dem Code entfernt wurde. Die Scanner lesen aber die vollständige Commit-Historie eines Repositories. Ein Schlüssel, der aus der aktuellen Datei verschwunden ist, lässt sich dort noch finden. Viele Treffer stammen aus alten Commits, die längst nicht mehr im sichtbaren Code stehen. Die Vergangenheit eines Repositories bleibt abrufbar, auch wenn die Gegenwart aufgeräumt aussieht.
Löschen ist keine Sperre. Wer einen Schlüssel aus dem Code nimmt oder die Git-Historie umschreibt, macht ihn damit nicht ungültig. Darauf weist Truffle Security, der Hersteller von TruffleHog, hin. Wirksam ist nur der Widerruf beim Anbieter. Hattest du einen Schlüssel jemals in einem öffentlichen Repository, behandle ihn als exponiert.
Zwei Scanner, zwei halbe Bilder
Zimmermann nutzte TruffleHog und Kingfisher. TruffleHog fand 12.737 funktionierende Zugangsdaten, Kingfisher 14.664. Nur 1.001 wurden von beiden Werkzeugen gefunden. Jedes Werkzeug allein entdeckte etwa die Hälfte der Gesamtmenge. Das Ergebnis hängt also stark von der gewählten Methode ab.
Die Unterschiede haben System. TruffleHog fand fast alle Alibaba-Cloud-Keys. Kingfisher alle 1.489 BigModel-Keys, weil TruffleHog keinen Detektor für Zhipu hat. Wer sich auf einen Scanner verlässt, sieht einen Ausschnitt. Teams sollten die Detektoren gegen die Dienste prüfen, die sie tatsächlich nutzen.
Ein sauberer Scan beweist nichts. Er zeigt nur, dass die eingebauten Muster nichts gefunden haben. Bei KI-Diensten und regionalen Cloud-Anbietern entstehen ständig neue Schlüsselformate. Wer Secrets zuverlässig finden will, braucht mehrere Scanner und regelmäßige Updates.
Was ein gültiger Schlüssel anrichten kann
Die Wirkung hängt vom Dienst ab. OpenAI schreibt, ein kompromittierter Key erlaube einem anderen, das Kontingent des Kontos ohne Zustimmung des Besitzers zu nutzen. Das kann zu Datenverlust, unerwarteten Kosten, einem aufgebrauchten Monatskontingent und unterbrochenem API-Zugang führen. Ein YouTube-API-Key ist laut Google ein Google-Cloud-API-Key, der ein Projekt identifiziert. Ohne Einschränkungen lässt er sich mit allen APIs verwenden, die Google-Cloud-Keys akzeptieren.
Bei einem Organisations-Admin-Zugang für eine Enterprise-KI-Plattform ist die Reichweite schwerer abzuschätzen. Zimmermann beschreibt den Fund, nennt aber weder die Plattform noch die genauen Rechte. Solche Fälle betreffen nicht nur ein Konto, sondern die Verwaltungsebene einer Organisation. Was der Schlüssel genau erreichen konnte, bleibt offen. Das ist Teil des Risikos.
Gitee im Vergleich zu GitLab und Bitbucket
Gitee ist die Basis einer nationalen Open-Source-Plattform: Das chinesische Ministerium für Industrie und Informationstechnologie wählte die Plattform 2020 dafür aus. Die öffentliche API ist begrenzt; ein Versuch aus dem Jahr 2021, geleakte Zugangsdaten auf der Seite zu untersuchen, wurde deshalb aufgegeben. Die aktuelle Rate von 3,64 funktionierenden Zugangsdaten pro 1.000 gescannten Repositories liegt über den Werten früherer Scans von GitLab mit 3,11 und Bitbucket mit 2,39.
Der Vergleich hat einen Haken. Die früheren Scans nutzten nur TruffleHog. Auf TruffleHog bezogen liegt Gitees Rate bei 1,76, doch diese Zahl lässt Dienste wie Zhipu aus. Keine der beiden Zahlen zeigt, welche Plattform mehr leakt. Sie zeigen, wie stark das Ergebnis von der Methode abhängt.
Die Rate ist keine Rangliste. Sie beschreibt, wie viele gültige Schlüssel pro 1.000 Repositories gefunden wurden. Unterschiedliche Scanner, Dienste und Prüfzeitpunkte machen jeden Vergleich unscharf. Wer daraus eine Rangfolge baut, überdehnt die Daten. Hilfreicher ist die Frage, welche Schlüssel noch aktiv sind und wer sie widerrufen muss.
Was Betroffene jetzt konkret tun sollten
Behandle jeden Schlüssel, der jemals in einem öffentlichen Gitee-Repository stand, als exponiert und widerrufe ihn beim Anbieter. Das gilt auch, wenn du ihn längst gelöscht hast. Ein neuer Schlüssel reicht nicht, solange der alte noch gültig ist. Der Widerruf ist die Sperre, nicht das Aufräumen im Repository.
Bei Alibaba Cloud empfiehlt sich ein geordneter Wechsel. Erstelle ein neues AccessKey-Paar, stelle die Anwendungen darauf um und deaktiviere anschließend das alte Paar, bevor du es löschst. Prüfe auf unerwartete Kosten und auf Ressourcen, die du nicht angelegt oder gelöscht hast. ActionTrail zeigt die API-Aufrufe der letzten 90 Tage. Datenoperationen in Diensten wie OSS und SLS musst du in den jeweiligen Logs prüfen.
Bei Google- und YouTube-API-Keys rotierst du den Key – dabei entsteht ein neuer Key mit denselben Einschränkungen. Dann aktualisierst du die Apps und löschst den alten Key. Setze API-Einschränkungen, damit der Key nur mit den APIs funktioniert, die du brauchst. Bei OpenAI rotierst du den Key sofort auf der API-Keys-Seite und setzt Ausgabenlimits. Ein Limit ersetzt keinen Widerruf, begrenzt aber den Schaden, wenn ein Schlüssel doch abhandenkommt.
Die Untersuchung liefert keine bestätigten Missbrauchsfälle, und Zimmermann nennt weder genaue Scan-Daten noch eine vollständige Liste aller betroffenen Dienste. Das mindert das Risiko nicht, es verschiebt es ins Unbekannte. Cloud-Sicherheit beginnt bei der Frage, welche Schlüssel überhaupt existieren und wer sie sehen kann. KI macht diese Frage dringlicher, weil API-Kontingente, Modellzugänge und Abrechnungen direkt an Schlüsseln hängen. Am eigenen Umgang mit Secrets führt kein Weg vorbei: nicht ins Repository, nicht in die Historie, nicht in öffentliche Build-Logs. Ein Schlüssel, der dort einmal sichtbar war, gehört ausgetauscht – nicht versteckt.
Quelle: thehackernews.com
