Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- GitHub secret scanning can report Cloudflare Access service-token secrets exposed in public repositories. Access disables the affected token and emails account administrators.
- Client Secrets created from August 26, 2026 use the cfast_ prefix, 40 alphanumeric characters and an 8-character hexadecimal checksum.
- The published detector is cfast_[A-Za-z0-9]{40}[a-f0-9]{8}. A match only indicates a similar format; it does not validate the checksum or credential status.
- The rule does not cover legacy 64-character hexadecimal secrets, which continue to work and do not need rotation solely because of their format.
- A reported leak must be rotated before re-enabling. The old secret stops working immediately with no grace period; update every caller first.
What changed, and which jobs may be affected?
Cloudflare’s November 11, 2026 announcement says GitHub secret scanning automatically detects Cloudflare Access service-token secrets exposed in public repositories and reports them to Cloudflare. Access then disables the affected token and emails account administrators.
Other secret-scanning tools can use the consistent Client Secret format in custom detection rules. CI jobs, scheduled tasks, monitors and backend services that share the token may be affected; this announcement alone does not explain an ordinary user’s sign-in failure.
The official material does not announce new plan eligibility, fees, country restrictions or an exact action time for every account. An authorized administrator should check the alert and actual token state before acting. This guide has not accessed a reader’s account, run a scan or performed recovery.
Recognize the new Client Secret format without inferring status
Since August 26, 2026, newly created service-token Client Secrets use the cfast_ prefix, followed by 40 alphanumeric characters and an 8-character hexadecimal checksum. Cloudflare’s published custom-detection regular expression is: cfast_[A-Za-z0-9]{40}[a-f0-9]{8}.
The expression can help a scanner find possible exposed secrets in the newer format. Matching it does not verify the checksum, establish that the secret is currently valid or enabled, or confirm that a leak was reported; check the official alert and account records as well.
Legacy Client Secrets use a 64-character hexadecimal format. They continue to work and do not require rotation just because of the format. Both formats use the same Client ID and authentication headers.
Identify the token and callers before rotating
Use the leak alert to confirm the account, token name and affected applications. List the services using that token and where their credentials are configured. Record configuration names, owners and times; keep real secrets out of tickets, screenshots and logs.
Recovery clears the token’s leak metadata. Preserve any necessary redacted report details first, then use administrator activity logs for the audit history. Missing metadata after rotation does not mean the leak never happened.
Step 1: rotate the secret and revoke the old value immediately
In the Cloudflare dashboard, open Zero Trust → Access controls → Service credentials → Service Tokens, find the token and select Rotate secret. For a token reported as leaked, the old secret is revoked immediately; a rotation grace period cannot keep it working.
If an authorized management program calls the rotation API, omit previous_client_secret_expires_at. Requesting a future expiration for a leaked token’s old secret returns 400. A grace period available for routine rotation does not apply to leak recovery.
The Client ID stays the same after rotation, while the Client Secret changes. The old secret stops working immediately and cannot be restored by extending its expiration. Plan for callers to be unavailable during configuration updates; do not promise uninterrupted service.
Step 2: update callers, then explicitly re-enable the token
Put the new Client Secret in each inventoried service’s existing credential configuration. Keep the Client ID, target application and existing access policy. There is no evidence that changing network egress resolves this credential-state problem.
Once the callers that need to recover are ready, use Enable token for that token. Rotation does not automatically re-enable a disabled token. Attempting to enable it before rotation returns 409 through the API.
For example, if CI and a nightly synchronization job share one token, updating CI alone does not establish that the nightly job has recovered. This is a hypothetical illustration, not a test performed for this guide; confirm that each caller has loaded the new configuration.
Step 3: remove the exposure and verify actual requests
Remove the exposed secret from the location identified in the alert. Deleting plaintext from a file or commit does not replace rotation: someone may already have copied it. Do not restore the old value to bring a service back.
After re-enabling the token, check a request within the original authorization scope that has no write side effects and a known expected result. Inspect the first response and actual content. Completing a button action, saving configuration or seeing HTTP 200 does not by itself prove that the full business task has recovered.
If the protected application still returns 401 or 403, check the service-token headers, destination path and Service Auth policy. Keep those application responses separate from 400 from the rotation API and 409 from trying to enable the token before rotation.
What should the recovery handoff record?
Record the alert time, actual rotation and re-enable times, updated callers and verification results. List jobs that still need checking. Retain only redacted states and evidence; do not save or share the real Client Secret.
Mark an unrecovered caller as pending. One successful read does not establish that all retries, pagination or later batch jobs work. The official material provides no recovery-time guarantee and does not say that this change alters the application’s authorization policy.
Sources
Frequently Asked Questions
Who receives a leaked-token email by default?
Current Cloudflare documentation says the platform automatically creates a leaked service-token alert. By default, it emails account Super Administrators and the token creator when their email address is available. Administrators can edit the alert’s recipients. This guide has not checked any account’s alert configuration.
Must every service token with the old format be replaced?
No, not solely because of its format. Current documentation says existing 64-character hexadecimal Client Secrets continue to work. The rotate-before-re-enable sequence here applies to a token reported as leaked; it does not mean every service token has been disabled.
Does a regex match prove that a secret is valid or leaked?
No. The pattern only finds candidates by format. It does not validate the eight-character checksum or show whether the secret is valid, enabled or reported as leaked. Check Cloudflare’s alert and account records.