Zimmermann informierte die Anbieter mit den meisten offengelegten Schlüsseln über die gefundenen Zugangsdaten, nicht aber die Entwickler, die sie veröffentlicht hatten. Zum Zeitpunkt der Veröffentlichung war nicht bestätigt, dass auch nur eine der gemeldeten Zugangsdaten zurückgezogen wurde. Wer je einen Schlüssel in ein öffentliches Gitee-Repository gepusht hat, kann also nicht davon ausgehen, dass dieser inzwischen ungültig ist.

Der Scan lief rund einen Monat; konkrete Daten nannte Zimmermann nicht, sodass unklar bleibt, wie lange der Test der Zugangsdaten zurückliegt. Ob Dritte die Schlüssel bereits genutzt haben, ließ er ebenfalls offen.

Zum Einsatz kamen zwei Secret-Scanner: TruffleHog und Kingfisher. Beide probierten jede gefundene Zugangsdatei gegen den jeweils ausstellenden Dienst aus und behielten nur, was tatsächlich funktionierte. Die Scanner lasen dabei die vollständige Commit-Historie jedes Repositories — ein Schlüssel, den ein Entwickler später aus dem Code entfernt hat, taucht dort weiterhin auf und wurde mitgezählt.

Die Zahl 26.400 zählt jede Zugangsdatei einmal, unabhängig davon, in wie vielen Repositories sie auftauchte. Nach Commit-Datum stammen 12.242 der Funde aus dem Jahr 2025, also fast die Hälfte. Einige reichen bis in die späten 2000er-Jahre zurück.

Nach den Alibaba-Cloud-Schlüsseln waren die größten Gruppen:

  • 3.805 YouTube-API-Schlüssel
  • 3.170 DeepSeek-Schlüssel
  • 1.489 Schlüssel für Zhipus KI-Plattform BigModel
  • 1.348 OpenAI-Schlüssel

Kleinere Mengen entfielen auf GitHub, AWS, Google Cloud und Googles Gemini. Bei einem der Funde handelte es sich laut Zimmermann um „eine aktive Organisations-Administrator-Zugangsberechtigung für eine große Unternehmens-KI-Plattform". Welche Plattform gemeint ist und worauf die Berechtigung Zugriff gab, nannte er nicht.

Was ein funktionierender Schlüssel ermöglicht, hängt vom Dienst ab. OpenAI zufolge kann ein kompromittierter Schlüssel dazu führen, dass Dritte das Kontingent des Kontos ohne Zustimmung des Inhabers nutzen — mit der Folge von „Datenverlust, unerwarteten Kosten", aufgebrauchtem Monatskontingent und unterbrochenem API-Zugriff. Ein YouTube-API-Schlüssel ist nach Angaben von Google ein Google-Cloud-API-Schlüssel, der ein Projekt identifiziert; ohne API-Beschränkungen lässt er sich mit jeder API verwenden, die Google-Cloud-Schlüssel akzeptiert.

Als Gegenmaßnahme gilt: Jeder Schlüssel, der jemals in einem öffentlichen Gitee-Repository stand, ist als offengelegt zu behandeln und beim Anbieter zu widerrufen. Das Löschen aus dem Code oder das Umschreiben der Repository-Historie widerruft ihn nicht, wie Truffle Security, der Hersteller von TruffleHog, betont.

  • Alibaba Cloud: neues AccessKey-Paar anlegen, Anwendungen umstellen, altes Paar deaktivieren und löschen. Der Leak-Reaktionsplan von Alibaba Cloud empfiehlt zudem, auf unerwartete Kosten sowie auf nicht benötigte, angelegte oder gelöschte Ressourcen zu prüfen. ActionTrail zeigt die API-Aufrufe des Schlüssels der letzten 90 Tage; Datenoperationen in Diensten wie OSS und SLS müssen in deren eigenen Protokollen geprüft werden.
  • Google- und YouTube-API-Schlüssel: Schlüssel rotieren — dabei entsteht ein neuer Schlüssel mit denselben Beschränkungen —, Anwendungen umstellen, alten Schlüssel löschen. Zusätzlich API-Beschränkungen setzen, damit der Schlüssel nur mit den benötigten APIs funktioniert.
  • OpenAI: Schlüssel umgehend über die Seite „API Keys" rotieren, wie OpenAI rät, und Ausgabenlimits setzen, um Kosten durch einen geleakten Schlüssel zu begrenzen.

Auffällig ist der geringe Überlapp der beiden Werkzeuge: TruffleHog fand 12.737 funktionierende Zugangsdaten, Kingfisher 14.664 — nur 1.001 davon fanden beide. Jedes Werkzeug allein deckte damit rund die Hälfte der Gesamtmenge ab. TruffleHog fand nahezu alle Alibaba-Cloud-Schlüssel, Kingfisher sämtliche 1.489 BigModel-Schlüssel, da TruffleHog laut Zimmermann keinen Detektor für Zhipus Schlüssel besitzt. Teams, die sich auf einen einzigen Scanner verlassen, sollten dessen Detektoren gegen die tatsächlich genutzten Dienste abgleichen. Kingfisher stammt von MongoDB; Zimmermanns Veröffentlichung entstand zusammen mit dessen Kingfisher-Team.

Gitee wurde 2020 vom chinesischen Ministerium für Industrie und Informationstechnologie als Basis einer nationalen Open-Source-Plattform für Code-Hosting ausgewählt. Die öffentliche API der Plattform ist eingeschränkt; ein Versuch, 2021 geleakte Zugangsdaten dort zu untersuchen, scheiterte daran.

Mit 3,64 funktionierenden Zugangsdaten pro 1.000 gescannten Repositories liegt Gitee über den Werten früherer Scans von GitLab (3,11) und Bitbucket (2,39). Diese Scans nutzten allerdings nur TruffleHog. Allein auf dessen Ergebnissen beruhend liegt Gitees Quote bei 1,76 — dabei fehlen jedoch Dienste, die TruffleHog nicht abdeckt, etwa Zhipu. Keine der beiden Zahlen zeigt daher, welche Plattform mehr Zugangsdaten preisgibt.