Cloudflare Release Notes

The minimum cacheTtl parameter for Workers KV has been reduced from 60 seconds to 30 seconds. This change applies to both get() and getWithMetadata() methods.

This reduction allows you to maintain more up-to-date cached data and have finer-grained control over cache behavior. Applications requiring faster data refresh rates can now configure cache durations as low as 30 seconds instead of the previous 60-second minimum.

The cacheTtl parameter defines how long a KV result is cached at the global network location it is accessed from:

// Read with custom cache TTL
const value = await env.NAMESPACE.get("my-key", {
	cacheTtl: 30, // Cache for minimum 30 seconds (previously 60)
});

// getWithMetadata also supports the reduced cache TTL
const valueWithMetadata = await env.NAMESPACE.getWithMetadata("my-key", {
	cacheTtl: 30, // Cache for minimum 30 seconds
});

The default cache TTL remains unchanged at 60 seconds. Upgrade to the latest version of Wrangler to be able to use 30 seconds cacheTtl.

This change affects all KV read operations using the binding API. For more information, consult the Workers KV cache TTL documentation.

Magic WAN and Magic Transit customers can use the Cloudflare dashboard to configure and manage BGP peering between their networks and their Magic routing table when using IPsec and GRE tunnel on-ramps (beta).

Using BGP peering allows customers to:

• Automate the process of adding or removing networks and subnets.
• Take advantage of failure detection and session recovery features.

With this functionality, customers can:

• Establish an eBGP session between their devices and the Magic WAN / Magic Transit service when connected via IPsec and GRE tunnel on-ramps.
• Secure the session by MD5 authentication to prevent misconfigurations.
• Exchange routes dynamically between their devices and their Magic routing table.

For configuration details, refer to:

• Configure BGP routes for Magic WAN
• Configure BGP routes for Magic Transit

We have partnered with Black Forest Labs (BFL) again to bring their optimized FLUX.2 [klein] 9B model to Workers AI. This distilled model offers enhanced quality compared to the 4B variant, while maintaining cost-effective pricing. With a fixed 4-step inference process, Klein 9B is ideal for rapid prototyping and real-time applications where both speed and quality matter.

Read the BFL blog ↗︎ to learn more about the model itself, or try it out yourself on our multi modal playground ↗︎.

Pricing documentation is available on the model page or pricing page.

Workers AI platform specifics

The model hosted on Workers AI is optimized for speed with a fixed 4-step inference process and supports up to 4 image inputs. Since this is a distilled model, the steps parameter is fixed at 4 and cannot be adjusted. Like FLUX.2 [dev] and FLUX.2 [klein] 4B, this image model uses multipart form data inputs, even if you just have a prompt.

With the REST API, the multipart form data input looks like this:

curl --request POST \
  --url 'https://api.cloudflare.com/client/v4/accounts/{ACCOUNT}/ai/run/@cf/black-forest-labs/flux-2-klein-9b' \
  --header 'Authorization: Bearer {TOKEN}' \
  --header 'Content-Type: multipart/form-data' \ …

A new Beta release for the Windows WARP client is now available on the beta releases downloads page.

This release contains minor fixes, improvements, and new features.

Changes and improvements

• Improvements to multi-user mode. Fixed an issue where when switching from a pre-login registration to a user registration, Mobile Device Management (MDM) configuration association could be lost.
• Added a new feature to manage NetBIOS over TCP/IP functionality on the Windows client. NetBIOS over TCP/IP on the Windows client is now disabled by default and can be enabled in device profile settings.
• Fixed an issue causing failure of the local network exclusion feature when configured with a timeout of 0. …

A new Beta release for the macOS WARP client is now available on the beta releases downloads page.

This release contains minor fixes and improvements.

Changes and improvements

• Fixed an issue causing failure of the local network exclusion feature when configured with a timeout of 0.
• Improvement for more accurate reporting of device colocation information in the Cloudflare One dashboard.

Cloudflare source IPs are the IP addresses used by Cloudflare services (such as Load Balancing, Gateway, and Browser Isolation) when sending traffic to your private networks.

For customers using legacy mode routing, traffic to private networks is sourced from public Cloudflare IPs, which may cause IP conflicts. For customers using Unified Routing mode (beta), traffic to private networks is sourced from dedicated, non-Internet-routable private IPv4 range to ensure:

• Symmetric routing over private network connections
• Proper firewall state preservation
• Private traffic stays on secure paths

Key details:

• IPv4: Sourced from 100.64.0.0/12 by default, configurable to any /12 CIDR
• IPv6: Sourced from 2606:4700:cf1:5000::/64 (not configurable)
• Affected connectors: GRE, IPsec, CNI, WARP Connector, and WARP Client (Cloudflare Tunnel is not affected)

