Changelog

Cloudflare Access service token Client Secrets created on or after August 26, 2026, use the format cfast_[40 alphanumeric characters][8-character checksum]. The prefix and checksum make these credentials easier for secret scanning tools to identify with fewer false positives.

Existing service token secrets continue to work and do not require rotation. Both formats use the same Client ID and the same CF-Access-Client-Id and CF-Access-Client-Secret authentication headers.

For more information, refer to Service tokens.

AI Search now supports six additional Workers AI models for text generation:

These models run on Workers AI, so they do not require an additional provider key. Select a model when creating or updating an AI Search instance in the dashboard or through the API.

For the full list of supported models, refer to Supported models.

You can now create app-scoped API tokens for Flagship. These tokens grant access only to the Flagship apps you select, instead of every app in the account.

When you create a custom token, open the resource dropdown (it defaults to Entire Account) and select Specified Flagship apps. Then choose the app and a Flagship App permission: Evaluate, Read, or Write. Account-wide Flagship Evaluate, Read, and Write permissions still exist when you need access to every app.

Use app-scoped tokens in trusted server-side environments, such as Wrangler, CI, or a backend service that should only touch one app.

To create a token, refer to API tokens or open the app-scoped token form ↗ in the dashboard.

Cloudflare Log Explorer customers can now permanently delete account and zone datasets from the Cloudflare dashboard or API.

Deletion protection is enabled by default to prevent accidental data loss. In the dashboard, go to Manage datasets, disable deletion protection for the dataset, select Delete, and enter the dataset name to confirm.

To delete a dataset through the API, first set deletion_protection to false with the Update an account or zone dataset method. Then use the Delete an account or zone dataset method.

Dataset deletion is irreversible and runs asynchronously. You cannot recreate the same dataset while deletion is in progress.

Cloudflare Enterprise customers using the Azure Functions-based Microsoft Sentinel connector ↗ must migrate to the Cloudflare for Microsoft Sentinel Codeless Connector Framework (CCF) connector ↗ by 2026-09-14.

Microsoft is deprecating the Azure Monitor HTTP Data Collector API. Support for the API ends on 2026-09-14. As a result, Cloudflare will no longer maintain the Azure Functions-based connector after that date.

To migrate, follow the Microsoft Sentinel integration setup guide.

• Download Cloudflare's CCF Sentinel Solution ↗
• Microsoft Sentinel data lake overview ↗
• About the CCF platform ↗

For more information, refer to Microsoft's Azure Monitor HTTP Data Collector API deprecation notice ↗.

Cloudflare Radar expands the Radar Researcher ↗ beta with richer sources and new ways to investigate Internet data.

Radar Researcher responses can now link to relevant Radar pages, reports, and Cloudflare Blog posts.

Select Explain with AI on a URL Scanner report ↗ to have Radar Researcher explain its findings and answer follow-up questions about the scanned site.

Shared conversations now open in fullscreen, while the share URL remains available until you close the panel or start a new conversation.

Open Radar Researcher ↗ to explore these improvements.

This emergency release updates an existing Next.js remote code execution rule to identify CVE-2026-75604 and adds a new rule for remote code execution in the Next.js Image Optimizer via crafted AVIF images.

Key Findings

• CVE-2026-75604 affects Windows-hosted Next.js applications using both the Pages Router and App Router without Cache Components and can lead to unauthenticated remote code execution.

• GHSA-2xp9-vwfh-vxw4 affects the Next.js Image Optimizer and can lead to unauthenticated remote code execution when it optimizes an attacker-controlled AVIF image.

Impact

Next.js recommends updating to version 16.3.3 or 15.5.24 to address these vulnerabilities.

@cf/zai-org/glm-5.3-flash is now available on Workers AI. It is the first natively multimodal model in the GLM-5 series, built on a Mixture-of-Experts architecture with 320B total parameters and 18B active per token.

GLM-5.3 Flash is the first GLM-family model on Workers AI to support multimodal inputs. It outperforms GLM-5.2 across benchmarks and real-world workloads at a lower price, while approaching Claude Opus 4.8 on coding and agentic benchmarks.

GLM-5.3 Flash requires the Workers Paid plan or prepaid AI Gateway credits.

Use GLM-5.3 Flash through the Workers AI binding (env.AI.run()), the REST API, the OpenAI-compatible endpoint, or AI Gateway.

For more information, refer to the GLM-5.3 Flash model page and pricing.

