Cloudflare Release Notes

Earlier this year, we announced the launch of the new Terraform v5 Provider. We are aware of the high number of issues ↗︎ reported by the Cloudflare Community related to the v5 release. We have committed to releasing improvements on a two week cadence to ensure stability and reliability.

One key change we adopted in recent weeks is a pivot to more comprehensive, test-driven development. We are still evaluating individual issues, but are also investing in much deeper testing to drive our stabilization efforts. We will subsequently be investing in comprehensive migration scripts. As a result, you will see several of the highest traffic APIs have been stabilized in the most recent release, and are supported by comprehensive acceptance tests.

Thank you for continuing to raise issues. We triage them weekly and they help make our products stronger.

Changes

• Resources stabilized:
  • cloudflare_argo_smart_routing
  • cloudflare_bot_management
  • cloudflare_list
  • cloudflare_list_item
  • cloudflare_load_balancer
  • cloudflare_load_balancer_monitor
  • cloudflare_load_balancer_pool
  • cloudflare_spectrum_application
  • cloudflare_managed_transforms
  • cloudflare_url_normalization_settings
  • cloudflare_snippet …

We've updated preview URLs for Cloudflare Workers to support long branch names.

Previously, branch and Worker names exceeding the 63-character DNS limit would cause alias generation to fail, leaving pull requests without aliased preview URLs. This particularly impacted teams relying on descriptive branch naming.

Now, Cloudflare automatically truncates long branch names and appends a unique hash, ensuring every pull request gets a working preview link.

How it works

• 63 characters or less: <branch-name>-<worker-name> → Uses actual branch name as is
• 64 characters or more: <truncated-branch-name>--<hash>-<worker-name> → Uses truncated name with 4-character hash
• Hash generation: The hash is derived from the full branch name to ensure uniqueness
• Stable URLs: The same branch always generates the same hash across all commits

Requirements and compatibility

• Wrangler 4.30.0 or later: This feature requires updating to wrangler@4.30.0+
• No configuration needed: Works automatically with existing preview URL setups

We are changing how Python Workers are structured by default. Previously, handlers were defined at the top-level of a module as on_fetch, on_scheduled, etc. methods, but now they live in an entrypoint class.

Here's an example of how to now define a Worker with a fetch handler:

from workers import Response, WorkerEntrypoint

class Default(WorkerEntrypoint):
    async def fetch(self, request):
        return Response("Hello World!")

To keep using the old-style handlers, you can specify the disable_python_no_global_handlers compatibility flag in your wrangler file:

{
	"compatibility_flags": [
		"disable_python_no_global_handlers"
	]
}

compatibility_flags = [ "disable_python_no_global_handlers" ]

Consult the Python Workers documentation for more details.

The recent Cloudflare Terraform Provider ↗︎ and SDK releases (such as cloudflare-typescript ↗︎) bring significant improvements to the Workers developer experience. These updates focus on reliability, performance, and adding Python Workers support.

Terraform Improvements

Fixed Unwarranted Plan Diffs

Resolved several issues with the cloudflare_workers_script resource that resulted in unwarranted plan diffs, including:

• Using Durable Objects migrations
• Using some bindings such as secret_text
• Using smart placement

A resource should never show a plan diff if there isn't an actual change. This fix reduces unnecessary noise in your Terraform plan and is available in Cloudflare Terraform Provider 5.8.0.

Improved File Management

You can now specify content_file and content_sha256 instead of content. This prevents the Workers script content from being stored in the state file which greatly reduces plan diff size and noise. If your workflow synced plans remotely, this should now happen much faster since there is less data to sync. This is available in Cloudflare Terraform Provider 5.7.0.

Cloudflare Logpush now supports IBM Cloud Logs as a native destination.

Logs from Cloudflare can be sent to IBM Cloud Logs ↗︎ via Logpush. The setup can be done through the Logpush UI in the Cloudflare Dashboard or by using the Logpush API. The integration requires IBM Cloud Logs HTTP Source Address and an IBM API Key. The feature also allows for filtering events and selecting specific log fields.

For more information, refer to Destination Configuration documentation.

A minimal implementation of the MessageChannel API ↗︎ is now available in Workers. This means that you can use MessageChannel to send messages between different parts of your Worker, but not across different Workers.

The MessageChannel and MessagePort APIs will be available by default at the global scope with any worker using a compatibility date of 2025-08-15 or later. It is also available using the expose_global_message_channel compatibility flag, or can be explicitly disabled using the no_expose_global_message_channel compatibility flag.

const { port1, port2 } = new MessageChannel();

port2.onmessage = (event) => {
	console.log('Received message:', event.data);
};

port2.postMessage('Hello from port2!');

Any value that can be used with the structuredClone(...) API can be sent over the port.

Differences

There are a number of key limitations to the MessageChannel API in Workers:

• Transfer lists are currently not supported. This means that you will not be able to transfer ownership of objects like ArrayBuffer or MessagePort between ports.
• The MessagePort is not yet serializable. This means that you cannot send a MessagePort object through the postMessage method or via JSRPC calls. …

This week's update focuses on a wide range of enterprise software, from network infrastructure and security platforms to content management systems and development frameworks. Flaws include unsafe deserialization, OS command injection, SSRF, authentication bypass, and arbitrary file upload — many of which allow unauthenticated remote code execution. Notable risks include Cisco Identity Services Engine and Ivanti EPMM, where successful exploitation could grant attackers full administrative control of core network infrastructure and popular web services such as WordPress, SharePoint, and Ingress-Nginx, where security bypasses and arbitrary file uploads could lead to complete site or server compromise.

Key Findings

• Cisco Identity Services Engine (CVE-2025-20281): Insufficient input validation in a specific API of Cisco Identity Services Engine (ISE) and ISE-PIC allows an unauthenticated, remote attacker to execute arbitrary code with root privileges on an affected device.

• Wazuh Server (CVE-2025-24016): An unsafe deserialization vulnerability in Wazuh Server (versions 4.4.0 to 4.9.0) allows for remote code execution and privilege escalation. By injecting unsanitized data, an attacker can trigger an exception to execute arbitrary code on the server. …

Now, you can use .env files to provide secrets and override environment variables on the env object during local development with Wrangler and the Cloudflare Vite plugin.

Previously in local development, if you wanted to provide secrets or environment variables during local development, you had to use .dev.vars files. This is still supported, but you can now also use .env files, which are more familiar to many developers.

Using .env files in local development

You can create a .env file in your project root to define environment variables that will be used when running wrangler dev or vite dev. The .env file should be formatted like a dotenv file, such as KEY="VALUE":

.envbash

TITLE="My Worker"
API_TOKEN="dev-token"

When you run wrangler dev or vite dev, the environment variables defined in the .env file will be available in your Worker code via the env object:

export default {
	async fetch(request, env) {
		const title = env.TITLE; // "My Worker"
		const apiToken = env.API_TOKEN; // "dev-token"
		const response = await fetch(
			`https://api.example.com/data?token=${apiToken}`,
		);
		return new Response(`Title: ${title} - ` + (await response.text()));
	},
};

Multiple environments with .env files

…

New information about broadcast metrics and events is now available in Cloudflare Stream in the Live Input details of the Dashboard.

Live Input details showing metrics

You can now easily understand broadcast-side health and performance with new observability, which can help when troubleshooting common issues, particularly for new customers who are just getting started, and platform customers who may have limited visibility into how their end-users configure their encoders.

To get started, start a live stream (just getting started?), then visit the Live Input details page in Dash.

See our new live Troubleshooting guide to learn what these metrics mean and how to use them to address common broadcast issues.

You can now import waitUntil from cloudflare:workers to extend your Worker's execution beyond the request lifecycle from anywhere in your code.

Previously, waitUntil could only be accessed through the execution context (ctx) parameter passed to your Worker's handler functions. This meant that if you needed to schedule background tasks from deeply nested functions or utility modules, you had to pass the ctx object through multiple function calls to access waitUntil.

Now, you can import waitUntil directly and use it anywhere in your Worker without needing to pass ctx as a parameter:

import { waitUntil } from "cloudflare:workers";

export function trackAnalytics(eventData) {
	const analyticsPromise = fetch("https://analytics.example.com/track", {
		method: "POST",
		body: JSON.stringify(eventData),
	});

	// Extend execution to ensure analytics tracking completes
	waitUntil(analyticsPromise);
}

This is particularly useful when you want to:

• Schedule background tasks from utility functions or modules
• Extend execution for analytics, logging, or cleanup operations
• Avoid passing the execution context through multiple layers of function calls

import { waitUntil } from "cloudflare:workers";

