Cloudflare Release Notes

This emergency release adds a new managed rule to block active exploitation of a critical remote code execution (RCE) and SQL injection (SQLi) vulnerability found in popular web frameworks.

Key Findings

• Generic Frameworks - Unauthenticated RCE: Attackers can execute arbitrary system commands with web server privileges by sending malicious input containing invalid path sequences during request processing.

• Generic Frameworks - SQLi: Attackers can execute unauthorized database queries due to a failure to sanitize input values within request parameters.

Ruleset

Rule ID

Legacy Rule ID

Description

Previous Action

New Action

Comments

Cloudflare Managed Ruleset

...550664b6

N/A

Generic Rules - Unauthenticated RCE

N/A

Block

This is a new detection.

Cloudflare Managed Ruleset

...ed933fcc

N/A

Generic Rules - SQLi

N/A

Block

This is a new detection.

Cloudflare Free Ruleset

...b5ec246a

N/A

Generic Rules - Unauthenticated RCE

N/A

Block

This is a new detection.

Cloudflare Free Ruleset

...33697a1a

N/A

Generic Rules - SQLi

N/A

Block

This is a new detection.

Cloudflare Fundamentals Organizations

Distributor, MSSP, and Agency partners on Cloudflare Organizations can now add and manage Organization Members directly from the Cloudflare dashboard, without help from Cloudflare.

Previously, adding a member to a Distributor, MSSP, or Agency Organization was a manual, Cloudflare-assisted process that required a request to Cloudflare and enrollment in a closed beta, and the dashboard Add member flow was blocked for these Organizations.

Now, Organization admins can add members themselves from Organization > Members > Add member, with no beta enrollment required.

New members receive access to the Organization's accounts through the same implicit-access model already used for enterprise Organizations. The Accounts list and the account switcher classify Distributor, MSSP, and Agency Organizations consistently with enterprise Organizations, so their accounts are labeled and grouped correctly in the dashboard.

Agency partners also gain access to the Organizations dashboard, while retaining access to their existing Tenant management dashboard.

Distributor, MSSP, and Agency Organizations are currently in beta. …

Distributor, MSSP, and Agency partners on Cloudflare Organizations can now add and manage Organization Members directly from the Cloudflare dashboard, without help from Cloudflare.

Previously, adding a member to a Distributor, MSSP, or Agency Organization was a manual, Cloudflare-assisted process that required a request to Cloudflare and enrollment in a closed beta, and the dashboard Add member flow was blocked for these Organizations.

Now, Organization admins can add members themselves from Organization > Members > Add member, with no beta enrollment required.

New members receive access to the Organization's accounts through the same implicit-access model already used for enterprise Organizations. The Accounts list and the account switcher classify Distributor, MSSP, and Agency Organizations consistently with enterprise Organizations, so their accounts are labeled and grouped correctly in the dashboard.

Agency partners also gain access to the Organizations dashboard, while retaining access to their existing Tenant management dashboard.

Distributor, MSSP, and Agency Organizations are currently in beta.

For more information, refer to Manage Organization members.

Wrangler now includes wrangler flagship, a command suite for managing Flagship apps and feature flags from your terminal.

Create an app and, if you use it from a Worker, add it to your wrangler.json or wrangler.jsonc file as a binding:

wrangler flagship apps create "My Worker App" \
  --binding FLAGS \
  --update-config

Then create flags for the behavior you want to control. Flags can be booleans, strings, numbers, or JSON values:

wrangler flagship flags create <APP_ID> new-checkout

wrangler flagship flags create <APP_ID> checkout-flow \
  --variation control=old-checkout \
  --variation treatment=new-checkout \
  --default control \
  --type string

After a flag exists, change its default variation or use enable and disable commands as kill switches. Existing targeting rules continue to apply unless you change or clear them explicitly:

wrangler flagship flags update <APP_ID> checkout-flow --default treatment
wrangler flagship flags disable <APP_ID> checkout-flow
wrangler flagship flags enable <APP_ID> checkout-flow

For release workflows, use rollout, split, and rules to change exposure without redeploying your Worker:

wrangler flagship flags rollout <APP_ID> new-checkout \
  --to on \
  --percentage 25 \
  --by user_id

wrangler flagship flags split <APP_ID> checkout-flow \
  --weight control=80 \
  --weight treatment=20 \…

Bot management fields and ASN support in Cache Rules

Cache Rules now supports bot management fields and the ip.src.asnum field in expression filters. You can now build cache policies that differentiate between automated and human traffic, or segment caching behavior by autonomous system number (ASN).