Configuring Cloudflare source IPs requires Unified Routing (beta) and the Cloudflare One Networks Write permission.

For configuration details, refer to Configure Cloudflare source IPs.

You can now control how Cloudflare buffers HTTP request and response bodies using two new settings in Configuration Rules.

Request body buffering

Controls how Cloudflare buffers HTTP request bodies before forwarding them to your origin server:

Mode

Behavior

Standard (default)

Cloudflare can inspect a prefix of the request body for enabled functionality such as WAF and Bot Management.

Full

Buffers the entire request body before sending to origin.

None

No buffering — the request body streams directly to origin without inspection.

Response body buffering

Controls how Cloudflare buffers HTTP response bodies before forwarding them to the client:

Mode

Behavior

Standard (default)

Cloudflare can inspect a prefix of the response body for enabled functionality.

None

No buffering — the response body streams directly to the client without inspection.

Caution

Setting body buffering to None may break security functionality that requires body inspection, including the Web Application Firewall (WAF) and Bot Management. Ensure that any paths where you disable buffering do not require security inspection.

API example

{
  "action": "set_config",
  "action_parameters": {
    "request_body_buffering": "standard",
    "response_body_buffering": "none"
  }
}
``` …

This week’s release introduces new detections for denial-of-service attempts targeting React CVE-2026-23864 (https://www.cve.org/CVERecord?id=CVE-2026-23864 ↗︎).

Key Findings

• CVE-2026-23864 (https://www.cve.org/CVERecord?id=CVE-2026-23864 ↗︎) affects react-server-dom-parcel, react-server-dom-turbopack, and react-server-dom-webpack packages.
• Attackers can send crafted HTTP requests to Server Function endpoints, causing server crashes, out-of-memory exceptions, or excessive CPU usage.

Ruleset

Rule ID

Legacy Rule ID

Description

Previous Action

New Action

Comments

Cloudflare Managed Ruleset

...61680354

N/A

React Server - DOS - CVE:CVE-2026-23864 - 1

N/A

Block

This is a new detection.

Cloudflare Managed Ruleset

...dcdffcf8

N/A

React Server - DOS - CVE:CVE-2026-23864 - 2

N/A

Block

This is a new detection.

Cloudflare Managed Ruleset

...349edbc6

N/A

React Server - DOS - CVE:CVE-2026-23864 - 3

N/A

Block

This is a new detection.

Screenshot of new 2FA enrollment experience

In an effort to improve overall user security, users without 2FA will be prompted upon login to enroll in email 2FA. This will improve user security posture while minimizing friction. Users without email 2FA enabled will see a prompt to secure their account with additional factors upon logging in. Enrolling in 2FA remains optional, but strongly encouraged as it is the best way to prevent account takeovers.

We also made changes to existing 2FA screens to improve the user experience. Now we have distinct experiences for each 2FA factor type, reflective of the way that factor works.

For more information

• Configure Email Two Factor Authentication

You can now require Cloudflare Access protection for all hostnames in your account. When enabled, traffic to any hostname that does not have a matching Access application is automatically blocked.

This deny-by-default approach prevents accidental exposure of internal resources to the public Internet. If a developer deploys a new application or creates a DNS record without configuring an Access application, the traffic is blocked rather than exposed.

Require Cloudflare Access protection in the dashboard

How it works

• Blocked by default: Traffic to all hostnames in the account is blocked unless an Access application exists for that hostname.
• Explicit access required: To allow traffic, create an Access application with an Allow or Bypass policy.
• Hostname exemptions: You can exempt specific hostnames from this requirement.

To turn on this feature, refer to Require Access protection.

Three new API token permissions are available for Cloudflare Access, giving you finer-grained control when building automations and integrations:

• Access: Organizations Revoke — Grants the ability to revoke user sessions in a Zero Trust organization. Use this permission when you need a token that can terminate active sessions without broader write access to organization settings.
• Access: Population Read — Grants read access to the SCIM users and groups synced from an identity provider to Cloudflare Access. Use this permission for tokens that only need to read synced user and group data.
• Access: Population Write — Grants write access to the SCIM users and groups synced from an identity provider to Cloudflare Access. Use this permission for tokens that need to create or modify synced user and group data.

These permissions are scoped at the account level and can be combined with existing Access permissions.

For a full list of available permissions, refer to API token permissions.

You can now configure Workers to run close to infrastructure in legacy cloud regions to minimize latency to existing services and databases. This is most useful when your Worker makes multiple round trips.

To set a placement hint, set the placement.region property in your Wrangler configuration file:

{
	"placement": {
		"region": "aws:us-east-1",
	},
}

[placement]
region = "aws:us-east-1"

Placement hints support Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure region identifiers. Workers run in the Cloudflare data center ↗︎ with the lowest latency to the specified cloud region.

If your existing infrastructure is not in these cloud providers, expose it to placement probes with placement.host for layer 4 checks or placement.hostname for layer 7 checks. These probes are designed to locate single-homed infrastructure and are not suitable for anycasted or multicasted resources.

{
	"placement": {
		"host": "my_database_host.com:5432",
	},
}

[placement]
host = "my_database_host.com:5432"

{
	"placement": {
		"hostname": "my_api_server.com",
	},
}

[placement]
hostname = "my_api_server.com"
``` …

