Skip to content

Changelog

New updates and improvements at Cloudflare.

You can now enable Access on a Worker or all Workers at once

You now have two new ways to protect your Workers with Cloudflare Access.

Protect an application across all its domains at once

Until now, if a Worker was reachable on a route, a Custom Domain, and a workers.dev URL, you had to manually add each one to an Access application and keep the list in sync whenever routes or domains changed.

Now, Access attaches the policy to the Worker itself, so every associated domain and preview URL stays protected even when its routes or domains change.

Access setting for protecting a single Worker

Protect all new and existing Workers by default

Make all Workers private by default, so every existing and newly created Worker requires sign-in before anyone can reach it.

Account-wide Access setting that protects all Workers

If a specific Worker should remain publicly accessible, add a Worker-level bypass to exempt it.

Make a Worker public when all Workers are protected

Whether you protect a single application or all Workers at once, you can choose whether to protect preview deployments only or both previews and production, and control who can sign in by Cloudflare account membership, email address, or email domain.

For more advanced policy options, edit the policy in Zero Trust.

Access policy configuration for controlling who can sign in

View all of your Worker Access policies

You can view and manage all of your Access policies in the Access tab of the Workers & Pages section in the dashboard.

Access tab showing all configured Access policies

See who is accessing your Worker

When Access is enabled on your Worker, every authenticated request includes ctx.access. Call ctx.access.getIdentity() to get the user's email, name, and groups — no manual JWT validation required.

export default {
  async fetch(request, env, ctx) {
    if (!ctx.access) {
      return new Response("Access did not run", { status: 401 });
    }

    const identity = await ctx.access.getIdentity();
    return Response.json({ aud: ctx.access.aud, email: identity?.email });
  },
};

Test Access locally

You can now test Cloudflare Access locally with wrangler dev. Add a dev block to your wrangler.jsonc:

{
  "access": {
    "dev": {
      "aud": "my-app",
      "identity": { "email": "admin@example.com" }
    }
  }
}

Your Worker will receive this identity through ctx.access and ctx.access.getIdentity(), letting you test authenticated and unauthenticated flows without deploying. Remove the dev block to simulate unauthenticated requests.

API and programmatic access

You can also set up these policies through the Workers API instead of the dashboard.

Data localization support for Artifacts

Artifacts now supports jurisdictions, allowing you to select the European Union or the United States as the only location where repo data is stored and processed.

Select a jurisdiction when you create a namespace. Every repo in that namespace automatically uses the selected jurisdiction.

curl --request POST \
  "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/artifacts/namespaces" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{
    "namespace": "my-eu-namespace",
    "jurisdiction": "eu"
  }'

Jurisdictions cannot be changed after namespace creation. If you omit the jurisdiction, Artifacts creates an unrestricted namespace.

For supported jurisdictions and usage details, refer to Data localization.

Detect and control software package downloads with package registry security

Cloudflare Gateway can now detect software package downloads and give you policy control over supply chain traffic. When a developer or CI/CD pipeline downloads a package through Gateway, the proxy identifies the registry protocol from the request URL and extracts the package ecosystem, name, version, and namespace. You can then write HTTP policies using pkg.* selectors to allow or block package downloads.

Supported ecosystems

Gateway detects package downloads for the following ecosystems:

Ecosystem Namespace
npm Scope (for example, @babel)
PyPI --
RubyGems --
Cargo --
Go Module path
Maven Group ID
NuGet --

Selectors

In the dashboard, select Package Ecosystem to access the package registry selectors. After selecting a single ecosystem, nested fields for package name, version, and namespace become available. Five pkg.* selectors are available for HTTP policies with the Allow and Block actions:

Selector Description
pkg.ecosystem The package ecosystem detected from the request URL.
pkg.name The package name extracted from the download URL.
pkg.version The package version, with support for ecosystem-aware comparison operators.
pkg.namespace The package namespace, when the ecosystem supports one.
pkg.purl The Package URL (PURL) derived from the detected coordinates. Available in the API only.

Detection is based on the registry protocol rather than the hostname, so it works the same way whether traffic goes to a public registry, a corporate proxy such as Artifactory or Nexus, or a self-hosted mirror.

Package registry security requires TLS decryption to be turned on.

For more information, refer to Package registry security.

Control Realtime SFU DataChannel delivery

