GitHub erkennt jetzt offengelegte Cloudflare-Access-Service-Tokens

GitHub ergänzt einen neuen Erkennungstyp

GitHub nennt in seiner Änderungsmitteilung vom 12. November ausdrücklich den Anbieter Cloudflare und das Muster cloudflare_access_service_token. Es handelt sich um eine Erweiterung der serverseitigen Geheimniserkennung, nicht um ein Softwareupdate, das Administratoren auf ihrem Webserver oder in ihrem Repository installieren müssen.

GitHub unterscheidet zwischen Partnerbenachrichtigungen und Warnungen an Repository-Verantwortliche. Bei Partner-Geheimnissen werden Funde aus öffentlichen Repositories an den ausstellenden Dienst gemeldet; diese Meldungen müssen nicht zugleich als Warnung im Repository erscheinen. Benutzerwarnungen stehen dagegen dort zur Verfügung, wo die entsprechende Secret-Scanning-Funktion für das Repository unterstützt und aktiviert ist. Ein fehlender Warnhinweis im GitHub-Repository ist deshalb kein sicherer Nachweis dafür, dass keine Zugangsdaten offengelegt wurden.

Wofür die Cloudflare-Zugangsdaten eingesetzt werden

Cloudflare Access verwendet Service-Tokens, um automatisierten Systemen Zugriff auf durch Zero Trust geschützte Anwendungen zu ermöglichen. Ein solcher Token besteht aus einer Client-ID und einem geheimen Client-Secret. Typische Einsatzfälle sind Server-zu-Server-Verbindungen, Monitoring und automatisierte Abrufe. Das Secret gehört weder in den Quellcode noch in Konfigurationsdateien, die in ein Git-Repository übertragen werden.

Cloudflare vergibt für neue Client-Secrets seit dem 26. August 2026 ein erkennbares Format mit dem Präfix cfast_; ältere, aus Hexadezimalzeichen bestehende Secrets bleiben nach Herstellerangaben weiterhin gültig. Aus GitHubs kurzer Ankündigung geht nicht hervor, dass das neue Suchmuster jede ältere Token-Variante gleichermaßen zuverlässig findet. Auch deshalb ersetzt automatisches Scanning nicht die sichere Speicherung von Secrets.

Kompromittierte Tokens müssen erneuert werden

Wird ein Service-Token als offengelegt gemeldet, beschreibt Cloudflare einen konkreten Wiederherstellungsweg: Zuerst das betroffene Client-Secret rotieren, anschließend den neuen Wert in allen abhängigen Diensten hinterlegen und den deaktivierten Token wieder aktivieren. Die Client-ID bleibt dabei bestehen. Für bereits als geleakt gemeldete Secrets ist bei der Rotation keine Übergangsfrist zulässig; der alte Schlüssel wird sofort ungültig.

1. Im Cloudflare-Zero-Trust-Dashboard unter Access controls → Service credentials → Service Tokens den betroffenen Token ermitteln und sein Client-Secret rotieren.
2. Den neuen geheimen Wert in Anwendungen, Deployments und gegebenenfalls GitHub-Actions-Secrets aktualisieren. Abhängige Verbindungen anschließend prüfen.
3. Den Token nach der Rotation wieder aktivieren, falls Cloudflare ihn wegen einer Leckmeldung deaktiviert hat. Zusätzlich Fundstelle und Zugriffsprotokolle kontrollieren.

Cloudflare dokumentiert Rotation, Reaktivierung und die Behandlung gemeldeter Lecks im eigenen Service-Token-Handbuch. Das bloße Entfernen der Zugangsdaten aus einem Commit reicht nicht: Bereits kopierte Secrets bleiben bis zur Sperrung oder Erneuerung verwendbar.

Welche Repositories erfasst werden

Für öffentliche GitHub-Repositories steht Secret Scanning grundsätzlich automatisch zur Verfügung. Bei privaten oder internen Repositories hängt die Erkennung für Benutzerwarnungen vom Kontotyp und der aktivierten GitHub Secret Protection ab. GitHub erläutert die Unterschiede in seiner deutschsprachigen Dokumentation zur Geheimnisüberprüfung.

Beim Prüfen eines möglichen Lecks sollte zusätzlich der Git-Verlauf berücksichtigt werden. GitHub durchsucht bei aktiver Erkennung auch ältere Commits und prüft Repositories nach Einführung neuer Geheimnistypen erneut. Wer Cloudflare-Access-Zugangsdaten im Projekt verwendet, sollte deshalb bestehende Warnungen und die in Cloudflare protokollierten Leckmeldungen kontrollieren und künftig die Secret-Verwaltung der jeweiligen Deployment-Plattform statt fest kodierter Werte nutzen.