Cloudflare Rulesets now includes encode_base64() and sha256() functions, enabling you to generate signed request headers directly in rule expressions. These functions support common patterns like constructing a canonical string from request attributes, computing a SHA256 digest, and Base64-encoding the result.

---

New functions

Function

Description

Availability

encode_base64(input, flags)

Encodes a string to Base64 format. Optional flags parameter: u for URL-safe encoding, p for padding (adds = characters to make the output length a multiple of 4, as required by some systems). By default, output is standard Base64 without padding.

All plans (in header transform rules)

sha256(input)

Computes a SHA256 hash of the input string.

Requires enablement

Note

The sha256() function is available as an Enterprise add-on and requires a specific entitlement. Contact your account team to enable it.

---

Examples

Encode a string to Base64 format:

encode_base64("hello world")

Returns: aGVsbG8gd29ybGQ

Encode a string to Base64 format with padding:

encode_base64("hello world", "p")

Returns: aGVsbG8gd29ybGQ=

Perform a URL-safe Base64 encoding of a string:

encode_base64("hello world", "u")

Returns: aGVsbG8gd29ybGQ

Compute the SHA256 hash of a secret token:

sha256("my-token")

Returns a hash that your origin can validate to authenticate requests. …

AI Search now includes path filtering for both website and R2 data sources. You can now control which content gets indexed by defining include and exclude rules for paths.

By controlling what gets indexed, you can improve the relevance and quality of your search results. You can also use path filtering to split a single data source across multiple AI Search instances for specialized search experiences.

Path filtering configuration in AI Search

Path filtering uses micromatch ↗︎ patterns, so you can use * to match within a directory and ** to match across directories.

Use case

Include

Exclude

Index docs but skip drafts

**/docs/**

**/docs/drafts/**

Keep admin pages out of results

—

**/admin/**

Index only English content

**/en/**

—

Configure path filters when creating a new instance or update them anytime from Settings. Check out path filtering to learn more.

You can now create AI Search instances programmatically using the API. For example, use the API to create instances for each customer in a multi-tenant application or manage AI Search alongside your other infrastructure.

If you have created an AI Search instance via the dashboard before, you already have a service API token registered and can start creating instances programmatically right away. If not, follow the API guide to set up your first instance.

For example, you can now create separate search instances for each language on your website:

for lang in en fr es de; do
  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" \
    --data '{
      "id": "docs-'"$lang"'",
      "type": "web-crawler",
      "source": "example.com",
      "source_params": {
        "path_include": ["**/'"$lang"'/**"]
      }
    }'
done

Refer to the REST API reference for additional configuration options.

Workers KV has an updated dashboard UI with new dashboard styling that makes it easier to navigate and see analytics and settings for a KV namespace.

The new dashboard features a streamlined homepage for easy access to your namespaces and key operations, with consistent design with the rest of the dashboard UI updates. It also provides an improved analytics view.

New KV Dashboard Homepage

The updated dashboard is now available for all Workers KV users. Log in to the Cloudflare Dashboard ↗︎ to start exploring the new interface.

Auxiliary Workers are now fully supported when using full-stack frameworks, such as React Router and TanStack Start, that integrate with the Cloudflare Vite plugin. They are included alongside the framework's build output in the build output directory. Note that this feature requires Vite 7 or above.

Auxiliary Workers are additional Workers that can be called via service bindings from your main (entry) Worker. They are defined in the plugin config, as in the example below:

vite.config.tsts

import { defineConfig } from "vite";
import { tanstackStart } from "@tanstack/react-start/plugin/vite";
import { cloudflare } from "@cloudflare/vite-plugin";

export default defineConfig({
	plugins: [
		tanstackStart(),
		cloudflare({
			viteEnvironment: { name: "ssr" },
			auxiliaryWorkers: [{ configPath: "./wrangler.aux.jsonc" }],
		}),
	],
});

See the Vite plugin API docs for more info.