Cloudflare Realtime SFU is a WebRTC selective forwarding unit that runs on Cloudflare's global network. It forwards audio, video, and application data between WebRTC clients without requiring you to manage SFU infrastructure or regions.

DataChannels are WebRTC channels for application messages. A client publishes a named DataChannel to Realtime SFU, and the SFU forwards its messages to every client that subscribes to that channel. Use DataChannels for low-latency payloads such as chat messages, game state, sensor updates, and control events.

What changed

Realtime SFU DataChannels now support unordered and partially reliable delivery. DataChannels remain reliable and ordered by default, so existing channels keep their current behavior.

With ordered delivery, a delayed message can block later messages. For game state or sensor updates, recent data may be more useful than recovering an older message. Unordered delivery lets later messages proceed, while partial reliability limits retransmission attempts or delivery time.

Choose delivery behavior

Delivery settings answer two questions: whether newer messages can bypass a delayed message, and when the transport should stop retrying delivery.

Choose the policy that matches how long your payload remains useful:

Goal Settings Use when
Reliable, ordered delivery (default) Omit ordered, maxRetransmits, and maxPacketLifeTime Messages remain useful and must arrive in order
Reliable, unordered delivery Set ordered: false; omit both retry fields Messages remain useful, but later messages should not wait for earlier messages
No retries or ordering Set ordered: false and maxRetransmits: 0 The application tolerates message loss and discards out-of-date updates
Limited retries Set maxRetransmits: <COUNT> Brief recovery is useful, but repeated retries are not
Time-bounded delivery Set maxPacketLifeTime: <MILLISECONDS> A message loses value after a known time window

ordered controls ordering independently from retries. maxRetransmits and maxPacketLifeTime are alternative retry budgets, so set at most one for each channel. Omit both for reliable delivery, whether ordered or unordered.

Apply the policy end to end

Realtime DataChannels use negotiated IDs, so browsers do not receive delivery settings from the remote peer. Apply the same settings when the publisher creates the local channel, each subscriber pulls the remote channel, and each client calls createDataChannel().

The following example configures unordered delivery with no retransmissions. It begins after you establish a DataChannel transport on both sessions and complete any required SDP exchange. Run the API requests from your backend with APP_ID, APP_TOKEN, PUBLISHER_SESSION_ID, and SUBSCRIBER_SESSION_ID set in your environment.

  1. On the publisher session, create the local DataChannel:
curl --request POST \
	--url "https://rtc.live.cloudflare.com/v1/apps/$APP_ID/sessions/$PUBLISHER_SESSION_ID/datachannels/new" \
	--header "Authorization: Bearer $APP_TOKEN" \
	--header "Content-Type: application/json" \
	--data @- <<EOF
{
	"dataChannels": [
		{
			"location": "local",
			"dataChannelName": "player-state",
			"ordered": false,
			"maxRetransmits": 0
		}
	]
}
EOF
  1. On each subscriber session, pull the remote DataChannel with the same delivery settings:
curl --request POST \
	--url "https://rtc.live.cloudflare.com/v1/apps/$APP_ID/sessions/$SUBSCRIBER_SESSION_ID/datachannels/new" \
	--header "Authorization: Bearer $APP_TOKEN" \
	--header "Content-Type: application/json" \
	--data @- <<EOF
{
	"dataChannels": [
		{
			"location": "remote",
			"sessionId": "$PUBLISHER_SESSION_ID",
			"dataChannelName": "player-state",
			"ordered": false,
			"maxRetransmits": 0
		}
	]
}
EOF
  1. In the publisher and subscriber clients, create the negotiated browser DataChannel with the same settings. In this example, pc is the active RTCPeerConnection, and channelId is the ID returned by the corresponding API request:
const channel = pc.createDataChannel("player-state", {
	negotiated: true,
	id: channelId,
	ordered: false,
	maxRetransmits: 0,
});

Certificate Transparency Monitoring is now Generally Available

Certificate Transparency Monitoring is now generally available across all Cloudflare plans.

Alerts for certificates Cloudflare issues on your behalf (Universal SSL renewals, backup certificates, Advanced Certificate Manager, Total TLS) are now automatically filtered out. Alert emails are also clearer and more actionable, with structured certificate details and a direct link to manage CT Monitoring in the Cloudflare dashboard.

Learn more in the launch blog post or the CT Monitoring docs.

Block emails by content with blocked content rules