Cloudflare Access administrators can now choose a grace period when rotating a service token secret. Both secrets remain valid during the grace period, giving administrators time to update services without interrupting authentication.

The dashboard offers grace periods from one hour to 30 days. Administrators can also revoke the previous secret immediately. The API accepts an RFC 3339 expiration time for custom rotation schedules.

For configuration instructions, refer to Rotate service token secrets.

Cloudflare Access administrators can now temporarily turn off service tokens without deleting them. A disabled token cannot authenticate, but its configuration remains available so administrators can turn it on again later.

Turning off a token also stops any previous secret in an active rotation grace period. Use this control to contain suspected credential exposure or pause an automated service.

For configuration instructions, refer to Turn a service token on or off.

AI Search supports larger custom metadata values within a shared 10 KiB metadata envelope for each vector. The envelope includes AI Search system metadata and JSON overhead, so it is not a per-field limit. The first 64 UTF-8 bytes of each indexed string remain filterable.

For details, refer to Metadata attributes.

MCP server portals support the stateless MCP 2026-07-28 specification for client and upstream server connections.

The portal's /mcp endpoint automatically accepts stateless MCP 2026-07-28 requests and earlier 2025 Streamable HTTP clients. When the portal connects to an upstream Streamable HTTP server, it checks for MCP 2026-07-28 support and falls back to the 2025 handshake when needed. Client and upstream protocol selection are independent, so clients and servers can upgrade separately without portal configuration changes.

SSE connections continue to use the legacy protocol. For details, refer to MCP server portal transport and protocol compatibility.

By default, an alarm interrupted by ctx.abort() retries after the Durable Object resets. Pass { retryAlarm: false } when the alarm should stop instead:

import { DurableObject } from "cloudflare:workers";

export class CleanupTask extends DurableObject {
	async alarm() {
		await this.ctx.storage.deleteAll();

		this.ctx.abort("Cleanup complete", { retryAlarm: false });
	}
}

import { DurableObject } from "cloudflare:workers";

export class CleanupTask extends DurableObject {
	async alarm(): Promise<void> {
		await this.ctx.storage.deleteAll();

		this.ctx.abort("Cleanup complete", { retryAlarm: false });
	}
}

For example, an alarm that deletes its storage can use this option to avoid repeating the cleanup or re-running the Durable Object constructor.

Alarms can run concurrently with other requests to the same Durable Object. If another request calls ctx.abort() while an alarm is running, the retryAlarm option on that call also controls whether the alarm retries.

The default retry prevents an unrelated request from permanently canceling the alarm. Set retryAlarm: false on every abort path that should stop an in-progress alarm, not only on calls from the alarm handler. Existing calls to ctx.abort() keep retrying alarms.

For local development, retryAlarm requires Wrangler 4.126.0 or later.

For more information, refer to ctx.abort().

This release moves four new detections from Log to Block, merges the XSS, HTML Injection - Script Tag - Beta rule into the original rule, and adds a Generic Rules - Remote Code Execution rule in Block mode.

Key Findings

• Four new detections move from Log to Block: HTTP/2 Request Smuggling - Request Body Anomaly and XSS - JavaScript Event Handler Coercion across Headers, Body, and URI.

• The XSS, HTML Injection - Script Tag - Beta rule is merged into the original rule.

• A Generic Rules - Remote Code Execution detection is added in Block mode.

When you register a Cloudflare One Virtual Appliance, you can now select your hypervisor and download the appliance directly from the dashboard — no need to look up asset URLs.

• On the Connectors page, select Add an appliance, choose Virtual appliance, then select your hypervisor: VMware ESXi, Proxmox, or libvirt/KVM.
• Download the OVA image (VMware ESXi) or the install script (Proxmox and libvirt/KVM) for the selected hypervisor.
• Use View setup guide to open deployment instructions for your platform.

This complements the existing self-serve registration and license key generation in the dashboard.

For details, refer to Configure a Cloudflare One Virtual Appliance.

Radar adds an ASPA validation tool ↗ to its Routing section ↗. Enter a BGP AS_PATH and the tool checks it against the Autonomous System Provider Authorization (ASPA) ↗ records currently published in the RPKI, returning a verdict of Valid, Invalid, or Unknown. An Invalid verdict means no chain of provider authorizations covers the whole path, which is the signature of a route leak.

Validation follows draft-ietf-sidrops-aspa-verification ↗, so verdicts match those produced by validators implementing the same draft. The draft is still a work in progress and not yet an RFC.

