Cloudflare Access Leaked Service Token Detection & Zero-Grace Recovery: cfast_ Secret Scanning, HTTP 409/400 Transitions, and Legacy 64-Hex Blind Spots

Cloudflare Access Leaked Service Token Auto-Disable & Zero-Grace 3-Step Recovery Architecture Diagram (Conceptual SVG Illustration)

On November 11–12, 2026, Cloudflare rolled out automatic detection and disabling for leaked Access service tokens via GitHub secret scanning alongside mandatory secret rotation before re-enabling leaked service tokens. When GitHub secret scanning detects a Cloudflare Access service token Client Secret (cfast_...) in a public repository and reports it to Cloudflare, Access immediately disables the token (enabled: false), emails account administrators, and blocks any attempt to re-enable the token (HTTP 409 Conflict) until its secret has been rotated without a grace period.

The key operational takeaway is straightforward: leaked tokens reject rotation requests that include a future previous_client_secret_expires_at (HTTP 400 Bad Request) and remain disabled (enabled: false) even after rotation succeeds, so recovery automation must omit the grace-period field, deploy the newly generated secret to all callers while the token is still disabled, and then send a PUT request that preserves both name and tags while setting enabled: true. In addition, legacy 64-character hexadecimal secrets created before August 26, 2026 are not covered by the cfast_ scanning pattern and should be rotated into the new format. This post synthesizes the official Cloudflare Changelog, Cloudflare One Service Tokens documentation, and Rotate a Service Token API reference, paired with a local Python state-transition verification script rather than live credential exposure tests against a production Zero Trust tenant.

1. What Changed in November 2026: Automatic Disabling and Mandatory Rotate-Before-Enable

Automated workloads—such as CI/CD runners, microservice backends, and scheduled workers—authenticate to Cloudflare Access applications using service tokens consisting of a CF-Access-Client-Id and a CF-Access-Client-Secret header pair (or a configured single header) (Service tokens documentation).

With the November 11, 2026 update, Cloudflare enforces a three-part lifecycle whenever a partner secret scanner reports an exposed Client Secret:

Partner Secret Scanning Detection: GitHub secret scanning identifies Cloudflare Access Client Secrets exposed in public repositories using the cfast_ structure and reports the match to Cloudflare.

Immediate Token Disabling & Administrator Alerting: Cloudflare Access automatically sets the affected token to disabled (enabled: false)—causing both current and previous secrets to stop authenticating immediately—and emails account administrators.

State-Machine Enforcement (409 on Re-Enable, 400 on Grace Period): To prevent operators from turning a compromised credential back on without replacing its secret, attempting to re-enable a leaked token before rotating its secret returns HTTP 409 Conflict. Furthermore, leaked tokens do not allow a rotation grace period; passing a future previous_client_secret_expires_at timestamp during rotation returns HTTP 400 Bad Request (Rotate a service token API).

2. Four Technical Boundaries to Keep Separate

When updating incident response runbooks and secret scanners, keep these four boundaries distinct:

Pattern matching is separate from checksum and active-token verification: Since August 26, 2026, newly generated Client Secrets follow the 54-character format cfast_ + 40 alphanumeric characters + an 8-character lowercase hexadecimal checksum. Custom scanners can match candidates with cfast_[A-Za-z0-9]{40}[a-f0-9]{8}, but matching the regular expression does not validate the 8-character checksum or confirm that the token is active (GitHub automatically detects leaked Access service tokens).

cfast_ secrets and legacy 64-character hexadecimal secrets have different detection coverage: Client Secrets issued before August 26, 2026 use a 64-character hexadecimal string (for example, bdd31cbc4dec...). While legacy secrets continue to authenticate normally and do not require rotation to function, the cfast_ partner scanning pattern does not apply to legacy 64-character hexadecimal secrets (Service tokens — Client Secret format). Rotating pre-August 2026 secrets upgrades them to the cfast_ format while keeping the same Client ID.

Secret rotation (rotate) is separate from token lifetime renewal (refresh / duration): Calling POST .../rotate issues a new client_secret for the same client_id, whereas calling POST .../refresh (or updating duration via PUT) extends the token's expires_at timestamp.

Strict service token authentication (strict_service_token_auth) controls failure status codes: Zero Trust organizations created on or after 2026-10-05 have strict_service_token_auth enabled by default (and cannot disable it), returning 401 or 403 and logging failed attempts when a token is disabled or presents an invalid secret. Organizations created before 2026-10-05 that leave strict_service_token_auth off return a 302 redirect to the Access login page on failure, which can mask credential outages in HTTP clients that follow redirects automatically (Strict service token authentication).