Cloudflare Email security now lets administrators write their own content-based blocking rules. A new Blocked content area under Policies & rules lets you define a plaintext string or a regular expression, choose whether to scan the message subject, body, or both, and automatically block any message that matches.

  • Create rules using either plaintext matches or regular expressions — useful for blocking targeted phishing campaigns, known-bad phrases, or content patterns unique to your organization.
  • Choose the search location for each rule: subject, body, or subject and body.
  • Use the built-in regular expression checker to validate your pattern against sample text before saving, so you can confirm the rule matches what you expect and avoid false positives.
  • Matching messages are marked with a malicious disposition and prevented from reaching users' inboxes.

Blocked content rules currently only support the block action.

This feature is available for the following Email security packages:

  • Enterprise
  • Enterprise + PhishGuard

To get started, refer to Blocked content.

Independent MFA supports FIDO2 for infrastructure applications

Infrastructure applications support independent multi-factor authentication (MFA) with FIDO2 keys. You can allow ssh_fido2_key, piv_key, or both in application-level and policy-level MFA settings.

Users enroll FIDO2 keys through the App Launcher and connect with the generated SSH identity. FIDO2 keys for SSH are separate from browser-based WebAuthn security keys and Personal Identity Verification (PIV) keys.

For setup instructions, refer to Enroll a FIDO2 key for infrastructure apps and Configure MFA for infrastructure applications.

MCP protocol detection and AI Security dashboard

Cloudflare Gateway now automatically detects Model Context Protocol (MCP) traffic flowing through your network. MCP is the standard protocol used by AI agents to connect to external tools and data sources. Gateway identifies MCP requests by inspecting protocol-specific headers and payload characteristics.

MCP policy selector

A new Is MCP selector (experimental.is_mcp) is available in HTTP policies. Use this selector to build Gateway rules that allow, block, or isolate MCP traffic.

This selector is currently in beta and may change before general availability.

For example, the following policy blocks MCP traffic that does not arrive through an approved MCP portal:

Selector Operator Value Logic Action
Is MCP is True And Block
Traffic Source is not MCP portal
Example Gateway policy that blocks MCP traffic not arriving through an MCP portal

AI security report

A new AI security report dashboard under Insights & Logs > Dashboards provides visibility into MCP usage across your organization. The dashboard includes:

  • Total MCP request volume, unique users, and unique MCP servers
  • A timeseries chart of unique MCP servers observed over time
  • A summary of Gateway policies that target MCP traffic
AI security report dashboard showing MCP detection data including total MCP requests, users, servers, and Gateway policies for MCP

For more information, refer to HTTP policies.

Traffic Source selector in Gateway policies

Gateway HTTP and Network policies now include a Traffic Source selector that identifies how traffic reaches Cloudflare. This allows administrators to write policies that target specific on-ramp methods - for example, applying different rules to traffic arriving via the Cloudflare One Client compared to traffic routed through an MCP portal or a proxy endpoint.

Available traffic source values

UI name API value Description
Device client device_client Traffic from the Cloudflare One Client (WARP)
Mesh mesh Traffic from a Cloudflare Mesh connector
Cloudflare WAN cloudflare_wan Traffic from Cloudflare WAN (Magic WAN)
Clientless RDP clientless_rdp Traffic from a clientless RDP session
Proxy endpoint proxy_endpoint Traffic from a proxy endpoint (PAC file)
Clientless Browser Isolation agentless_biso Traffic from clientless Browser Isolation
MCP portal mcp_portal Traffic from an MCP portal

The selector uses the net.onramp.type API field in both HTTP and Network policies.

UI name API example
Traffic Source net.onramp.type == "device_client"

Browser Isolation selector

A Browser Isolation selector is also available in Network and HTTP policies. This selector identifies whether the current session is running inside Remote Browser Isolation, allowing administrators to apply different policy behavior to isolated traffic.

UI name API example
Browser Isolation net.is_isolated == true

For more information, refer to HTTP policies and Network policies.

New Cloudflare Status page

The Cloudflare Status page at www.cloudflarestatus.com has been rebuilt. It is available at the same address, and every previously documented Status API endpoint remains supported, so existing bookmarks, integrations, and monitoring continue to work.

Notifications that fire even when Cloudflare is down

The status page now has its own notification system, delivered independently of Cloudflare infrastructure. You can subscribe by email, webhook, Slack, Discord, or Google Chat.

