Changelog

This week's release introduces new detections for a critical Remote Code Execution (RCE) vulnerability in MCP Server (CVE-2026-23744), alongside targeted protection for an authentication bypass vulnerability in SolarWinds products (CVE-2025-40552). Additionally, this release includes a new generic detection rule designed to identify and block Cross-Site Scripting (XSS) injection attempts leveraging "OnEvent" handlers within HTTP cookies.

Key Findings

• MCP Server (CVE-2026-23744): A vulnerability in the Model Context Protocol (MCP) server implementation where malformed input payloads can trigger a memory corruption state, allowing for arbitrary code execution.

• SolarWinds (CVE-2025-40552): A critical flaw in the authentication module allows unauthenticated attackers to bypass security filters and gain unauthorized access to the management console due to improper identity token validation.

• XSS OnEvents Cookies: This generic rule identifies malicious event handlers (such as onload or onerror) embedded within HTTP cookie values.

Impact

Successful exploitation of the MCP Server and SolarWinds vulnerabilities could allow unauthenticated attackers to execute arbitrary code or gain administrative control, leading to a full system takeover. Additionally, the new generic XSS detection prevents attackers from leveraging browser event handlers in cookies to hijack user sessions or execute malicious scripts.

The Workers runtime now automatically sends a reciprocal Close frame when it receives a Close frame from the peer. The readyState transitions to CLOSED before the close event fires. This matches the WebSocket specification ↗ and standard browser behavior.

This change is enabled by default for Workers using compatibility dates on or after 2026-04-07 (via the web_socket_auto_reply_to_close compatibility flag). Existing code that manually calls close() inside the close event handler will continue to work — the call is silently ignored when the WebSocket is already closed.

const [client, server] = Object.values(new WebSocketPair());
server.accept();

server.addEventListener("close", (event) => {
	// readyState is already CLOSED — no need to call server.close().
	console.log(server.readyState); // WebSocket.CLOSED
	console.log(event.code); // 1000
	console.log(event.wasClean); // true
});

The automatic close behavior can interfere with WebSocket proxying, where a Worker sits between a client and a backend and needs to coordinate the close on both sides independently. To support this use case, pass { allowHalfOpen: true } to accept():

const [client, server] = Object.values(new WebSocketPair());

server.accept({ allowHalfOpen: true });

server.addEventListener("close", (event) => {
	// readyState is still CLOSING here, giving you time
	// to coordinate the close on the other side.
	console.log(server.readyState); // WebSocket.CLOSING

	// Manually close when ready.
	server.close(event.code, "done");
});

For more information, refer to WebSockets Close behavior.

Cloudflare Email Security now supports DANE (DNS-based Authentication of Named Entities) for MX deployments. This enhancement strengthens email transport security by enabling DNSSEC-backed certificate verification for our regional MX records.

• Regional MX hostnames now publish DANE TLSA records backed by DNSSEC, enabling DANE-capable SMTP senders to cryptographically validate certificate identities before establishing TLS connections—moving beyond opportunistic encryption to verified encrypted delivery.
• DANE support is automatically available for all customers using regional MX deployments. No additional configuration is required; DANE-capable mail infrastructure will automatically validate MX certificates using the published records.

This applies to all Email Security packages:

• Advantage
• Enterprise
• Enterprise + PhishGuard

We're announcing the public beta of Organizations for enterprise customers, a new top-level Cloudflare container that lets Cloudflare customers manage multiple accounts, members, analytics, and shared policies from one centralized location.

What's New

Organizations [BETA]: Organizations are a new top-level container for centrally managing multiple accounts. Each Organization supports up to 500 accounts and 5000 zones, giving larger teams a single place to administer resources at scale.

Self-serve onboarding: Enterprise customers can create an Organization in the dashboard and assign accounts where they are already Super Administrators.

Centralized Account Management: At launch, every Organization member has the Organization Super Admin role. Organization Super Admins can invite other users and manage any child account under the Organization implicitly. Shared policies: Share WAF or Gateway policies across multiple accounts within your Organization to simplify centralized policy management. Implicit access: Members of an Organization automatically receive Super Administrator permissions across child accounts, removing the need for explicit membership on each account. Additional Org-level roles will be available over the course of the year.

Unified analytics: View, filter, and download aggregate HTTP analytics across all Organization child accounts from a single dashboard for centralized visibility into traffic patterns and security events.

Terraform provider support: Manage Organizations with infrastructure as code from day one. Provision organizations, assign accounts, and configure settings programmatically with the Cloudflare Terraform provider ↗.

Shared policies: Share WAF or Gateway policies across multiple accounts within your Organization to simplify centralized policy management.