Paths are read in BGP wire order: the rightmost AS is the origin, and the leftmost AS is the one closest to the collector or router that observed the route. AS numbers can be separated by spaces, commas, or hyphens, with or without an AS prefix. The full ASPA snapshot is loaded into the browser once, so the verdict, graph, and trace update as the path is edited, with no further requests. A set of example paths covers the interesting cases, including a route leak with an AS0 ASPA, where an AS declares that it has no providers at all.

The draft defines two verification algorithms that differ only in whether a down-ramp is permitted:

• Upstream (section 5.4 ↗) — for routes received from a customer, peer, route server client, or route server. Only an up-ramp is permitted.
• Downstream (section 5.5 ↗) — for routes received from a provider. Both an up-ramp and a down-ramp are permitted.

An up-ramp is the run of consecutive customer-to-provider hops from the origin to the apex of the path, and a down-ramp is the equivalent run from the announcing neighbor back to that apex. The tool evaluates both algorithms at once and labels each with its verdict, so a path that is legitimate when received from one session type and a leak when received from another is visible without switching modes. Selecting an algorithm drives the graph and the trace.

The ASPA validation graph draws the path hop by hop, labeling each AS with its role, whether it publishes an ASPA, and how many providers that ASPA authorizes. Every hop is marked Provider+, Not Provider+, or No attestation, and the maximum and minimum bounds of each ramp are drawn against the length of the path. Hops that no ramp reaches are highlighted, because a path the ramps cannot cover end to end is Invalid. The accompanying ASPA records table lists every AS in the path with its ASPA status and its authorized providers, each linked to its Radar AS page.

The Algorithm step by step section shows the derivation rather than just the answer. Two columns run the same scans under different stopping rules: the upper bounds, which test for Invalid and stop only on Not Provider+, and the lower bounds, which test for Unknown and also stop on No Attestation. A hop is Not Provider+ when the AS publishes an ASPA that does not list the next AS as a provider, and No Attestation when the AS publishes no ASPA at all. Each column lists the outcome for every hop scanned, marks where the scan stopped, gives the resulting ramp length, and then evaluates the verdict rule with the numbers filled in.

The path and the selected algorithm are kept in the URL, so a link reproduces a result exactly — for example, this route leak with an AS0 ASPA ↗. Appending &mode=upstream pins the link to the upstream algorithm. The graph is a standard Radar widget, so it can also be embedded or shared as an image.

The records behind the tool are the same ones served by the /bgp/rpki/aspa/snapshot endpoint of the ASPA API, and the number of records loaded and the snapshot timestamp are shown alongside the input.

Try the ASPA validation tool ↗ with a path of your own.

Wrangler and the Cloudflare API MCP server now use optional OAuth scopes. During authorization, you can choose which optional scopes to grant instead of approving every scope requested by each client.

The consent dialog now includes the option to edit the permissions you grant to Wrangler or the Cloudflare API MCP server:

You can then choose which specific permissions to grant:

Required scopes remain selected. Choosing fewer optional scopes limits each tool's access to the permissions needed for your workflow.

If a command or tool call needs a scope that you declined, reauthorize the client and grant that scope.

For more information, refer to wrangler login and Edit optional permissions.

Cloudflare CASB is an API-based (agentless) tool that continuously scans your SaaS and cloud applications for security misconfigurations and data exposure. You can now use CASB remediation policies to automatically fix a finding or send a webhook the moment CASB detects it, without manual triage.

A policy can perform a first-party remediation action directly against the SaaS integration API. When a policy triggers, Cloudflare revokes the external sharing configuration without human intervention.

Remediation is currently supported for file-sharing findings in Microsoft 365 and Google Workspace. Support for additional finding types and integrations is coming soon. For the full list of supported finding types, refer to Run remediations in the CASB remediation policies documentation.

A policy can send posture finding data to Slack, ServiceNow, or any other webhook destination. Webhook actions are supported for all posture finding types across CASB integrations.

A single policy can perform both actions: remediate a finding and send a webhook.

1. In Cloudflare One ↗, go to Cloud & SaaS findings > Policies.
2. Select Create a policy.
3. Under Basic information, enter a Policy name and, optionally, a Description.
4. Under Choose how you want to trigger the policy, select a Vendor, Integration, and Finding type.
5. Under Define what to do with findings that match your trigger, choose Run Remediation, Send webhooks, or both.
6. Under Status, turn on Enable policy.
7. Select Create policy.