The Maintenance Notification and Incident Alerts in Cloudflare Notifications remain supported, and deliver to the destinations already configured on your account.

Markdown for AI agents

Every page on the status page returns Markdown when requested with an Accept: text/markdown header, so agents can read the current status without parsing HTML:

curl -H "Accept: text/markdown" https://www.cloudflarestatus.com/locations

Separate feeds for incidents and maintenance

Incidents and maintenance are published as separate feeds, each available in RSS and Atom, so you can subscribe to one without the other:

https://www.cloudflarestatus.com/api/v3/incidents.rss
https://www.cloudflarestatus.com/api/v3/incidents.atom
https://www.cloudflarestatus.com/api/v3/maintenance.rss
https://www.cloudflarestatus.com/api/v3/maintenance.atom

For more information, refer to Cloudflare Status.

Hostname routing is now generally available, with a new public IP range for initial resolved IPs

Hostname routing is now generally available. Instead of managing static IP lists and routes, you can route traffic by hostname across multiple Cloudflare One connectors:

  • Cloudflare Tunnel: route a private hostname (for example, wiki.internal.local) to a private application behind your tunnel, or a public hostname (for example, bank.example.com) to egress through a specific tunnel and anchor traffic to a dedicated exit node.
  • Cloudflare Mesh: attract a private or public hostname's traffic to a Mesh node.

Alongside GA, the default IPv4 range used for initial resolved IPs (also called token IPs) is changing from a Carrier-Grade NAT (CGNAT) range to a public Cloudflare-owned range:

  • IPv4: 172.64.128.0/20
  • IPv6: 2606:4700:0cf1:4000::/64

This is the default range. You can configure a custom initial resolved IP range for IPv4 if it conflicts with your existing network.

Why this is changing: Starting with Chrome 142, Local Network Access (LNA) restrictions block background requests to CGNAT addresses (100.64.0.0/10), which included the previous initial resolved IP default (100.80.0.0/16). LNA is implemented at the Chromium engine level, so it affects all Chromium-based browsers (for example, Microsoft Edge, Brave, and Opera), not only Google Chrome. This could silently break hostname-based Gateway features for users of these browsers, and required Chrome Enterprise policy workarounds. The new default range is public Cloudflare address space, so it is not affected by this restriction.

What is affected: Initial resolved IPs are used by several features that associate a DNS query with the network connection that follows it:

You can check your account's current range, or configure a custom range, at any time from Zero Trust > Team & Resources > Devices > Device profiles, or using the Initial Resolved IP Subnet API.

For full instructions, refer to Configure initial resolved IPs. The IPv6 range (2606:4700:0cf1:4000::/64) is unchanged and is not affected by this restriction.

If you were relying on a Chrome Enterprise policy workaround (such as LocalNetworkAccessRestrictionsTemporaryOptOut) while your account was still on the legacy CGNAT-based range, refer to Google Chrome restricts access to private hostnames for next steps.

WAF Release - 2026-08-11

This release introduces new protection for a remote code execution vulnerability in vBulletin and improves two existing detections.

Key Findings

  • A new detection provides protection against vBulletin CVE-2026-61511.
  • Two existing detections have been improved to strengthen coverage.

Impact

Successful exploitation of CVE-2026-61511 may lead to remote code execution on affected vBulletin systems, potentially resulting in unauthorized access, data exposure, service disruption, and broader compromise of the hosting environment. Administrators are strongly encouraged to apply vendor updates and recommended mitigations.

RulesetRule IDLegacy Rule IDDescriptionPrevious ActionNew ActionComments
Cloudflare Managed RulesetN/AvBulletin - Remote Code Execution - CVE:CVE-2026-61511LogBlockThis is a new detection.
Cloudflare Managed RulesetN/AVersion Control - Information Disclosure - BetaLogBlockThis rule is merged into the original rule "Version Control - Information Disclosure" (ID: )
Cloudflare Managed RulesetN/AvBulletin - Code Injection - Invalid image format - CVE:CVE-2019-17132 - BetaLogBlockThis rule is merged into the original rule "vBulletin - Code Injection - Invalid image format - CVE:CVE-2019-17132" (ID: )

Stream live logs from Cloudflare Tunnel in the dashboard

