GitHub Secret Scanning Adds Cloudflare Access Service Token Detection

GitHub announced a secret-scanning detector for Cloudflare Access service tokens on November 12, 2026. Cloudflare separately documented its recovery behavior on November 11. When a scanning partner reports a leak, Cloudflare disables the affected service token and requires secret rotation before the token can be re-enabled.

GitHub secret scanning and recovery.

Workflow for Cloudflare service tokens.

What changed for Cloudflare Access users?

Cloudflare Access service tokens authenticate workloads such as deployment jobs and scheduled API clients. They use a Client ID and Client Secret pair. GitHub calls the newly supported secret type cloudflare_access_service_token. That announcement concerns Cloudflare Access credentials. Treat Cloudflare management API tokens and other credential types according to their own supported patterns and recovery procedures.

Before this integration	With the announced detector
Teams depended on their own detection and incident-response coverage for these service-token secrets	GitHub recognizes the supported token type
Responders manually disabled or replaced exposed credentials once discovered	Cloudflare documents automatic disablement when a partner reports a qualifying leak
A routine rotation could use a grace period	A reported leaked secret must be invalidated immediately during rotation

A partner notification for a public leak and a repository alert are separate mechanisms. Consult GitHub’s supported patterns and repository settings for user-alert, private-repository and push-protection behavior. The release alone does not establish that a given repository or branch policy blocks the secret at push time. Cloudflare’s newer scannable format also differs from legacy secrets, so retain other detection and auditing coverage.

What to do when the alert arrives

1. Identify the affected token and protected applications. Record incident identifiers and timestamps without copying the secret into tickets or chat.
2. Contain the exposure in Cloudflare Access. If the token was already disabled by the partner workflow, leave it disabled until the replacement is installed. For suspected abuse, review relevant application and Access logs.
3. Rotate the Client Secret. A reported leak has no rotation grace period. Put the replacement in the application secret store and in any affected CI environment.
4. Re-enable the token after clients have the replacement. Verify a controlled request with the new credential and confirm the old one is rejected using a safe internal test.
5. Remove exposed values from workflow logs, artifacts and current source where applicable. Review history and downstream copies. Rotate before treating repository cleanup as remediation.
6. Resolve the alert once owners confirm recovery and review the policy scope to reduce the impact of a future exposure.

Keep ASP.NET Core credentials out of source

The example uses a fixed HTTPS origin and disables redirects to avoid sending custom credential headers to another host. Supply configuration through a server-side secret store or environment mapping. For this named client, register the following in Program.cs.

builder.Services.AddHttpClient("CloudflareAccess", client =>
{
    client.BaseAddress = new Uri("https://internal.example.com/");
    client.DefaultRequestHeaders.Add("CF-Access-Client-Id",
        builder.Configuration["Cloudflare:ClientId"]
        ?? throw new InvalidOperationException("Missing Cloudflare client ID."));
    client.DefaultRequestHeaders.Add("CF-Access-Client-Secret",
        builder.Configuration["Cloudflare:ClientSecret"]
        ?? throw new InvalidOperationException("Missing Cloudflare client secret."));
}).ConfigurePrimaryHttpMessageHandler(() => new HttpClientHandler
{
    AllowAutoRedirect = false
});

Use the named client only with fixed or validated relative paths. Never accept an arbitrary outbound URL from request input. Keep secret headers out of telemetry. A GitHub Actions job should receive the secret only at the step that needs it, with narrowly scoped environment access. For a long-running service, check how your configuration provider reloads rotated values and verify that the next request uses the new secret.

Does deleting the commit revoke a credential? Revocation or rotation happens at the issuer. A historical commit, mirror or job log can still contain a copied value.

• GitHub detector changelog

• Cloudflare leaked-token recovery

• Cloudflare service token documentation

• GitHub supported secret-scanning patterns

• Related ASP.NET PB coverage