Changelog

AI Search now supports @cf/zai-org/glm-5.3-flash for text generation. The model has a 1,048,576-token context window and runs on Workers AI.

To configure the model for an AI Search instance, refer to Supported models.

A new GA release for the macOS Cloudflare One Client is now available on the stable releases downloads page.

This hotfix resolves an issue where a small but noticeable percentage of DNS queries fail across platforms.

A new GA release for the Windows Cloudflare One Client is now available on the stable releases downloads page.

Fixed a rare but critical issue where the client could fail to connect or switch organizations due to an invalid registration after switching installed client versions. Additionally, this hotfix resolves an issue where a small but noticeable percentage of DNS queries fail across platforms.

A new GA release for the Linux Cloudflare One Client is now available on the stable releases downloads page.

This hotfix resolves an issue where a small but noticeable percentage of DNS queries fail across platforms.

@cf/zai-org/glm-5.3 is now available on Workers AI. It is Z.ai's flagship agentic coding model, built for long-running, tool-driven development workflows rather than single-turn chat.

GLM-5.3 uses the same base model as GLM-5.2, with every gain coming from post-training. The results are substantial on coding and agentic benchmarks: Z.ai reports ↗ a 50% improvement over GLM-5.2 on its in-house Z.ai Code Bench, and calls GLM-5.3 the most capable open-weights model for coding. On public benchmarks, it scores 88.2 on Terminal Bench 2.1 (up from 81.0), 28.3 on Terminal Bench 3.0 — open-source state of the art, up from 4.6 — 66.9 on DeepSWE (up from 46.2), 78.1 on FrontierSWE (up from 67.5), and 42.5 on SWE-Marathon (up from 19.4). It is also the top-scoring model in Z.ai's comparisons on CyberGym for vulnerability discovery (84.5) and on long-horizon automation tasks like AutomationBench (48.2).

The price-to-performance ratio is the compelling part. On Workers AI, GLM-5.3 costs the same as GLM-5.2 — $1.40 per M input tokens, $0.26 per M cached input tokens, and $4.40 per M output tokens — while roughly doubling GLM-5.2's scores on long-horizon benchmarks like SWE-Marathon, and improving them by more than 6x on Terminal Bench 3.0.

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

Use GLM-5.3 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 model page and pricing.

Durable Objects can have up to ten distinct Dynamic Workers with in-flight requests, increased from four. This limit applies across all concurrent requests to the same Durable Object because they share an input/output (I/O) context. Other Workers can have up to four distinct Dynamic Workers with in-flight requests per request.

Multiple in-flight requests to the same Dynamic Worker count as one toward this limit.

For more information, refer to Dynamic Workers limits.

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.

API Shield JSON Web Token validation now supports symmetric keys that use the HS256, HS384, and HS512 algorithms. You can configure HMAC verification keys in the Cloudflare dashboard or with the Cloudflare API.

Cloudflare never stores symmetric credentials in plaintext. API responses do not include the credential.

Refer to Configure JWT validation via the API for supported key formats and credential requirements.

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.