Real-time Tunnel log streaming is now available in the Cloudflare dashboard under Networking > Tunnels. This brings the same live debugging capability previously only available in the Cloudflare One dashboard, including multi-connector aggregated streaming for high-availability deployments.

Stream live logs from a tunnel in the Cloudflare dashboard

In the tunnel detail view, a new Live logs tab lets you:

  • Stream logs from single or multiple connectors — In highly available deployments with multiple cloudflared replicas, logs from all connectors are merged into a single stream grouped by hostname, making it easy to identify which host machine produced each log entry.
  • Filter by log level, event type, and HTTP method — Narrow the stream to only the events you care about (HTTP, TCP, UDP, or cloudflared internal), at any log level.
Go to Tunnels ↗

For more information, refer to Monitor tunnels and Tunnel log streams.

Turnstile Spin is now generally available

Turnstile Spin is now generally available with three setup paths for creating a Turnstile widget and wiring canonical server-side siteverify into your existing backend. Start in the dashboard, with Wrangler, or from your AI coding agent. All three paths create the same widget. You can complete the integration by hand or have your agent embed the widget, wire siteverify, and validate it.

Server-side verification

Turnstile setup has two parts: embed the widget in your frontend, then call siteverify from your backend. Without the second part, the widget appears on the page but does not protect the request.

  • The skill includes insertion snippets for Next.js (App Router and Pages Router), Astro, SvelteKit, Hugo, and vanilla HTML. For other frameworks, the agent proposes a generic pattern and asks you to confirm it first.
  • The Turnstile dashboard flags existing widgets with no matching siteverify traffic. Select Fix with Spin to copy a prompt that guides your agent through wiring siteverify into your backend.
  • Before finishing, the agent runs a real Turnstile token through your protected endpoint, checks that it passes, then replays the token to confirm the endpoint rejects it on the second try. If a check fails, the agent stops and shows you where.

Run Spin

You can run Spin three ways:

  • In the Turnstile dashboard, select Set up with Spin, enter your domains, then select Set up. Spin creates the widget and returns the sitekey, secret, and a prompt for your agent.
  • From the Wrangler CLI, run wrangler turnstile widget create. Wrangler prints the sitekey and secret. You wire the frontend and siteverify by hand.
  • From your AI coding agent, paste the Spin prompt into Claude Code, Cursor, Codex, OpenCode, or GitHub Copilot Chat. Your agent fetches the skill, creates the widget, then embeds it and wires siteverify.

To get started, refer to the Turnstile Spin documentation.

Workers AI and AI Gateway unify model access and billing

Workers AI and AI Gateway now provide a unified path for accessing models and managing inference traffic. Use the same AI binding and REST API to call models hosted on Workers AI or by supported third-party providers, with AI Gateway providing observability, logging, caching, security, and billing controls.

Unified entrypoints and observability

The AI binding supports both Workers AI and third-party models through env.AI.run(). The REST API provides shared /ai/ endpoints with Cloudflare authentication across providers.

Route a Workers AI request through AI Gateway by specifying a gateway ID. Use default to automatically create a gateway on the first authenticated request, or specify an existing gateway to separate applications and workloads:

const response = await env.AI.run(
	"@cf/zai-org/glm-5.2",
	{
		messages: [{ role: "user", content: "What is the capital of France?" }],
	},
	{
		gateway: { id: "default" },
	},
);
const response = await env.AI.run(
	"@cf/zai-org/glm-5.2",
	{
		messages: [{ role: "user", content: "What is the capital of France?" }],
	},
	{
		gateway: { id: "default" },
	},
);

Requests routed through AI Gateway can be logged and included in analytics for request volume, errors, latency, token usage, and costs. You can also configure controls such as caching, rate limiting, and request retries on the gateway.

Unified billing and higher rate limits

You can now use prepaid AI Gateway credits to pay for Workers AI inference. This provides one credit balance for Workers AI and supported third-party model providers. To use credits for Workers AI, set the gateway's Workers AI billing setting to Unified billing. Workers AI requests routed through that gateway deduct from your credit balance in real time.

Prepaid credits also provide access to the following Workers AI frontier models without requiring the Workers Paid plan. Each frontier Workers AI model has a rate limit of 50 requests per minute per account, per model when billed with AI Gateway credits, compared to 20 requests per minute through standard Workers AI billing:

These limits are designed for typical agentic and coding workloads, where requests to frontier models can take longer to complete.