For more info:

• Get started with Organizations
• Set up your Organization
• Review limitations

Cloudflare has added a new field to the Gateway DNS Logpush dataset:

• ResponseTimeMs: Total response time of the DNS request in milliseconds.

For the complete field definitions, refer to Gateway DNS dataset.

You can now specify placement constraints to control where your Containers run.

Use regions to limit placement to specific geographic areas. Use jurisdiction to restrict containers to compliance boundaries — eu maps to European regions (EEUR, WEUR) and fedramp maps to North American regions (ENAM, WNAM).

Refer to Containers placement for more details.

We are partnering with Google to bring @cf/google/gemma-4-26b-a4b-it to Workers AI. Gemma 4 26B A4B is a Mixture-of-Experts (MoE) model built from Gemini 3 research, with 26B total parameters and only 4B active per forward pass. By activating a small subset of parameters during inference, the model runs almost as fast as a 4B-parameter model while delivering the quality of a much larger one.

Gemma 4 is Google's most capable family of open models, designed to maximize intelligence-per-parameter.

• Mixture-of-Experts architecture with 8 active experts out of 128 total (plus 1 shared expert), delivering frontier-level performance at a fraction of the compute cost of dense models
• 256,000 token context window for retaining full conversation history, tool definitions, and long documents across extended sessions
• Built-in thinking mode that lets the model reason step-by-step before answering, improving accuracy on complex tasks
• Vision understanding for object detection, document and PDF parsing, screen and UI understanding, chart comprehension, OCR (including multilingual), and handwriting recognition, with support for variable aspect ratios and resolutions
• Function calling with native support for structured tool use, enabling agentic workflows and multi-step planning
• Multilingual with out-of-the-box support for 35+ languages, pre-trained on 140+ languages
• Coding for code generation, completion, and correction

Use Gemma 4 26B A4B through the Workers AI binding (env.AI.run()), the REST API at /run or /v1/chat/completions, or the OpenAI-compatible endpoint.

For more information, refer to the Gemma 4 26B A4B model page.

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

This release contains minor fixes and improvements.

The next stable release for macOS will introduce the new Cloudflare One Client UI, providing a cleaner and more intuitive design as well as easier access to common actions and information.

Changes and improvements

• Empty MDM files are now rejected instead of being incorrectly accepted as a single MDM config.
• Fixed an issue in local proxy mode where the client could become unresponsive due to upstream connection timeouts.
• Fixed an issue where the emergency disconnect status of a prior organization persisted after a switch to a different organization.
• Consumer-only CLI commands are now clearly distinguished from Zero Trust commands.
• Added detailed QUIC connection metrics to diagnostic logs for better troubleshooting.
• Added monitoring for tunnel statistics collection timeouts.
• Switched tunnel congestion control algorithm for local proxy mode to Cubic for improved reliability across platforms.
• Fixed initiating managed network detections checks when no network is available, which caused device profile flapping.

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

This release contains minor fixes and improvements.

The next stable release for Linux will introduce the new Cloudflare One Client UI, providing a cleaner and more intuitive design as well as easier access to common actions and information.

Changes and improvements

• Empty MDM files are now rejected instead of being incorrectly accepted as a single MDM config.
• Fixed an issue in local proxy mode where the client could become unresponsive due to upstream connection timeouts.
• Fixed an issue where the emergency disconnect status of a prior organization persisted after a switch to a different organization.
• Consumer-only CLI commands are now clearly distinguished from Zero Trust commands.
• Added detailed QUIC connection metrics to diagnostic logs for better troubleshooting.
• Added monitoring for tunnel statistics collection timeouts.
• Switched tunnel congestion control algorithm for local proxy mode to Cubic for improved reliability across platforms.
• Fixed initiating managed network detections checks when no network is available, which caused device profile flapping.

MCP server portals support in-session management of upstream MCP server connections. Users can return to the server selection page at any time to enable or disable servers, reauthenticate, or change which data a server has access to — all without leaving their MCP client.

To return to the server selection page, ask your AI agent with a prompt like "take me back to the server selection page." The portal responds with an authorization URL via MCP elicitation ↗ that you open in your browser:

https://<subdomain>.<domain>/authorize?elicitationId=<ELICITATION_ID>

From the server selection page you can:

• Enable or disable servers — Toggle individual upstream MCP servers on or off. Disabling a server removes its tools from the active session, which reduces context window usage.
• Log out and reauthenticate — Log out of a server and log back in to change which data the server has access to, or to reauthenticate with different permissions.

Users can also enable or disable a server inline by asking their AI agent directly, for example "enable the wiki server" or "disable my Jira server."

