Cloudflare Release Notes

In AutoRAG, you can now view your object's custom metadata in the response from /search and /ai-search, and optionally add a context field in the custom metadata of an object to provide additional guidance for AI-generated answers.

You can add custom metadata to an object when uploading it to your R2 bucket.

Object's custom metadata in search responses

When you run a search, AutoRAG now returns any custom metadata associated with the object. This metadata appears in the response inside attributes then file , and can be used for downstream processing.

For example, the attributes section of your search response may look like:

{
	"attributes": {
		"timestamp": 1750001460000,
		"folder": "docs/",
		"filename": "launch-checklist.md",
		"file": {
			"url": "https://wiki.company.com/docs/launch-checklist",
			"context": "A checklist for internal launch readiness, including legal, engineering, and marketing steps."
		}
	}
}

Add a context field to guide LLM answers

…

In AutoRAG, you can now filter by an object's file name using the filename attribute, giving you more control over which files are searched for a given query.

This is useful when your application has already determined which files should be searched. For example, you might query a PostgreSQL database to get a list of files a user has access to based on their permissions, and then use that list to limit what AutoRAG retrieves.

For example, your search query may look like:

const response = await env.AI.autorag("my-autorag").search({
	query: "what is the project deadline?",
	filters: {
		type: "eq",
		key: "filename",
		value: "project-alpha-roadmap.md",
	},
});

This allows you to connect your application logic with AutoRAG's retrieval process, making it easy to control what gets searched without needing to reindex or modify your data.

Learn more in AutoRAG's metadata filtering documentation.

Simplified Worker Deployments with our SDKs

We've simplified the programmatic deployment of Workers via our Cloudflare SDKs. This update abstracts away the low-level complexities of the multipart/form-data upload process, allowing you to focus on your code while we handle the deployment mechanics.

This new interface is available in:

• cloudflare-typescript ↗︎ (4.4.1)
• cloudflare-python ↗︎ (4.3.1)

For complete examples, see our guide on programmatic Worker deployments.

The Old way: Manual API calls

Previously, deploying a Worker programmatically required manually constructing a multipart/form-data HTTP request, packaging your code and a separate metadata.json file. This was more complicated and verbose, and prone to formatting errors.

For example, here's how you would upload a Worker script previously with cURL:

curl https://api.cloudflare.com/client/v4/accounts/<account_id>/workers/scripts/my-hello-world-script \
  -X PUT \
  -H 'Authorization: Bearer <api_token>' \
  -F 'metadata={
        "main_module": "my-hello-world-script.mjs",
        "bindings": [
          {
            "type": "plain_text", …

Authoritative DNS analytics are now available on the account level via the Cloudflare GraphQL Analytics API.

This allows users to query DNS analytics across multiple zones in their account, by using the accounts filter.

Here is an example to retrieve the most recent DNS queries across all zones in your account that resulted in an NXDOMAIN response over a given time frame. Please replace a30f822fcd7c401984bf85d8f2a5111c with your actual account ID.

GraphQL example for account-level DNS analyticsgraphql

query GetLatestNXDOMAINResponses {
	viewer {
		accounts(filter: { accountTag: "a30f822fcd7c401984bf85d8f2a5111c" }) {
			dnsAnalyticsAdaptive(
				filter: {
					date_geq: "2025-06-16"
					date_leq: "2025-06-18"
					responseCode: "NXDOMAIN"
				}
				limit: 10000
				orderBy: [datetime_DESC]
			) {
				zoneTag
				queryName
				responseCode
				queryType
				datetime
			}
		}
	}
}

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

Gateway will now evaluate Network (Layer 4) policies before HTTP (Layer 7) policies. This change preserves your existing security posture and does not affect which traffic is filtered — but it may impact how notifications are displayed to end users.

This change will roll out progressively between July 14–18, 2025. If you use HTTP policies, we recommend reviewing your configuration ahead of rollout to ensure the user experience remains consistent.

Updated order of enforcement

Previous order:

1. DNS policies
2. HTTP policies
3. Network policies

New order:

1. DNS policies
2. Network policies
3. HTTP policies

Action required: Review your Gateway HTTP policies

This change may affect block notifications. For example:

• You have an HTTP policy to block example.com and display a block page.
• You also have a Network policy to block example.com silently (no client notification).

With the new order, the Network policy will trigger first — and the user will no longer see the HTTP block page.

To ensure users still receive a block notification, you can: …

Today we announced the public beta ↗︎ of remote bindings for local development. With remote bindings, you can now connect to deployed resources like R2 buckets and D1 databases while running Worker code on your local machine. This means you can test your local code changes against real data and services, without the overhead of deploying for each iteration.

Example configuration

To enable remote mode, add "experimental_remote" : true to each binding that you want to rely on a remote resource running on Cloudflare:

{
	"name": "my-worker",
	// Set this to today's date
	"compatibility_date": "2026-10-11",

	"r2_buckets": [
		{
			"bucket_name": "screenshots-bucket",
			"binding": "screenshots_bucket",
			"experimental_remote": true,
		},
	],
}

name = "my-worker"
# Set this to today's date
compatibility_date = "2026-10-11"

[[r2_buckets]]
bucket_name = "screenshots-bucket"
binding = "screenshots_bucket"
experimental_remote = true

When remote bindings are configured, your Worker still executes locally, but all binding calls are proxied to the deployed resource that runs on Cloudflare's network.

You can try out remote bindings for local development today with: …

Log Explorer is now GA, providing native observability and forensics for traffic flowing through Cloudflare.

Search and analyze your logs, natively in the Cloudflare dashboard. These logs are also stored in Cloudflare's network, eliminating many of the costs associated with other log providers.

Log Explorer dashboard

With Log Explorer, you can now:

• Monitor security and performance issues with custom dashboards – use natural language to define charts for measuring response time, error rates, top statistics and more.
• Investigate and troubleshoot issues with Log Search – use data type-aware search filters or custom sql to investigate detailed logs.
• Save time and collaborate with saved queries – save Log Search queries for repeated use or sharing with other users in your account.
• Access Log Explorer at the account and zone level – easily find Log Explorer at the account and zone level for querying any dataset.

For help getting started, refer to our documentation.

For those building Single Page Applications (SPAs) on Workers, you can now explicitly define which routes invoke your Worker script in Wrangler configuration. The run_worker_first config option has now been expanded to accept an array of route patterns, allowing you to more granularly specify when your Worker script runs.

Configuration example:

{
	"name": "my-spa-worker",
	// Set this to today's date
	"compatibility_date": "2026-10-11",
	"main": "./src/index.ts",
	"assets": {
		"directory": "./dist/",
		"not_found_handling": "single-page-application",
		"binding": "ASSETS",
		"run_worker_first": ["/api/*", "!/api/docs/*"]
	}
}

name = "my-spa-worker"
# Set this to today's date
compatibility_date = "2026-10-11"
main = "./src/index.ts"

[assets]
directory = "./dist/"
not_found_handling = "single-page-application"
binding = "ASSETS"
run_worker_first = [ "/api/*", "!/api/docs/*" ]

This new routing control was done in partnership with our community and customers who provided great feedback on our public proposal ↗︎. Thank you to everyone who brought forward use-cases and feedback on the design!

Prerequisites

…

Mitigations have been put in place for all existing and future deployments of sites with the Cloudflare adapter for Open Next in response to an identified Server-Side Request Forgery (SSRF) vulnerability in the @opennextjs/cloudflare package.

The vulnerability stemmed from an unimplemented feature in the Cloudflare adapter for Open Next, which allowed users to proxy arbitrary remote content via the /_next/image endpoint.

This issue allowed attackers to load remote resources from arbitrary hosts under the victim site's domain for any site deployed using the Cloudflare adapter for Open Next. For example: https://victim-site.com/_next/image?url=https://attacker.com. In this example, attacker-controlled content from attacker.com is served through the victim site's domain (victim-site.com), violating the same-origin policy and potentially misleading users or other services.

References: https://www.cve.org/cverecord?id=CVE-2025-6087 ↗︎, https://github.com/opennextjs/opennextjs-cloudflare/security/advisories/GHSA-rvpw-p7vw-wj3m ↗︎

Impact

• SSRF via unrestricted remote URL loading
• Arbitrary remote content loading
• Potential internal service exposure or phishing risks through domain abuse

Mitigation

The following mitigations have been put in place: …

Earlier this year, we announced the launch of the new Terraform v5 Provider. Unlike the earlier Terraform providers, v5 is automatically generated based on the OpenAPI Schemas for our REST APIs. Since launch, we have seen an unexpectedly high number of issues ↗︎ reported by customers. These issues currently impact about 15% of resources. We have been working diligently to address these issues across the company, and have released the v5.6.0 release which includes a number of bug fixes. Please keep an eye on this changelog for more information about upcoming releases.

Changes

• Broad fixes across resources with recurring diffs, including, but not limited to:
  • cloudflare_zero_trust_access_identity_provider
    • cloudflare_zone
• cloudflare_page_rules runtime panic when setting cache_level to cache_ttl_by_status
• Failure to serialize requests in cloudflare_zero_trust_tunnel_cloudflared_config
• Undocumented field 'priority' on zone_lockdown resource
• Missing importability for cloudflare_zero_trust_device_default_profile_local_domain_fallback and cloudflare_account_subscription
• New resources:
  • cloudflare_schema_validation_operation_settings
  • cloudflare_schema_validation_schemas
  • cloudflare_schema_validation_settings …

You can now grant members of your Cloudflare account read-only access to the Workers Platform.

The new "Workers Platform (Read-only)" role grants read-only access to all products typically used as part of Cloudflare's Developer Platform, including Workers, Pages, Durable Objects, KV, R2, Zones, Zone Analytics and Page Rules. When Cloudflare introduces new products to the Workers platform, we will add additional read-only permissions to this role.

Additionally, the role previously named "Workers Admin" has been renamed to "Workers Platform Admin". This change ensures that the name more accurately reflects the permissions granted — this role has always granted access to more than just Workers — it grants read and write access to the products mentioned above, and similarly, as new products are added to the Workers platform, we will add additional read and write permissions to this role.

You can review the updated roles in the developer docs.

Participating beta testers can now fully configure Internal DNS directly in the Cloudflare dashboard ↗︎.

Internal DNS enables customers to:

• Map internal hostnames to private IPs for services, devices, and applications not exposed to the public Internet

• Resolve internal DNS queries securely through Cloudflare Gateway

• Use split-horizon DNS to return different responses based on network context

• Consolidate internal and public DNS zones within a single management platform

What’s new in this release:

• Beta participants can now create and manage internal zones and views in the Cloudflare dashboard

Internal DNS UI

Note

The Internal DNS beta is currently only available to Enterprise customers.

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

This week’s roundup highlights multiple critical vulnerabilities across popular web frameworks, plugins, and enterprise platforms. The focus lies on remote code execution (RCE), server-side request forgery (SSRF), and insecure file upload vectors that enable full system compromise or data exfiltration.

Key Findings

• Cisco IOS XE (CVE-2025-20188): Critical RCE vulnerability enabling unauthenticated attackers to execute arbitrary commands on network infrastructure devices, risking total router compromise.
• Axios (CVE-2024-39338): SSRF flaw impacting server-side request control, allowing attackers to manipulate internal service requests when misconfigured with unsanitized user input.
• vBulletin (CVE-2025-48827, CVE-2025-48828): Two high-impact RCE flaws enabling attackers to remotely execute PHP code, compromising forum installations and underlying web servers.
• Invision Community (CVE-2025-47916): A critical RCE vulnerability allowing authenticated attackers to run arbitrary code in community platforms, threatening data and lateral movement risk.
• CrushFTP (CVE-2025-32102, CVE-2025-32103): SSRF vulnerabilities in upload endpoint processing permit attackers to pivot internal network scans and abuse internal services.
• Roundcube (CVE-2025-49113): RCE via email processing enables attackers to execute code upon viewing a crafted email — particularly dangerous for webmail deployments. …

Enterprise customers can now select NSEC3 as method for proof of non-existence on their zones.

What's new:

• NSEC3 support for live-signed zones – For both primary and secondary zones that are configured to be live-signed (also known as "on-the-fly signing"), NSEC3 can now be selected as proof of non-existence.

• NSEC3 support for pre-signed zones – Secondary zones that are transferred to Cloudflare in a pre-signed setup now also support NSEC3 as proof of non-existence.

For more information and how to enable NSEC3, refer to the NSEC3 documentation.

Workers Builds connects your Worker to a Git repository, and automates building and deploying your code on each pushed change.

To make CI/CD pipelines even more flexible, Workers Builds now automatically injects default environment variables into your build process (much like the defaults in Cloudflare Pages projects). You can use these variables to customize your build process based on the deployment context, such as the branch or commit.

The following environment variables are injected by default:

Environment Variable

Injected value

Example use-case

CI

true

Changing build behavior when run on CI versus locally

WORKERS_CI

1

Changing build behavior when run on Workers Builds versus locally

WORKERS_CI_BUILD_UUID

<build-uuid-of-current-build>

Passing the Build UUID along to custom workflows

WORKERS_CI_COMMIT_SHA

<sha1-hash-of-current-commit>

Passing current commit ID to error reporting, for example, Sentry

WORKERS_CI_BRANCH

<branch-name-from-push-event

Customizing build based on branch, for example, disabling debug logging on production …

Stream

We have increased the limits for Media Transformations:

• Input file size limit is now 100MB (was 40MB)
• Output video duration limit is now 1 minute (was 30 seconds)

Additionally, we have improved caching of the input asset, resulting in fewer requests to origin storage even when transformation options may differ.

For more information, learn about Transforming Videos.

Workers native integrations were originally launched in May 2023 ↗︎ to connect to popular database and observability providers with your Worker in just a few clicks. We are changing how developers connect Workers to these external services. The Integrations tab in the dashboard has been removed in favor of a more direct, command-line-based approach using Wrangler secrets.

What's changed

• Integrations tab removed: The integrations setup flow is no longer available in the Workers dashboard.
• Manual secret configuration: New connections should be configured by adding credentials as secrets to your Workers using npx wrangler secret put commands.

Impact on existing integrations

Existing integrations will continue to work without any changes required. If you have integrations that were previously created through the dashboard, they will remain functional.

Updating existing integrations

If you'd like to modify your existing integration, you can update the secrets, environment variables, or Tail Workers that were created from the original integration setup. …

This week’s update spotlights four critical vulnerabilities across CMS platforms, VoIP systems, and enterprise applications. Several flaws enable remote code execution or privilege escalation, posing significant enterprise risks.

Key Findings

• WordPress OttoKit Plugin (CVE-2025-27007): Privilege escalation flaw allows unauthenticated attackers to create or elevate user accounts, compromising WordPress administrative control.
• SAP NetWeaver (CVE-2025-42999): Remote Code Execution vulnerability enables attackers to execute arbitrary code on SAP NetWeaver systems, threatening core ERP and business operations.
• Fortinet FortiVoice (CVE-2025-32756): Buffer error vulnerability may lead to memory corruption and potential code execution, directly impacting enterprise VoIP infrastructure.
• Camaleon CMS (CVE-2024-46986): Remote Code Execution vulnerability allows attackers to gain full control over Camaleon CMS installations, exposing hosted content and underlying servers.

Impact

These vulnerabilities target widely deployed CMS, ERP, and VoIP systems. RCE flaws in SAP NetWeaver and Camaleon CMS allow full takeover of business-critical applications. Privilege escalation in OttoKit exposes WordPress environments to full administrative compromise. FortiVoice buffer handling issues risk destabilizing or fully compromising enterprise telephony systems.

Ruleset

Rule ID

Legacy Rule ID

Description

Previous Action

New Action

Comments

Cloudflare Managed Ruleset …

Custom Errors can now fetch and store assets and error pages from your origin even if they are served with a 4xx or 5xx HTTP status code — previously, only 200 OK responses were allowed.

What’s new:

• You can now upload error pages and error assets that return error status codes (for example, 403, 500, 502, 503, 504) when fetched.
• These assets are stored and minified at the edge, so they can be reused across multiple Custom Error rules without triggering requests to the origin.

This is especially useful for retrieving error content or downtime banners from your backend when you can’t override the origin status code.

Learn more in the Custom Errors documentation.