For details, refer to Workers AI limits, Workers AI pricing, Unified Billing, and the AI Gateway model catalog.

MySQL support in Hyperdrive is now generally available

Support for MySQL in Hyperdrive is now generally available. You can connect to any MySQL database from your Workers using Hyperdrive.

Hyperdrive makes your regional, MySQL databases fast when connecting from Cloudflare Workers. It eliminates unnecessary network roundtrips during connection setup, pools database connections globally, and can cache query results to provide the fastest possible response times.

You can connect using your existing drivers, ORMs, and query builders with Hyperdrive's secure credentials, with no code changes required. MySQL support is available at the same pricing as Postgres.

import { createConnection } from "mysql2/promise";

export default {
	async fetch(request, env, ctx) {
		const connection = await createConnection({
			host: env.HYPERDRIVE.host,
			user: env.HYPERDRIVE.user,
			password: env.HYPERDRIVE.password,
			database: env.HYPERDRIVE.database,
			port: env.HYPERDRIVE.port,
			disableEval: true, // Required for Workers compatibility
		});

		const [results, fields] = await connection.query("SHOW tables;");

		ctx.waitUntil(connection.end());

		return new Response(JSON.stringify({ results, fields }), {
			headers: {
				"Content-Type": "application/json",
				"Access-Control-Allow-Origin": "*",
			},
		});
	},
};
import { createConnection } from "mysql2/promise";

export interface Env {
	HYPERDRIVE: Hyperdrive;
}

export default {
	async fetch(request, env, ctx): Promise<Response> {
		const connection = await createConnection({
			host: env.HYPERDRIVE.host,
			user: env.HYPERDRIVE.user,
			password: env.HYPERDRIVE.password,
			database: env.HYPERDRIVE.database,
			port: env.HYPERDRIVE.port,
			disableEval: true, // Required for Workers compatibility
		});

		const [results, fields] = await connection.query("SHOW tables;");

		ctx.waitUntil(connection.end());

		return new Response(JSON.stringify({ results, fields }), {
			headers: {
				"Content-Type": "application/json",
				"Access-Control-Allow-Origin": "*",
			},
		});
	},
} satisfies ExportedHandler<Env>;

Learn more about how Hyperdrive works and get started building Workers that connect to MySQL with Hyperdrive.

Container image for Cloudflare Mesh

Cloudflare Mesh nodes can now run as Docker containers. The cloudflare/mesh image is available on Docker Hub for Docker Compose, Kubernetes, and any OCI-compatible runtime — no host-level package installation required.

The image supports amd64 and arm64 architectures and includes built-in source NAT so return traffic routes correctly without VPC route table changes.

Deployment patterns

  • Docker Compose — add a cloudflare-mesh service to your compose.yaml and connect your entire stack to a private network.
  • Kubernetes StatefulSet — deploy a standalone Mesh node with persistent registration state.
  • Kubernetes sidecar — add the Mesh image as a sidecar container in a Pod to connect an application to Cloudflare without application changes.
  • CI/CD — pull the image in a pipeline step, join the Mesh, run integration tests against private infrastructure, and tear down. The node disappears when the container exits.

For high availability, run multiple replicas with the same Mesh node token. Cloudflare operates replicas in active-passive mode with automatic failover.

Go to Mesh ↗

For setup steps, runtime configuration, and deployment examples, refer to Run Mesh in Docker / Kubernetes.

AS-level connectivity and upstream providers on Cloudflare Radar

Radar expands its Routing section with two widgets on AS pages, such as AS13335, that describe how a network reaches the rest of the Internet: the paths it takes toward the Tier-1 networks, and the mix of direct upstreams carrying its routes. Both are derived from RouteViews RIB snapshots, unioned across selected collectors.

AS-level connectivity

The AS-level connectivity graph aggregates the BGP paths an AS uses to reach the Tier-1 networks, unioned across all the prefixes it announces, as observed by selected RouteViews collectors. It reads from left to right, starting at the queried AS and ending at the Tier-1 networks, and each node is labeled with its AS number, country, and organization name. Tier-1 nodes are marked so they stand apart from the intermediate networks that lead to them.

By default, the graph shows the network's direct connections to Tier-1 networks plus the indirect paths, which keeps the view readable. A Show full paths toggle expands it to every observed path, including transit through Tier-1 networks the AS already connects to. An IP version selector switches between IPv4 and IPv6, because the paths reaching Tier-1 networks may differ between the two address families.