• Learn how to create and manage CASB remediation policies in Cloudflare One.
• Configure CASB webhooks as a policy destination.
• Learn how to manage findings in Cloudflare One.

CASB remediation policies are now available in Cloudflare One.

Test scan lets you check how Data Loss Prevention (DLP) evaluates sample content before you apply a profile to production traffic. Paste text, upload a file, or upload a HAR file, then select the profiles you want to test.

Test scan sends content directly to the DLP scanner. Gateway policies are not evaluated, no traffic passes through Gateway, and no Gateway activity logs are created. Results include matched profiles, detection entries, confidence levels, match context, proximity keywords, file metadata, antivirus status, and OCR output.

Test scan is available to all Cloudflare Zero Trust customers. Profile availability depends on your Zero Trust plan.

For more details, refer to the Test scan documentation.

Cloudflare API 403 Forbidden responses now include a documentation_url field that links directly to the API documentation for the endpoint that was denied. This gives developers, administrators, and agents an immediate path to the relevant docs with role information instead of guessing at which role or permission they are missing for that endpoint.

What's New

Enriched 403 error responses: When a Cloudflare API request is denied, the error response now includes a documentation_url field that points to the documentation for that specific endpoint. Contextual 403 responses are now available across nearly all Cloudflare product APIs.

Faster troubleshooting: The linked API docs surface the roles required for each endpoint, making it easier to self-serve access issues.

Better support for tools and agents: Agents can use the \documentation_url` field to immediately fetch the endpoint's documentation from the 403 error response, identify the accepted permissions for the denied action, and use that context to drive third-party approval workflows.`

Example 403 response:

{
  "success": false,
  "errors": [
    {
      "code": 10000,
      "message": "Forbidden",
      "documentation_url": "https://developers.cloudflare.com/api/resources/workers/subresources/beta/subresources/workers/methods/list"
    }
  ],
  "messages": [],
  "result": null
}

For more info:

• Browse the Cloudflare API documentation
• Review Cloudflare roles
• Review API token permissions

Cloudflare Dashboard users can now save login profiles on a device for faster sign-in on future visits.

What's New

Save login profiles on a device: After a successful sign-in, users can choose to save a login profile on that device. Saved profiles store the email address, login method, and last-used profile locally in the browser.

Faster sign-in for returning users: Saved profiles appear directly on the login page. Selecting one can prefill the email field for password logins or resume the associated SSO or social login flow.

Up to five login profiles can be saved per device, and saved profiles can be removed from the profile list at any time.

For more info:

• Log in to Cloudflare
• Set up dashboard SSO

Dashboard SCIM now supports replacing groups using HTTP PUT, as defined by RFC 7644 section 3.5.1 ↗. This allows identity providers to synchronize a group's full state, including its display name, external ID, and members, in a single request.

What's New

Group replacement via PUT: Full-state group synchronization improves compatibility with identity providers that use replacement semantics and helps keep Cloudflare groups aligned with their source identity provider.

For more information:

• SCIM provisioning overview

Cloudflare Web Analytics (Real User Monitoring) is rolling out accuracy improvements to client-side soft navigations.

This change may alter the volume of pageviews reported in the dashboard and GraphQL API, though the extent depends on your front-end architecture and visitor traffic patterns.

Single Page Applications (SPAs)—such as websites built with React, Angular, Vue, or Svelte—predominantly use soft navigations. Soft navigations avoid fully unloading the current page and rendering the next one from scratch as visitors navigate.

Any client-side navigation counts as a soft navigation, including navigations intercepted by the Navigation API ↗ or triggered by the History API ↗. This means a non-SPA website can have soft navigation activity if its implementation uses these APIs.

The main improvement comes from Google Chrome's new Soft Navigation API ↗. It natively measures Largest Contentful Paint (LCP) on soft navigations, removing a blind spot in perceived loading speed across pageviews.

We've extended our navigationType values to segment these different types of navigations:

Prior to this change, we only used History API and all navigations were bucketed into navigate.

For more information, refer to the Navigation Types and Web Analytics SPA documentation pages.

Browser Run lets you automate headless browsers on Cloudflare's global network. Run full browser sessions for interactive workflows, or use Quick Actions for one-request tasks such as screenshots, PDFs, and capturing page content.

If you are on the Workers Paid plan, your default limits are now higher:

You can now run hundreds of browser sessions in parallel, launch new browsers faster, and process three times as many Quick Actions per second. These published limits are defaults, not maximums. If your workload needs more more concurrent browsers, request higher limits ↗.