GitHub Secret Scanning Adds Cloudflare Access Token Detection: How to Recover Leaked Credentials

The important distinction is between finding a leaked credential, notifying its issuer, and restoring the service that used it. GitHub’s announcement describes the detection and reporting paths; Cloudflare’s documentation explains the recovery work administrators must perform afterward.

What the new detector covers​

The announcement names one newly supported secret type: Cloudflare Access service tokens. It does not announce blanket detection for every Cloudflare credential, nor does it specify legacy-token coverage, validity checking, or push-protection support for this detector. Detection should not be mistaken for a promise that GitHub will block a commit before exposure.

Cloudflare Access service tokens give automated systems credentials for reaching protected applications. Each consists of a Client ID and Client Secret, commonly supplied through the CF-Access-Client-Id and CF-Access-Client-Secret HTTP headers.

That makes the update relevant to developers and administrators managing machine-to-machine access—not just people looking for passwords accidentally left in source code.

Public reporting and repository alerts are different​

GitHub distinguishes two notification routes:

• Partner secrets: Matches found in public repositories are automatically reported to the credential issuer through GitHub’s secret-scanning partnership program.
• User secrets: Supported matches produce repository secret-scanning alerts in public or private repositories.

Those definitions are not interchangeable. The announcement does not provide separate partner- and user-support indicators for this particular Cloudflare detector, so its wording should not be read as confirmation that every private repository receives equivalent coverage.

GitHub’s partner documentation supplies useful additional context: partner scanning runs by default on public repositories and public npm packages. GitHub sends detected credentials to the provider, which validates the string and determines its response. Regular repository alerts follow a separate workflow. Provider notification is not the same thing as a repository alert waiting for an administrator to close it.

How to recover a reported Cloudflare token​

Cloudflare documents a specific recovery sequence for service tokens reported as leaked. A reported token cannot be re-enabled until its secret has been rotated.

For administrators handling that situation:

1. Rotate the secret. In the Cloudflare dashboard, open Zero Trust > Access controls > Service credentials > Service Tokens, locate the token, and select Rotate secret.
2. Update dependent services with the replacement Client Secret. The Client ID remains unchanged.
3. Re-enable the token. Rotation alone does not turn a disabled token back on.
4. Remove the exposed credential from the reported location. Deleting it is not a substitute for rotation because someone may already have copied it.

There is an important operational catch: leaked-token rotation has no grace period. The previous secret is revoked immediately, unlike an ordinary planned rotation that can temporarily keep both secrets valid. For API-driven recovery, Cloudflare instructs administrators to omit previous_client_secret_expires_at.

The practical takeaway is straightforward: treat this as an incident-response workflow, not routine credential housekeeping. GitHub adds another opportunity to discover an exposed Access credential; Cloudflare’s recovery requirements mean the responsible team still needs to replace it, update its consumers, and explicitly restore the token.