AS-level connectivity graph for AS13335, showing Tier-1 networks it reaches directly alongside paths that reach others through intermediate networks

This is the AS-level counterpart to the Real-time connectivity graph on prefix pages, such as the one for 1.1.1.0/24. Instead of covering a single prefix, it covers the union of paths for all prefixes an AS announces, which makes it a fast way to read a network's transit hierarchy: which providers it depends on, how many hops separate it from the core, and whether its paths to the core are diverse or concentrated. For more information on the prefix-level graph, refer to BGP real-time routes.

Upstream providers

The Upstream providers widget tracks the share of an AS's observed paths carried by each of its direct upstream networks over time, drawn as a stacked area chart. Up to 10 upstreams appear as their own series and the remaining ones are grouped into Other. Transit changes such as adding a provider, dropping one, or moving traffic between them appear as movement between bands rather than as a single aggregate number. As with the connectivity graph, an IP version selector switches between IPv4 and IPv6.

Stacked area chart of the share of AS13335's observed paths carried by each of its top 10 direct upstreams, with the remainder grouped into Other

API endpoints

The data behind both widgets is also available through two new endpoints on the BGP API:

  • /bgp/routes/paths/{asn} — Returns the ordered AS path segments an AS uses to reach the Tier-1 networks, each with its observed path count, peer count, and contributing collectors, alongside the name and country of every ASN in the response. Pass collector to scope the result to a single RouteViews collector.
  • /bgp/routes/upstreams/{asn}/timeseries — Returns the share of an AS's observed paths carried by each direct upstream over time. Use limit to control how many upstreams come back as separate series before the rest are grouped into an OTHER series, and ipVersion to select the address family.

Visit the AS13335 routing page to explore both widgets, or swap in any other AS number.

Radar Researcher beta and WebMCP support now available

Cloudflare Radar now includes Radar Researcher, a beta AI-powered assistant for exploring Internet trends and traffic data in plain language. Open Researcher from the header on any Radar page to ask questions by voice or text, receive explanations, and view interactive charts based on Radar API data.

Screenshot of the Radar Researcher panel alongside the Radar overview page

To ask about a specific chart, select Explain with AI to start a conversation with its underlying data and context.

Screenshot of the Explain with AI option in a Radar chart menu

You can explore further with suggested follow-up questions, find earlier conversations through searchable history, and share conversations through shareable links.

Alongside the user-facing Researcher experience, Radar now supports WebMCP, allowing browser-based AI agents to navigate Radar, search data, and use tools such as URL scanning and domain lookup.

To get started, visit Cloudflare Radar.

Sandbox SDK 1.0 preview on @next

Sandbox SDK 1.0 is available to preview under the npm @next tag. For existing applications, the current stable package remains published on the 0.12.x line.

Sandbox SDK first shipped to provide a rich library for running untrusted and agent-driven work on Cloudflare Containers. Since then, both Sandbox and Containers have matured. This preview is a thinner SDK built on a richer Cloudflare Containers foundation.

npm i @cloudflare/sandbox@next

What this preview is

  • A single execution interfacesandbox.exec() takes an argument list, returns when the process starts, and gives you a handle for output, logs, waits, and signals. Both short commands and long-running services use the same API.
  • Removed session execution — the SDK no longer maintains shell state between executions. Each launch is independent. Pass cwd and env when you need them, or put multi-step shell syntax in one explicit shell command.
  • RPC as the only transport — the SDK talks to the container exclusively over RPC. Remove SANDBOX_TRANSPORT, transport on getSandbox(), and setTransport().
  • Improved PTY and terminal interface — interactive PTYs use createTerminal / connect, not the older session-shaped helpers.
  • Code interpreter as an extension — configure the code interpreter on your Sandbox subclass so you only ship what you need.

Start new projects on @next. Migrate existing apps when you can so you are ready when 1.0 becomes stable. Deploy the Worker package and container image from the same @next line.

Coding agents: install Cloudflare Skills (Agent setup). Use sandbox-next for @next (recommended for new projects), sandbox-stable for the current stable package, and sandbox-migrate-to-next when you are ready to port. Stable-package deprecated-API cleanup is in the 2026 deprecation guide.

The main Sandbox documentation still describes today's stable package. Preview docs:

The self-deployed Sandbox bridge is not currently part of this preview. We are working on bringing it in line with the latest code. Until then, use the stable bridge with the matching stable package and container image.

Timeline for 1.0

Further Cloudflare Containers features will let us keep reducing the size of the Sandbox SDK. We aim to ship Sandbox SDK 1.0 once those are in. In the meantime we continue to support and maintain the 1.0 preview (@next) alongside the current stable release.

WAF Release - 2026-08-07

This release updates WordPress XSS rule metadata in the Cloudflare Managed Ruleset and Cloudflare Free Ruleset to identify XSS2Shell (CVE-2026-64638). It also disables the Command Injection - Obfuscation rule.

Key Findings

  • CVE-2026-64638: A pre-authentication reflected cross-site scripting vulnerability affecting the WordPress login screen. Exploitation requires social engineering and explicit interaction by the target user. Under additional conditions, it may be escalated to remote code execution.

Impact

The WordPress changes update rule metadata only; detection behavior and actions remain unchanged.

RulesetRule IDLegacy Rule IDDescriptionPrevious ActionNew ActionComments
Cloudflare Managed RulesetN/AWordpress - XSS - CVE:CVE-2026-64638BlockN/ARule metadata description refined. Detection unchanged.
Cloudflare Free RulesetN/AWordpress - XSS - CVE:CVE-2026-64638BlockN/ARule metadata description refined. Detection unchanged.
Cloudflare Managed RulesetN/ACommand Injection - ObfuscationBlockDisabledDetection logic has been deprecated

AI Search makes it easier to build a search engine for your data

AI Search gets you from a data source to a working search endpoint quickly. This release adds what you need to put that endpoint in front of real users: your own domain, authentication, and one endpoint across several instances. It also adds crawling for sites without a complete sitemap, so your index covers everything you want it to find.

Each of the following is a new option. The previous behavior is still the default, so nothing changes until you change it.

Serve search from your own domain

A public endpoint is a URL that a site or app can query directly, with no authentication in front of it. By default that URL is a generated hostname on search.ai.cloudflare.com. You can now serve the same endpoint from a custom domain, a hostname in a zone that you own:

https://search.example.com/search

Restrict who can query your content

Once your endpoint is on your own domain, you can put Cloudflare Access in front of it. For example, you usually want to give /mcp to specific agents rather than to anyone who finds the URL. Agents authenticate with an Access service token, and people who open the endpoint in a browser sign in through your identity provider.

Search several instances from one URL

A namespace can expose its own public endpoint with /search, /chat/completions, and /mcp paths that fan out across the instances you choose:

curl https://ns-<NAMESPACE_ENDPOINT_ID>.search.ai.cloudflare.com/search \
  --header "Content-Type: application/json" \
  --data '{
    "messages": [{ "content": "How do I configure AI Search?", "role": "user" }],
    "ai_search_options": { "instance_ids": ["docs", "support"] }
  }'

Index your sites without a sitemap

Website data sources support a new discover parse type. It starts at the source URL and collects pages from both your sitemaps and the links it finds while crawling:

curl -X POST "https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/ai-search/instances" \
  -H "Authorization: Bearer <API_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "id": "my-ai-search",
    "type": "web-crawler",
    "source": "example.com",
    "source_params": {
      "web_crawler": {
        "parse_type": "discover",
        "discover_options": { "source": "links", "limit": 5000, "depth": 3 }
      }
    }
  }'

To learn more, refer to the AI Search documentation.

Introducing Kitesurf, an agent-first browser on Browser Run

Kitesurf is Cloudflare's new stateless, highly scalable browser that runs entirely on top of Workers and is designed for AI agents. It is available for free while in beta.

Compared to Chromium, Kitesurf uses 3–7× less CPU and memory for common agentic tasks like screenshots and HTML extraction, so you can run more sessions and scale better for bursty, AI-driven workloads.

Your existing clients already work. To opt in, add the browser=kitesurf parameter to any Browser Run CDP or Quick Action endpoint:

curl -X POST 'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/screenshot?browser=kitesurf' \
  -H 'Authorization: Bearer <API_TOKEN>' \
  -H 'Content-Type: application/json' \
  -d '{
    "url": "https://example.com"
  }' \
  --output "screenshot.png"

You can also explore Kitesurf without writing any code in the public playground.

For more information, refer to the Kitesurf documentation and the blog announcement.