export default {
	async fetch(request, env, ctx) { …

Now, you can use .env files to provide secrets and override environment variables on the env object during local development with Wrangler and the Cloudflare Vite plugin.

Previously in local development, if you wanted to provide secrets or environment variables during local development, you had to use .dev.vars files. This is still supported, but you can now also use .env files, which are more familiar to many developers.

Using .env files in local development

You can create a .env file in your project root to define environment variables that will be used when running wrangler dev or vite dev. The .env file should be formatted like a dotenv file, such as KEY="VALUE":

.envbash

TITLE="My Worker"
API_TOKEN="dev-token"

When you run wrangler dev or vite dev, the environment variables defined in the .env file will be available in your Worker code via the env object:

export default {
	async fetch(request, env) {
		const title = env.TITLE; // "My Worker"
		const apiToken = env.API_TOKEN; // "dev-token"
		const response = await fetch(
			`https://api.example.com/data?token=${apiToken}`,
		);
		return new Response(`Title: ${title} - ` + (await response.text()));
	},
};

Multiple environments with .env files

…

You can now import waitUntil from cloudflare:workers to extend your Worker's execution beyond the request lifecycle from anywhere in your code.

Previously, waitUntil could only be accessed through the execution context (ctx) parameter passed to your Worker's handler functions. This meant that if you needed to schedule background tasks from deeply nested functions or utility modules, you had to pass the ctx object through multiple function calls to access waitUntil.

Now, you can import waitUntil directly and use it anywhere in your Worker without needing to pass ctx as a parameter:

import { waitUntil } from "cloudflare:workers";

export function trackAnalytics(eventData) {
	const analyticsPromise = fetch("https://analytics.example.com/track", {
		method: "POST",
		body: JSON.stringify(eventData),
	});

	// Extend execution to ensure analytics tracking completes
	waitUntil(analyticsPromise);
}

This is particularly useful when you want to:

• Schedule background tasks from utility functions or modules
• Extend execution for analytics, logging, or cleanup operations
• Avoid passing the execution context through multiple layers of function calls

import { waitUntil } from "cloudflare:workers";

export default {
	async fetch(request, env, ctx) { …

When you deploy MX or Inline, not only can you apply email link isolation to suspicious links in all emails (including benign), you can now also apply email link isolation to all links of a specified disposition. This provides more flexibility in controlling user actions within emails.

For example, you may want to deliver suspicious messages but isolate the links found within them so that users who choose to interact with the links will not accidentally expose your organization to threats. This means your end users are more secure than ever before.

Expanded Email Link Isolation Configuration

To isolate all links within a message based on the disposition, select Settings > Link Actions > View and select Configure. As with other other links you isolate, an interstitial will be provided to warn users that this site has been isolated and the link will be recrawled live to evaluate if there are any changes in our threat intel. Learn more about this feature on Configure link actions ↗︎.

This feature is available across these Email security packages:

• Enterprise
• Enterprise + PhishGuard

By setting the value of the cache property to no-cache, you can force Cloudflare's cache to revalidate its contents with the origin when making subrequests from Cloudflare Workers.

index.jsjs

export default {
	async fetch(req, env, ctx) {
		const request = new Request("https://cloudflare.com", {
			cache: "no-cache",
		});
		const response = await fetch(request);
		return response;
	},
};

index.tsts

export default {
  async fetch(req, env, ctx): Promise<Response> {
		const request = new Request("https://cloudflare.com", { cache: 'no-cache'});
		const response = await fetch(request);
    return response;
  }
} satisfies ExportedHandler<Environment>

When no-cache is set, the Worker request will first look for a match in Cloudflare's cache, then:

• If there is a match, a conditional request is sent to the origin, regardless of whether or not the match is fresh or stale. If the resource has not changed, the cached version is returned. If the resource has changed, it will be downloaded from the origin, updated in the cache, and returned.
• If there is no match, Workers will make a standard request to the origin and cache the response. …

This week’s highlight focuses on two critical vulnerabilities affecting key infrastructure and enterprise content management platforms. Both flaws present significant remote code execution risks that can be exploited with minimal or no user interaction.

Key Findings

• Squid (≤6.3) — CVE-2025-54574: A heap buffer overflow occurs when processing Uniform Resource Names (URNs). This vulnerability may allow remote attackers to execute arbitrary code on the server. The issue has been resolved in version 6.4.

• Adobe AEM (≤6.5.23) — CVE-2025-54253: Due to a misconfiguration, attackers can achieve remote code execution without requiring any user interaction, posing a severe threat to affected deployments.

Impact

Both vulnerabilities expose critical attack vectors that can lead to full server compromise. The Squid heap buffer overflow allows remote code execution by crafting malicious URNs, which can lead to server takeover or denial of service. Given Squid’s widespread use as a caching proxy, this flaw could be exploited to disrupt network traffic or gain footholds inside secure environments.

Adobe AEM’s remote code execution vulnerability enables attackers to run arbitrary code on the content management server without any user involvement. This puts sensitive content, application integrity, and the underlying infrastructure at extreme risk. Exploitation could lead to data theft, defacement, or persistent backdoor installation. …

Cloudflare Load Balancing Monitors support loading and applying settings for a specific zone to monitoring requests to origin endpoints. This feature has been migrated to new infrastructure to improve reliability, performance, and accuracy.

All zone monitors have been tested against the new infrastructure. There should be no change to health monitoring results of currently healthy and active pools. Newly created or re-enabled pools may need validation of their monitor zone settings before being introduced to service, especially regarding correct application of mTLS.

What you can expect:

• More reliable application of zone settings to monitoring requests, including
  • Authenticated Origin Pulls
  • Aegis Egress IP Pools
  • Argo Smart Routing
  • HTTP/2 to Origin
• Improved support and bug fixes for retries, redirects, and proxied origin resolution
• Improved performance and reliability of monitoring requests within the Cloudflare network
• Unrelated CDN or WAF configuration changes should have no risk of impact to pool health