The portal also automatically prompts connected users to authorize new servers when an admin adds them to the portal. This requires the use of managed OAuth.

For more information, refer to Manage portal sessions.

AI Gateway now supports automatic retries at the gateway level. When an upstream provider returns an error, your gateway retries the request based on the retry policy you configure, without requiring any client-side changes.

You can configure the retry count (up to 5 attempts), the delay between retries (from 100ms to 5 seconds), and the backoff strategy (Constant, Linear, or Exponential). These defaults apply to all requests through the gateway, and per-request headers can override them.

This is particularly useful when you do not control the client making the request and cannot implement retry logic on the caller side. For more complex failover scenarios — such as failing across different providers — use Dynamic Routing.

For more information, refer to Manage gateways.

Cloudflare Logpush now supports BigQuery as a native destination.

Logs from Cloudflare can be sent to Google Cloud BigQuery ↗ via Logpush. The destination can be configured through the Logpush UI in the Cloudflare dashboard or by using the Logpush API.

For more information, refer to the Destination Configuration documentation.

All wrangler workflows commands now accept a --local flag to target a Workflow running in a local wrangler dev session instead of the production API.

You can now manage the full Workflow lifecycle locally, including triggering Workflows, listing instances, pausing, resuming, restarting, terminating, and sending events:

npx wrangler workflows list --local
npx wrangler workflows trigger my-workflow --local
npx wrangler workflows instances list my-workflow --local
npx wrangler workflows instances pause my-workflow <INSTANCE_ID> --local
npx wrangler workflows instances send-event my-workflow <INSTANCE_ID> --type my-event --local

All commands also accept --port to target a specific wrangler dev session (defaults to 8787).

For more information, refer to Workflows local development.

AI Search supports a wrangler ai-search command namespace. Use it to manage instances from the command line.

The following commands are available:

The create command guides you through setup, choosing a name, source type (r2 or web), and data source. You can also pass all options as flags for non-interactive use:

wrangler ai-search create my-instance --type r2 --source my-bucket

Use wrangler ai-search search to query an instance directly from the CLI:

wrangler ai-search search my-instance --query "how do I configure caching?"

All commands support --json for structured output that scripts and AI agents can parse directly.

For full usage details, refer to the Wrangler commands documentation.

Access authentication logs and Gateway activity logs (DNS, Network, and HTTP) now feature a refreshed user interface that gives you more flexibility when viewing and analyzing your logs.

The updated UI includes:

• Filter by field - Select any field value to add it as a filter and narrow down your results.
• Customizable fields - Choose which fields to display in the log table. Querying for fewer fields improves log loading performance.
• View details - Select a timestamp to view the full details of a log entry.
• Switch to classic view - Return to the previous log viewer interface if needed.

For more information, refer to Access authentication logs and Gateway activity logs.

Radar now features an expanded Routing section ↗ with dedicated sub-pages, providing a more organized and in-depth view of the global routing ecosystem. This restructuring lays the groundwork for additional routing features and widgets coming in the near future.

The single Routing page has been split into three focused sub-pages:

• Overview ↗ — Routing statistics, IP address space trends, BGP announcements, and the new Top 100 ASes ranking.
• RPKI ↗ — RPKI validation status, ASPA deployment trends, and per-ASN ASPA provider details.
• Anomalies ↗ — BGP route leaks, origin hijacks, and Multi-Origin AS (MOAS) conflicts.

The routing overview now includes a Top 100 ASes table ranking autonomous systems by customer cone size, IPv4 address space, or IPv6 address space. Users can switch between rankings using a segmented control.

The RPKI sub-page introduces a RPKI validation view for per-ASN pages, showing prefixes grouped by RPKI validation status (Valid, Invalid, Unknown) with visibility scores.

The IP address space ↗ chart now displays both IPv4 and IPv6 trends stacked vertically and is available on global, country, and AS views.

Check out the Radar routing section ↗ to explore the data, and stay tuned for more routing insights coming soon.

Two new fields are now available in rule expressions that surface Layer 4 transport telemetry from the client connection. Together with the existing cf.timings.client_tcp_rtt_msec field, these fields give you a complete picture of connection quality for both TCP and QUIC traffic — enabling transport-aware rules without requiring any client-side changes.

Previously, QUIC RTT and delivery rate data was only available via the Server-Timing: cfL4 response header. These new fields make the same data available directly in rule expressions, so you can use them in Transform Rules, WAF Custom Rules, and other phases that support dynamic fields.

Use a request header transform rule to tag requests from high-latency connections, so your origin can serve a lighter page variant:

Rule expression:

cf.timings.client_tcp_rtt_msec > 200 or cf.timings.client_quic_rtt_msec > 200

Header modifications:

cf.edge.l4.delivery_rate > 0 and cf.edge.l4.delivery_rate < 100000

For more information, refer to Request Header Transform Rules and the fields reference.

Workers Builds now supports Deploy Hooks — trigger builds from your headless CMS, a Cron Trigger, a Slack bot, or any system that can send an HTTP request.

Each Deploy Hook is a unique URL tied to a specific branch. Send it a POST and your Worker builds and deploys.

curl -X POST "https://api.cloudflare.com/client/v4/workers/builds/deploy_hooks/<DEPLOY_HOOK_ID>"

To create one, go to Workers & Pages > your Worker > Settings > Builds > Deploy Hooks.

Since a Deploy Hook is a URL, you can also call it from another Worker. For example, a Worker with a Cron Trigger can rebuild your project on a schedule:

export default {
	async scheduled(event, env, ctx) {
		ctx.waitUntil(fetch(env.DEPLOY_HOOK_URL, { method: "POST" }));
	},
};

export default {
  async scheduled(event: ScheduledEvent, env: Env, ctx: ExecutionContext): Promise<void> {
    ctx.waitUntil(fetch(env.DEPLOY_HOOK_URL, { method: "POST" }));
  },
} satisfies ExportedHandler<Env>;

You can also use Deploy Hooks to rebuild when your CMS publishes new content or deploy from a Slack slash command.

• Automatic deduplication: If a Deploy Hook fires multiple times before the first build starts running, redundant builds are automatically skipped. This keeps your build queue clean when webhooks retry or CMS events arrive in bursts.
• Last triggered: The dashboard shows when each hook was last triggered.
• Build source: Your Worker's build history shows which Deploy Hook started each build by name.

Deploy Hooks are rate limited to 10 builds per minute per Worker and 100 builds per minute per account. For all limits, see Limits & pricing.

To get started, read the Deploy Hooks documentation.

Three new properties are now available on request.cf in Workers that expose Layer 4 transport telemetry from the client connection. These properties let your Worker make decisions based on real-time connection quality signals — such as round-trip time and data delivery rate — without requiring any client-side changes.

Previously, this telemetry was only available via the Server-Timing: cfL4 response header. These new properties surface the same data directly in the Workers runtime, so you can use it for routing, logging, or response customization.

export default {
  async fetch(request) {
    const cf = request.cf;

    const rtt = cf.clientTcpRtt ?? cf.clientQuicRtt ?? 0;
    const deliveryRate = cf.edgeL4?.deliveryRate ?? 0;
    const transport = cf.clientTcpRtt ? "TCP" : "QUIC";

    console.log(`Transport: ${transport}, RTT: ${rtt}ms, Delivery rate: ${deliveryRate} B/s`);

    const headers = new Headers(request.headers);
    headers.set("X-Client-RTT", String(rtt));
    headers.set("X-Delivery-Rate", String(deliveryRate));

    return fetch(new Request(request, { headers }));
  },
};

For more information, refer to Workers Runtime APIs: Request.

Internal DNS is now in open beta.

Internal DNS is bundled as a part of Cloudflare Gateway and is now available to every Enterprise customer with one of the following subscriptions:

• Cloudflare Zero Trust Enterprise
• Cloudflare Gateway Enterprise

To learn more and get started, refer to the Internal DNS documentation.

This week's release introduces new detections for a critical authentication bypass vulnerability in Fortinet products (CVE-2025-59718), alongside three new generic detection rules designed to identify and block HTTP Parameter Pollution attempts. Additionally, this release includes targeted protection for a high-impact unrestricted file upload vulnerability in Magento and Adobe Commerce.

Key Findings

• CVE-2025-59718: An improper cryptographic signature verification vulnerability in Fortinet FortiOS, FortiProxy, and FortiSwitchManager. This may allow an unauthenticated attacker to bypass the FortiCloud SSO login authentication using a maliciously crafted SAML message, if that feature is enabled on the device.

• Magento 2 - Unrestricted File Upload: A critical flaw in Magento and Adobe Commerce allows unauthenticated attackers to bypass security checks and upload malicious files to the server, potentially leading to Remote Code Execution (RCE).

Impact

Successful exploitation of the Fortinet and Magento vulnerabilities could allow unauthenticated attackers to gain administrative control or deploy webshells, leading to complete server compromise and data theft.

Four new fields are now available on request.cf.tlsClientAuth in Workers for requests that include a mutual TLS (mTLS) client certificate. These fields encode the client certificate and its intermediate chain in RFC 9440 ↗ format — the same standard format used by the Client-Cert and Client-Cert-Chain HTTP headers — so your Worker can forward them directly to your origin without any custom parsing or encoding logic.