This allows you to apply different caching strategies for verified bots, high-risk traffic, or specific network operators without affecting legitimate user requests. For example, you can set shorter cache TTLs for suspected bot traffic or bypass cache entirely for requests from specific ASNs.

New fields

The following fields are now available in Cache Rules expressions:

Field

Type

Description

cf.bot_management.score

Number

Bot score from 1 to 99, where a lower value indicates a higher likelihood that the request originates from a bot.

cf.bot_management.ja3_hash

String

JA3 fingerprint of the request, which helps identify the client making the connection.

cf.bot_management.ja4

String

JA4 fingerprint of the request, which provides a more detailed client identification than JA3.

cf.bot_management.verified_bot

Boolean

Whether the request originates from a verified bot, such as a search engine crawler.

cf.bot_management.static_resource

Boolean

Whether the request is for a static resource and therefore exempt from bot detection. …

Internal DNS is now generally available. Internal DNS provides authoritative and recursive DNS for private networks on the same global network and control plane you already use for public DNS, Zero Trust, and application services.

Why it matters

• Consolidate DNS operations. Public and private DNS run on one platform, with one API, one audit trail, and one place to set policy.
• Simplify split-horizon DNS. Internal and external resolution are defined as separate views over shared zones, managed from a single control plane — so there is no drift to chase down.
• Extend Zero Trust to DNS. Resolver policies decide which users and devices resolve against which view, enforced by the same Gateway that already governs the rest of your traffic.

Setting up Internal DNS takes three steps: create a zone, create a view, and define a resolver policy.

POST /zones
{
  "account": {
    "id": "<ACCOUNT_ID>"
  },
  "name": "corp.internal",
  "type": "internal"
}

Internal DNS is included with Cloudflare Gateway for Enterprise customers. To get started, refer to the Internal DNS documentation.

You can now subscribe to Email Sending events through Queues event subscriptions and receive outbound transactional email lifecycle events on a queue. Each subscription is scoped to one sending domain — either the zone apex, such as example.com, or a verified sending subdomain, such as send.example.com.

Six event types are published: message.delivered, message.deferred, message.bounced, message.failed, message.rejected, and message.complained. Use them to track deliverability, react to bounces and complaints, and drive suppression or retry logic. Email Routing events are not published on this source.

Each event includes the message details, delivery status, and SMTP response:

{
	"type": "cf.email.sending.message.delivered",
	"source": {
		"type": "email.sending",
		"zoneId": "023e105f4ecef8ad9ca31a8372d0c353",
		"domain": "example.com"
	},
	"payload": {
		"messageId": "0101018f7d0c4d9a-msg-deadbeef",
		"recipient": "user@example.net",
		"terminal": true,
		"delivery": {
			"status": "delivered",
			"smtpStatusCode": "250"
		}
	}
}

Refer to Event subscriptions to see all event types and example payloads.

