On November 11, 2026, Cloudflare announced that GitHub secret scanning now recognizes Cloudflare Access service token secrets exposed in public repositories. GitHub notifies Cloudflare, Access disables the affected token and emails the account administrators. Before this, containing a leak depended on someone noticing it and replacing the secret.
A service token is the credential Access uses for machines: a Client ID and Client Secret pair that CI pipelines, scripts, cron jobs and services send in headers to reach a protected application without a person logging in.
What changes in practice
Two things, and the second one weighs more on operations.
The first is automatic disabling. Cloudflare does not ask first: the token stops authenticating as soon as the report arrives. Any integration that relies on it starts getting blocked by Access.
The second is the recovery rule. A token flagged as leaked only works again after its secret is rotated, and that rotation does not accept a grace period. A regular Access rotation can keep the old secret valid for a while as services are updated; for a leaked token, the previous secret is discarded at once. Through the API, trying to re-enable the token before rotating returns 409, and requesting a future previous_client_secret_expires_at returns 400. Rotation does not re-enable the token either: you have to turn it on again after distributing the new secret. The Client ID stays the same.
For auditing, the API now returns leak_reported_at, leak_reporter and leak_report_url, with when and where the leak was found. Rotation clears these fields, so the history lives in the admin activity logs.
Who should look at this
Teams that use Access to protect internal dashboards, staging APIs or admin tools and authenticate automations with a service token. The concrete risk is a public repository: an open source project with a deploy workflow, a sample repository published by mistake, a public fork of internal code.
If you never exposed a secret, nothing changes. If you did, you get a protection you did not have before, and also a service outage with no warning, whenever GitHub finds the secret.
What to do now
There is no deadline, because the change is already live. What is worth doing this week:
- List which automations depend on each service token and who is responsible for them. When the leak email arrives, someone needs to know within minutes which services will break and where the new secret has to go.
- Check that the email recipients on the Cloudflare account are actually read. The notice goes to administrators; a shared inbox nobody owns will not do.
- Rehearse the rotation: where the secret is stored (CI secrets, vault, Worker variables) and how to update every place at once, since there will be no window in which both secrets work.
- Look for secrets already exposed in your own repositories. Secrets created on or after August 26, 2026 follow the format
cfast_+ 40 alphanumeric characters + an 8-character hexadecimal checksum, and Cloudflare published the regular expressioncfast_[A-Za-z0-9]{40}[a-f0-9]{8}for scanning tools that support custom rules.
Deleting the secret from the repository does not replace rotation. The documentation itself notes it may already have been copied.
What is still unclear
The cfast_ prefix format only applies to secrets created since August 26. Older ones, 64 hexadecimal characters, keep working and do not need rotation. Cloudflare says the regular expression does not cover that legacy format, but does not say whether GitHub can detect them; since an unprefixed hex string is hard to tell apart from other values, the safer assumption is that leaked legacy tokens stay active. If you have tokens created before that date, running a planned rotation now (with a grace period, while it is still allowed) moves the token to the detectable format.
The announcement also mentions only public repositories. It says nothing about private repositories with secret scanning enabled or about scanning partners other than GitHub.
If your company is weighing something similar, reach me on LinkedIn or WhatsApp.