export default {
  async fetch(request) {
    const tls = request.cf.tlsClientAuth;

    // Only forward if cert was verified and chain is complete
    if (!tls || !tls.certVerified || tls.certRevoked || tls.certChainRFC9440TooLarge) {
      return new Response("Unauthorized", { status: 401 });
    }

    const headers = new Headers(request.headers);
    headers.set("Client-Cert", tls.certRFC9440);
    headers.set("Client-Cert-Chain", tls.certChainRFC9440);

    return fetch(new Request(request, { headers }));
  },
};

For more information, refer to Client certificate variables and Mutual TLS authentication.

MCP server portals support Code Mode MCP server patterns, a technique that reduces context window usage by replacing individual tool definitions with a single code execution tool. Code Mode is turned on by default on all portals.

To turn it off, edit the portal in Access controls > AI controls and turn off Code Mode under Basic information.

When Code Mode is active, the portal exposes a single code tool instead of listing every tool from every upstream MCP server. The connected AI agent writes JavaScript that calls typed codemode.* methods for each upstream tool. The generated code runs in an isolated Dynamic Worker environment, keeping authentication credentials and environment variables out of the model context.

To use Code Mode, append ?codemode=search_and_execute to your portal URL when connecting from an MCP client:

https://<subdomain>.<domain>/mcp?codemode=search_and_execute

For more information, refer to Code Mode.

MCP server portals support two context optimization options that reduce how many tokens tool definitions consume in the model's context window. Both options are activated by appending the optimize_context query parameter to the portal URL.

Strips tool descriptions and input schemas from all upstream tools, leaving only their names. The portal exposes a special query tool that agents use to retrieve full definitions on demand. This provides up to 5x savings in token usage.

https://<subdomain>.<domain>/mcp?optimize_context=minimize_tools

Hides all upstream tools and exposes only two tools: query and execute. The query tool searches and retrieves tool definitions. The execute tool runs the upstream tools in an isolated Dynamic Worker environment. This reduces the initial token cost to a small constant, regardless of how many tools are available through the portal.

https://<subdomain>.<domain>/mcp?optimize_context=search_and_execute

For more information, refer to Optimize context.

Containers and Sandboxes now support connecting directly to Workers over HTTP. This allows you to call Workers functions and bindings, like KV or R2, from within the container at specific hostnames.

Define an outbound handler to capture any HTTP request or use outboundByHost to capture requests to individual hostnames and IPs.

export class MyApp extends Sandbox {}

MyApp.outbound = async (request, env, ctx) => {
	// you can run arbitrary functions defined in your Worker on any HTTP request
	return await someWorkersFunction(request.body);
};

MyApp.outboundByHost = {
	"my.worker": async (request, env, ctx) => {
		return await anotherFunction(request.body);
	},
};

In this example, requests from the container to http://my.worker will run the function defined within outboundByHost, and any other HTTP requests will run the outbound handler. These handlers run entirely inside the Workers runtime, outside of the container sandbox.

Each handler has access to env, so it can call any binding set in Wrangler config. Code inside the container makes a standard HTTP request to that hostname and the outbound Worker translates it into a binding call.

export class MyApp extends Sandbox {}

MyApp.outboundByHost = {
	"my.kv": async (request, env, ctx) => {
		const key = new URL(request.url).pathname.slice(1);
		const value = await env.KV.get(key);
		return new Response(value ?? "", { status: value ? 200 : 404 });
	},
	"my.r2": async (request, env, ctx) => {
		const key = new URL(request.url).pathname.slice(1);
		const object = await env.BUCKET.get(key);
		return new Response(object?.body ?? "", { status: object ? 200 : 404 });
	},
};

Now, from inside the container sandbox, curl http://my.kv/some-key will access Workers KV and curl http://my.r2/some-object will access R2.

Use ctx.containerId to reference the container's automatically provisioned Durable Object.

export class MyContainer extends Container {}

MyContainer.outboundByHost = {
	"get-state.do": async (request, env, ctx) => {
		const id = env.MY_CONTAINER.idFromString(ctx.containerId);
		const stub = env.MY_CONTAINER.get(id);
		return stub.getStateForKey(request.body);
	},
};

This provides an easy way to associate state with any container instance, and includes a built-in SQLite database.

Upgrade to @cloudflare/containers version 0.2.0 or later, or @cloudflare/sandbox version 0.8.0 or later to use outbound Workers.

Refer to Containers outbound traffic and Sandboxes outbound traffic for more details and examples.