The new @cloudflare/actors ↗ library is now in beta!
The @cloudflare/actors library is a new SDK for Durable Objects and provides a powerful set of abstractions for building real-time, interactive, and multiplayer applications on top of Durable Objects. With beta usage and feedback, @cloudflare/actors will become the recommended way to build on Durable Objects and draws upon Cloudflare's experience building products/features on Durable Objects.
The name "actors" originates from the actor programming model, which closely ties to how Durable Objects are modelled.
The @cloudflare/actors library includes:
Actor class for using Durable Objects with a defined patternStorage and alarm helper methods can be combined with any Javascript class ↗ that defines your Durable Object, i.e, ones that extend DurableObject including the Actor class.
import { Storage } from "@cloudflare/actors/storage";
export class ChatRoom extends DurableObject<Env> { storage: Storage;
constructor(ctx: DurableObjectState, env: Env) { super(ctx, env) this.storage = new Storage(ctx.storage); this.storage.migrations = [{ idMonotonicInc: 1, description: "Create users table", sql: "CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY)" }] } async fetch(request: Request): Promise<Response> { // Run migrations before executing SQL query await this.storage.runMigrations();
// Query with SQL template let userId = new URL(request.url).searchParams.get("userId"); const query = this.storage.sql`SELECT * FROM users WHERE id = ${userId};` return new Response(`${JSON.stringify(query)}`); }}@cloudflare/actors library introduces the Actor class pattern. Actor lets you access Durable Objects without writing the Worker that communicates with your Durable Object (the Worker is created for you). By default, requests are routed to a Durable Object named "default".
export class MyActor extends Actor<Env> { async fetch(request: Request): Promise<Response> { return new Response('Hello, World!') }}
export default handler(MyActor);You can route to different Durable Objects by name within your Actor class using nameFromRequest ↗.
export class MyActor extends Actor<Env> { static nameFromRequest(request: Request): string { let url = new URL(request.url); return url.searchParams.get("userId") ?? "foo"; }
async fetch(request: Request): Promise<Response> { return new Response(`Actor identifier (Durable Object name): ${this.identifier}`); }}
export default handler(MyActor);For more examples, check out the library README ↗. @cloudflare/actors library is a place for more helpers and built-in patterns, like retry handling and Websocket-based applications, to reduce development overhead for common Durable Objects functionality. Please share feedback and what more you would like to see on our Discord channel ↗.
Zero Trust now includes Data security analytics, providing you with unprecedented visibility into your organization sensitive data.
The new dashboard includes:
Sensitive Data Movement Over Time:
Sensitive Data at Rest in SaaS & Cloud:
DLP Policy Activity:
To access the new dashboard, log in to Cloudflare One ↗ and go to Insights on the sidebar.
We're announcing the GA of User Groups for Cloudflare Dashboard and System for Cross Domain Identity Management (SCIM) User Groups, strengthening our RBAC capabilities with stable, production-ready primitives for managing access at scale.
What's New
User Groups [GA]: User Groups are a new Cloudflare IAM primitive that enable administrators to create collections of account members that are treated equally from an access control perspective. User Groups can be assigned permission policies, with individual members in the group inheriting all permissions granted to the User Group. User Groups can be created manually or via our APIs.
SCIM User Groups [GA]: Centralize & simplify your user and group management at scale by syncing memberships directly from your upstream identity provider (like Okta or Entra ID) to the Cloudflare Platform. This ensures Cloudflare stays in sync with your identity provider, letting you apply Permission Policies to those synced groups directly within the Cloudflare Dashboard.
Stability & Scale: These features have undergone extensive testing during the Public Beta period and are now ready for production use across enterprises of all sizes.
For more info:
Customers using Cloudflare Network Interconnect with the v1 dataplane can now subscribe to maintenance alert emails. These alerts notify you of planned maintenance windows that may affect your CNI circuits.
For more information, refer to Monitoring and alerts.
We’ve increased the total allowed size of blob fields on data points written to Workers Analytics Engine from 5 KB to 16 KB.
This change gives you more flexibility when logging rich observability data — such as base64-encoded payloads, AI inference traces, or custom metadata — without hitting request size limits.
You can find full details on limits for queries, filters, payloads, and more here in the Workers Analytics Engine limits documentation.
export default { async fetch(request, env) { env.analyticsDataset.writeDataPoint({ // The sum of all of the blob's sizes can now be 16 KB blobs: [ // The URL of the request to the Worker request.url, // Some metadata about your application you'd like to store JSON.stringify(metadata), // The version of your Worker this datapoint was collected from env.versionMetadata.tag, ], indexes: ["sample-index"], }); },};export default { async fetch(request, env) { env.analyticsDataset.writeDataPoint({ // The sum of all of the blob's sizes can now be 16 KB blobs: [ // The URL of the request to the Worker request.url, // Some metadata about your application you'd like to store JSON.stringify(metadata), // The version of your Worker this datapoint was collected from env.versionMetadata.tag, ], indexes: ["sample-index"], }); }};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.
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." } }}When you include a custom metadata field named context, AutoRAG attaches that value to each chunk of the file. When you run an /ai-search query, this context is passed to the LLM and can be used as additional input when generating an answer.
We recommend using the context field to describe supplemental information you want the LLM to consider, such as a summary of the document or a source URL. If you have several different metadata attributes, you can join them together however you choose within the context string.
For example:
{ "context": "summary: 'Checklist for internal product launch readiness, including legal, engineering, and marketing steps.'; url: 'https://wiki.company.com/docs/launch-checklist'"}This gives you more control over how your content is interpreted, without requiring you to modify the original contents of the file.
Learn more in AutoRAG's metadata filtering documentation.
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.
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.
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.
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:
For complete examples, see our guide on programmatic Worker deployments.
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", "name": "MESSAGE", "text": "Hello World!" } ], "compatibility_date": "$today" };type=application/json' \ -F 'my-hello-world-script.mjs=@-;filename=my-hello-world-script.mjs;type=application/javascript+module' <<EOFexport default { async fetch(request, env, ctx) { return new Response(env.MESSAGE, { status: 200 }); }};EOFWith the new SDK interface, you can now define your entire Worker configuration using a single, structured object.
This approach allows you to specify metadata like main_module, bindings, and compatibility_date as clearer properties directly alongside your script content. Our SDK takes this logical object and automatically constructs the complex multipart/form-data API request behind the scenes.
Here's how you can now programmatically deploy a Worker via the cloudflare-typescript SDK ↗
import Cloudflare from "cloudflare";import { toFile } from "cloudflare/index";
// ... client setup, script content, etc.
const script = await client.workers.scripts.update(scriptName, { account_id: accountID, metadata: { main_module: scriptFileName, bindings: [], }, files: { [scriptFileName]: await toFile(Buffer.from(scriptContent), scriptFileName, { type: "application/javascript+module", }), },});import Cloudflare from 'cloudflare';import { toFile } from 'cloudflare/index';
// ... client setup, script content, etc.
const script = await client.workers.scripts.update(scriptName, { account_id: accountID, metadata: { main_module: scriptFileName, bindings: [], }, files: { [scriptFileName]: await toFile(Buffer.from(scriptContent), scriptFileName, { type: 'application/javascript+module', }), },});View the complete example here: https://github.com/cloudflare/cloudflare-typescript/blob/main/examples/workers/script-upload.ts ↗
We've also made several fixes and enhancements to the Cloudflare Terraform provider ↗:
cloudflare_workers_script ↗ resource in Terraform, which previously was producing a diff even when there were no changes. Now, your terraform plan outputs will be cleaner and more reliable.cloudflare_workers_for_platforms_dispatch_namespace ↗, where the provider would attempt to recreate the namespace on a terraform apply. The resource now correctly reads its remote state, ensuring stability for production environments and CI/CD workflows.cloudflare_workers_route ↗ resource now allows for the script property to be empty, null, or omitted to indicate that pattern should be negated for all scripts (see routes docs). You can now reserve a pattern or temporarily disable a Worker on a route without deleting the route definition itself.primary_location_hint in the cloudflare_d1_database ↗ resource will no longer always try to recreate. You can now safely change the location hint for a D1 database without causing a destructive operation.We've also properly documented the Workers Script And Version Settings in our public OpenAPI spec and SDKs.
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.
Previous order:
New order:
This change may affect block notifications. For example:
example.com and display a block page.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:
This update is based on user feedback and aims to:
To learn more, visit the Gateway order of enforcement documentation.
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.
With Log Explorer, you can now:
For help getting started, refer to our documentation.
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.
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-04-03",
"r2_buckets": [ { "bucket_name": "screenshots-bucket", "binding": "screenshots_bucket", "experimental_remote": true, }, ],}name = "my-worker"# Set this to today's datecompatibility_date = "2026-04-03"
[[r2_buckets]]bucket_name = "screenshots-bucket"binding = "screenshots_bucket"experimental_remote = trueWhen 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:
wrangler dev --x-remote-bindings command.Have feedback? Join the discussion in our beta announcement ↗ to share feedback or report any issues.
A new Beta release for the Windows WARP client is now available on the beta releases downloads page.
This release contains new improvements in addition to the features and improvements introduced in Beta client version 2025.5.735.1.
Changes and improvements
Known issues
Microsoft has confirmed a regression with Windows 11 starting around 24H2 that may cause performance issues for some users. These performance issues could manifest as mouse lag, audio cracking, or other slowdowns. A fix from Microsoft is expected in early July.
Devices with KB5055523 installed may receive a warning about Win32/ClickFix.ABA being present in the installer. To resolve this false positive, update Microsoft Security Intelligence to version 1.429.19.0 or later.
DNS resolution may be broken when the following conditions are all true:
A new Beta release for the macOS WARP client is now available on the beta releases downloads page.
This release contains new improvements in addition to the features and improvements introduced in Beta client version 2025.5.735.1.
Changes and improvements
Known issues
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.
cloudflare_zero_trust_access_identity_provider
cloudflare_zonecloudflare_page_rules runtime panic when setting cache_level to cache_ttl_by_statuscloudflare_zero_trust_tunnel_cloudflared_configzone_lockdown resourcecloudflare_zero_trust_device_default_profile_local_domain_fallback and cloudflare_account_subscriptioncloudflare_schema_validation_operation_settingscloudflare_schema_validation_schemascloudflare_schema_validation_settingscloudflare_zero_trust_device_settingsFor a more detailed look at all of the changes, see the changelog ↗ in GitHub.
If you have an unaddressed issue with the provider, we encourage you to check the open issues ↗ and open a new one if one does not already exist for what you are experiencing.
If you are evaluating a move from v4 to v5, please make use of the
migration guide ↗. We have
provided automated migration scripts using Grit which simplify the transition, although these do not support implementations which
use Terraform modules, so customers making use of modules need to migrate manually. Please make use of terraform plan to test
your changes before applying, and let us know if you encounter any additional issues by reporting to our
GitHub repository ↗.
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-04-03", "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 datecompatibility_date = "2026-04-03"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!
To use advanced routing control with run_worker_first, you'll need:
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 ↗
The following mitigations have been put in place:
Server side updates to Cloudflare's platform to restrict the content loaded via the /_next/image endpoint to images. The update automatically mitigates the issue for all existing and any future sites deployed to Cloudflare using the affected version of the Cloudflare adapter for Open Next
Root cause fix: Pull request #727 ↗ to the Cloudflare adapter for Open Next. The patched version of the adapter has been released as @opennextjs/cloudflare@1.3.0
Package dependency update: Pull request cloudflare/workers-sdk#9608 ↗ to create-cloudflare (c3) to use the fixed version of the Cloudflare adapter for Open Next. The patched version of create-cloudflare has been published as create-cloudflare@2.49.3.
In addition to the automatic mitigation deployed on Cloudflare's platform, we encourage affected users to upgrade to @opennext/cloudflare v1.3.0 and use the remotePatterns ↗ filter in Next config if they need to allow-list external urls with images assets.
Participating beta testers can now fully configure Internal DNS directly in the Cloudflare dashboard ↗.
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
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
Impact
These vulnerabilities span core systems — from routers to e-commerce to email. RCE in Cisco IOS XE, Roundcube, and vBulletin poses full system compromise. SSRF in Axios and CrushFTP supports internal pivoting, while WooCommerce’s file upload bug opens doors to mass WordPress exploitation.
| Ruleset | Rule ID | Legacy Rule ID | Description | Previous Action | New Action | Comments |
|---|---|---|---|---|---|---|
| Cloudflare Managed Ruleset | 100783 | Cisco IOS XE - Remote Code Execution - CVE:CVE-2025-20188 | Log | Block | This is a New Detection | |
| Cloudflare Managed Ruleset | 100784 | Axios - SSRF - CVE:CVE-2024-39338 | Log | Block | This is a New Detection | |
| Cloudflare Managed Ruleset | 100785 | vBulletin - Remote Code Execution - CVE:CVE-2025-48827, CVE:CVE-2025-48828 | Log | Block | This is a New Detection | |
| Cloudflare Managed Ruleset | 100786 | Invision Community - Remote Code Execution - CVE:CVE-2025-47916 | Log | Block | This is a New Detection | |
| Cloudflare Managed Ruleset | 100791 | CrushFTP - SSRF - CVE:CVE-2025-32102, CVE:CVE-2025-32103 | Log | Block | This is a New Detection | |
| Cloudflare Managed Ruleset | 100792 | Roundcube - Remote Code Execution - CVE:CVE-2025-49113 | Log | Block | This is a New Detection | |
| Cloudflare Managed Ruleset | 100793 | XSS - Ontoggle | Log | Disabled | This is a New Detection | |
| Cloudflare Managed Ruleset | 100794 | WordPress WooCommerce Plugin - Dangerous File Upload - CVE:CVE-2025-47577 | Log | Block | This is a New Detection |
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.
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.
We have increased the limits for Media Transformations:
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 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 |
You can override these default values and add your own custom environment variables by navigating to your Worker > Settings > Environment variables.
Learn more in the Build configuration documentation.
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:
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.
You can now use the cf.worker.upstream_zone field in Transform Rules to control rule execution based on whether a request originates from Workers, including subrequests issued by Workers in other zones.
What's new:
cf.worker.upstream_zone is now supported in Transform Rules expressions.For example, to add a header when the subrequest comes from another zone:
Text in Expression Editor (replace myappexample.com with your domain):
(cf.worker.upstream_zone != "" and cf.worker.upstream_zone != "myappexample.com")Selected operation under Modify request header: Set static
Header name: X-External-Workers-Subrequest
Value: 1
This gives you more granular control in how you handle incoming requests for your zone.
Learn more in the Transform Rules documentation and Rules language fields reference.