Dimension	Structured Client Secret (`cfast_`)	Legacy Client Secret (64-Hex)	Operational Action
Issuance Cutoff	Created or rotated on or after August 26, 2026	Created before August 26, 2026 (not yet rotated)	Audit token creation/update timestamps and schedule rotation for pre-Aug 26 secrets
Format & Length	`cfast_` • 40 alphanumeric + 8-hex checksum (54 chars)	64 lowercase hexadecimal characters (64 chars)	Both formats share the same `Client ID` and `CF-Access-Client-Secret` header
Custom Scanner Regex	`cfast_[A-Za-z0-9]{40}[a-f0-9]{8}`	No dedicated prefix (indistinguishable from generic SHA-256 hex)	Add `cfast_[A-Za-z0-9]{40}[a-f0-9]{8}` to pre-commit and internal CI scanners
GitHub Auto-Disable	Supported (reports leak and auto-disables token)	Not covered by the `cfast_` pattern	Rotate legacy secrets with a planned grace period to gain automatic leak protection

3. Normal Secret Rotation vs. Leaked Token Recovery

Although planned rotations and leak recoveries call the same endpoints, the API enforces different state transitions when a token has been flagged as leaked (Rotate a service token API).

Lifecycle Step / Field	Planned Rotation (Normal State)	Leaked Token Recovery (Leaked State)	API Status Code & Trap
Initial Token State	`enabled: true` (authenticating traffic)	Automatically set to `enabled: false` upon partner report	Disabling a token immediately stops both current and previous secrets
Re-Enable Before Rotate (`PUT .../service_tokens/{id}`)	Not applicable (or freely toggled by admin)	Rejected if secret has not been rotated since leak report	Returns `HTTP 409 Conflict` to block reuse of exposed secret
Grace Period Field (`previous_client_secret_expires_at`)	Optional RFC 3339 future timestamp (1 hour to 30 days in UI)	Not supported (must omit `previous_client_secret_expires_at`)	Passing a future expiration on a leaked token returns `HTTP 400 Bad Request`
Previous Secret Lifetime	Remains valid until `previous_client_secret_expires_at`	Discarded immediately upon rotation	Update all callers before re-enabling to avoid authentication failures
Post-Rotation State	Remains `enabled: true`	Remains `enabled: false` after rotation	Requires an explicit `PUT` with `"enabled": true` after secret rollout

4. Three-Step Zero-Grace Recovery Workflow and Verification Code

4.1 Three-Step API Recovery Sequence

When recovering a leaked service token via the Cloudflare API, strip previous_client_secret_expires_at from the rotation payload and preserve the token's existing name and tags when re-enabling it (Service tokens documentation).

4.2 Local Python Verification Script

The following script models and verifies the six core invariants from the official specification: cfast_ vs. legacy 64-hex classification, normal grace-period dual-secret acceptance, automatic disabling on partner leak report, HTTP 409 when re-enabling before rotation, HTTP 400 when passing a future previous_client_secret_expires_at on a leaked token, and tag-preserving recovery under strict_service_token_auth.

5. Production Operations & CI/CD Checklist

Rotate pre-August 26, 2026 legacy 64-hex secrets into cfast_ format: Any service token whose secret has not been rotated since August 26, 2026 still uses a 64-character hexadecimal string that is excluded from cfast_ partner scanning. Perform a planned grace-period rotation to upgrade the secret format without downtime.

Register cfast_[A-Za-z0-9]{40}[a-f0-9]{8} in internal secret scanners: Add the official regular expression to pre-commit hooks, Gitleaks, or TruffleHog rules to catch accidental commits in private repositories before they ever reach public remotes.

Add an emergency zero-grace branch to rotation automation: Ensure rotation scripts omit previous_client_secret_expires_at when recovering a leaked token so the API call does not fail with HTTP 400.

Preserve name and all tags on PUT re-enable requests: Because PUT /accounts/{account_id}/access/service_tokens/{service_token_id} replaces the entire tags map, always fetch and echo existing tags when setting "enabled": true so service_token_tag Access policies ("decision": "non_identity") continue to match.

Enable strict_service_token_auth on Zero Trust organizations created before 2026-10-05: Send PATCH /accounts/{account_id}/access/organizations with {"strict_service_token_auth": true} so disabled or mismatched service tokens return explicit 401/403 responses and appear in Access authentication logs instead of returning 302 login redirects.