The legacy Workers KV API routes under /accounts/{account_id}/workers/namespaces/* are deprecated as of July 15, 2026, and will stop working on October 15, 2026. Migrate to the documented Workers KV API routes under /accounts/{account_id}/storage/kv/namespaces/* before that date.

The legacy and replacement routes are interchangeable. They accept the same request parameters and return the same response payloads. To migrate, update the URL path from /workers/namespaces/ to /storage/kv/namespaces/.

What you need to do

Update any integration that calls a route under /accounts/{account_id}/workers/namespaces/ to use the equivalent route under /accounts/{account_id}/storage/kv/namespaces/. The migration is a direct URL path substitution — request parameters and response payloads are identical:

• GET and POST /accounts/{account_id}/workers/namespaces → GET and POST /accounts/{account_id}/storage/kv/namespaces
• GET, PUT, and DELETE /accounts/{account_id}/workers/namespaces/{namespace_id} → GET, PUT, and DELETE /accounts/{account_id}/storage/kv/namespaces/{namespace_id}
• GET /accounts/{account_id}/workers/namespaces/{namespace_id}/keys → GET /accounts/{account_id}/storage/kv/namespaces/{namespace_id}/keys …

Internal DNS is now generally available. Internal DNS provides authoritative and recursive DNS for private networks on the same global network and control plane you already use for public DNS, Zero Trust, and application services.

Why it matters

• Consolidate DNS operations. Public and private DNS run on one platform, with one API, one audit trail, and one place to set policy.
• Simplify split-horizon DNS. Internal and external resolution are defined as separate views over shared zones, managed from a single control plane — so there is no drift to chase down.
• Extend Zero Trust to DNS. Resolver policies decide which users and devices resolve against which view, enforced by the same Gateway that already governs the rest of your traffic.

Setting up Internal DNS takes three steps: create a zone, create a view, and define a resolver policy.

POST /zones
{
  "account": {
    "id": "<ACCOUNT_ID>"
  },
  "name": "corp.internal",
  "type": "internal"
}

Internal DNS is included with Cloudflare Gateway for Enterprise customers. To get started, refer to the Internal DNS documentation.

Platforms can now create temporary preview accounts through the Cloudflare REST API. This lets your platform deploy a live Worker before the user signs in to Cloudflare.

With the Temporary Accounts API, coding agents, AI app builders, and other platforms can build a similar flow for generated Workers and supported resources.

Your platform can keep users in its onboarding flow while they generate, deploy, and test an application. Users do not need an existing Cloudflare account, and your platform does not need write access to one.

Diagram showing an AI agent deploying, verifying, and redeploying a Worker in a temporary account, then a user authenticating and claiming the account to keep its resources

The API returns a claim URL that lets the user make the temporary account and its resources permanent.

Cloudflare Drop ↗︎ demonstrates this preview-and-claim pattern for static sites. Someone can upload a site, test and share it for one hour, then sign in or create an account only when they want to keep it.

This API expands the flow first introduced with wrangler deploy --temporary. Your backend now controls the provisioning and deployment experience directly: …

Cloudflare Web Analytics (Real User Monitoring) has rolled out performance optimizations to significantly improve the stability and loading speed of account-wide dashboards.

For larger accounts (with >100 Web Analytics sites), loading the aggregate account-wide view would often fail, running into timeouts or unexpected interface errors due to the massive scale of parallel query processing. This update optimizes how high-volume multi-site data is queried to reduce errors and provide a snappier dashboard experience.

Accounts with up to 1,000 sites will now be able to load this account-wide aggregate view without experiencing misleading errors.

If you have an account with over 1,000 sites, we cannot currently aggregate over this volume due to processing constraints but you will now be presented with a clear error and instruction to filter to the relevant site(s) you wish to see the data for.

This release introduces new rules targeting critical infrastructure vulnerabilities. These include an unauthenticated memory disclosure flaw in Citrix NetScaler ADC and Gateway (CVE-2026-8451) and a high-severity pre-authentication remote code execution (RCE) vulnerability in Progress Kemp LoadMaster (CVE-2026-8037).

Key Findings

• CVE-2026-8451: An insufficient input validation vulnerability affects Citrix NetScaler ADC and NetScaler Gateway appliances configured as a SAML Identity Provider (IdP). Remote, unauthenticated attackers can exploit this flaw by sending malformed requests to trigger a memory overread, allowing them to leak chunks of sensitive data from adjacent appliance memory.

• CVE-2026-8037: A critical OS command injection vulnerability in Progress Kemp LoadMaster load balancers allows unauthenticated remote attackers to achieve remote code execution (RCE).

Ruleset

Rule ID

Legacy Rule ID

Description

Previous Action

New Action

Comments

Cloudflare Managed Ruleset

...76973ac4

N/A

Citrix Netscaler ADC - Insufficient Input Validation - CVE:CVE-2026-8451

Log

Block

This is a new detection.

Cloudflare Managed Ruleset

...10233f36

N/A

Progress Kemp LoadMaster - Remote Code Execution - CVE:CVE-2026-8037

Log

Block

This is a new detection.

Agents connected to Model Context Protocol (MCP) servers with addMcpServer can now handle elicitation ↗︎ requests.

Elicitation lets an MCP server request user input while it handles a tool call. Form mode collects structured, non-sensitive data. URL mode asks for consent before opening an out-of-band flow, such as third-party authorization or payment.

sequenceDiagram participant User participant Agent as Agent (MCP client) participant Server as MCP server participant Browser

Server->>Agent: elicitation/create
Agent->>User: Show server, reason, and input or URL
User->>Agent: Submit, open, decline, or cancel
Agent->>Browser: Open URL after consent (URL mode)
Agent->>Server: accept, decline, or cancel
Server-->>Agent: Optional URL completion notification

Register a handler for each mode your Agent supports in onStart():

import { Agent } from "agents";

export class MyAgent extends Agent {
	onStart() {
		this.mcp.configureElicitationHandlers({
			form: (request, serverId) => this.forwardToUser(request, serverId),
			url: (request, serverId) => this.forwardToUser(request, serverId),
		});
	}

	forwardToUser(request, serverId) {
		// Show the request in your UI and resolve after the user responds.
		throw new Error( …

R2 Data Catalog now accepts read-only API tokens, so query engines and clients that only read data no longer need a read-write token. Previously, every catalog operation required an Admin Read & Write token, which granted read-only clients more access than they needed.

You can now authenticate your Iceberg engine based on your workload:

• Read-only operations (such as listing namespaces, loading tables, and querying data) work with an Admin Read only token (R2 Data Catalog read and R2 storage read).
• Write operations (such as creating or dropping tables and committing transactions) continue to require an Admin Read & Write token.

This lets you follow the principle of least privilege — for example, using a read-write token for the pipeline that writes to your tables and read-only tokens for engines like R2 SQL, DuckDB, or PyIceberg that query them.

Note that credentials vended by the catalog inherit the R2 storage permissions of the token used to authenticate. To ensure read-only access to your underlying data, scope the R2 storage permission to read-only as well. …

R2 Data Catalog, a managed Apache Iceberg ↗︎ catalog built into R2, now automatically optimizes manifest files as part of compaction.

Manifest files track the data files that make up an Iceberg table. As a table accumulates many small or fragmented manifests, query engines must read more metadata during query planning, which slows down queries even before any data is scanned.

When compaction runs, R2 Data Catalog now rewrites and clusters manifest files by partition as a best-effort pre-step. This consolidates fragmented manifests, reduces the number of manifests a query engine must open, and lowers metadata I/O overhead. Tables that are already well-clustered are skipped, so the operation only runs when it provides a benefit.

This happens automatically for tables with compaction enabled — no configuration changes are required.

For more information, refer to Table maintenance.

Precursor is rolling out to all customers starting today. Precursor is client-side JavaScript that enables session-based bot detection.

You can read the announcement blog ↗︎ for background on why we built Precursor and how session-level behavioral detection works.

With Precursor enabled, Cloudflare can:

• Continuously evaluate behavioral signals across a session
• Re-validate challenge clearance as behavior changes
• Update bot scores with session context
• Provide client-side visibility where none previously existed

It integrates with existing protections, including Security Rules, and can be enabled directly from the Cloudflare dashboard with configurable modes to balance security and user experience.

Animated walkthrough of enabling Precursor in the Cloudflare dashboard

To learn more, refer to the Precursor documentation.

Cloudflare Fundamentals

Markdown for Agents now preserves security- and cache-relevant response headers from your origin when converting HTML to Markdown:

• Markdown for Agents preserves security headers such as Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Frame-Options, Set-Cookie, and CORS headers (for example, Access-Control-Allow-Origin) on the converted response.
• Caching headers ( Cache-Control, Expires, Age) continue to pass through.

Your origin's Content Signals ↗︎ policy is now authoritative. If your origin sets a content-signal header, Markdown for Agents preserves it. When the origin does not send one, Cloudflare adds the default Content-Signal: ai-train=yes, search=yes, ai-input=yes.

This release also fixes relative link resolution for directory-style base URLs (those ending in a trailing slash). Previously, relative links such as ../page/ could resolve one path segment too high and return a 404. Links are now resolved correctly per RFC 3986 ↗︎.

Refer to our developer documentation for more details.

Markdown for Agents now preserves security- and cache-relevant response headers from your origin when converting HTML to Markdown:

• Markdown for Agents preserves security headers such as Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Frame-Options, Set-Cookie, and CORS headers (for example, Access-Control-Allow-Origin) on the converted response.
• Caching headers (Cache-Control, Expires, Age) continue to pass through.

Your origin's Content Signals ↗︎ policy is now authoritative. If your origin sets a content-signal header, Markdown for Agents preserves it. When the origin does not send one, Cloudflare adds the default Content-Signal: ai-train=yes, search=yes, ai-input=yes.

This release also fixes relative link resolution for directory-style base URLs (those ending in a trailing slash). Previously, relative links such as ../page/ could resolve one path segment too high and return a 404. Links are now resolved correctly per RFC 3986 ↗︎.

Refer to our developer documentation for more details.

Data Loss Prevention (DLP) source code detection now focuses on identifying whole source code file uploads and downloads. Previously, source code detection performed partial scans resulting in a higher rate of false positives. Since only whole source code files are evaluated, code embedded in other content — such as chat messages, documentation, or code samples — is no longer flagged as source code, removing a common source of false positives.

Source code detection requires a minimum of 500 characters to evaluate a file. Files below this threshold are not flagged to reduce noise. This threshold filters out small fragments that lack enough context for reliable classification.

Enable and set confidence levels to tune match sensitivity. A higher confidence level reduces false positives by requiring stronger signals that the content is truly source code. A lower confidence level catches more files at the cost of additional noise.

Source code detection applies to standalone source code files in Gateway HTTP policies. It does not detect source code embedded within other file types or payloads, such as .docx files or chat messages. …