Use our brand new onboarding experience for Cloudflare Zero Trust. New and returning users can now engage with a Get Started tab with walkthroughs for setting up common use cases end-to-end.
There are eight brand new onboarding guides in total:
Securely access a private network (sets up device client and Tunnel)
Device-to-device / mesh networking (sets up and connects multiple device clients)
Network to network connectivity (sets up and connects multiple WARP Connectors, makes reference to Magic WAN availability for Enterprise)
Secure web traffic (sets up device client, Gateway, pre-reqs, and initial policies)
Secure DNS for networks (sets up a new DNS location and Gateway policies)
Clientless web access (sets up Access to a web app, Tunnel, and public hostname)
Clientless SSH access (all the same + the web SSH experience)
Clientless RDP access (all the same + RDP-in-browser)
Each flow walks the user through the steps to configure the essential elements, and provides a “more details” panel with additional contextual information about what the user will accomplish at the end, along with why the steps they take are important.
Log Explorer customers can now monitor their data ingestion volume to keep track of their billing. Monthly usage is displayed at the top of the Log Search and Manage Datasets screens in Log Explorer.
You can now expect 3-5× faster indexing in AutoRAG, and with it, a brand new Jobs view to help you monitor indexing progress.
With each AutoRAG, indexing jobs are automatically triggered to sync your data source (i.e. R2 bucket) with your Vectorize index, ensuring new or updated files are reflected in your query results. You can also trigger jobs manually via the Sync API or by clicking “Sync index” in the dashboard.
With the new jobs observability, you can now:
View the status, job ID, source, start time, duration and last sync time for each indexing job
Inspect real-time logs of job events (e.g. Starting indexing data source...)
See a history of past indexing jobs under the Jobs tab of your AutoRAG
This makes it easier to understand what’s happening behind the scenes.
Coming soon: We’re adding APIs to programmatically check indexing status, making it even easier to integrate AutoRAG into your workflows.
Cloudflare Zero Trust customers can use the App Library to get full visibility over the SaaS applications that they use in their Gateway policies, CASB integrations, and Access for SaaS applications.
App Library, found under My Team, makes information available about all Applications that can be used across the Zero Trust product suite.
You can use the App Library to see:
How Applications are defined
Where they are referenced in policies
Whether they have Access for SaaS configured
Review their CASB findings and integration status.
Within individual Applications, you can also track their usage across your organization, and better understand user behavior.
This week’s roundup uncovers critical vulnerabilities affecting enterprise VoIP systems, webmail platforms, and a popular JavaScript framework. The risks range from authentication bypass to remote code execution (RCE) and buffer handling flaws, each offering attackers a path to elevate access or fully compromise systems.
Key Findings
Next.js - Auth Bypass: A newly detected authentication bypass flaw in the Next.js framework allows attackers to access protected routes or APIs without proper authorization, undermining application access controls.
Fortinet FortiVoice (CVE-2025-32756): A buffer error vulnerability in FortiVoice systems that could lead to memory corruption and potential code execution or service disruption in enterprise telephony environments.
Roundcube (CVE-2025-49113): A critical RCE flaw allowing unauthenticated attackers to execute arbitrary PHP code via crafted requests, leading to full compromise of mail servers and user inboxes.
Impact
These vulnerabilities affect core business infrastructure, from web interfaces to voice communications and email platforms. The Roundcube RCE and FortiVoice buffer flaw offer potential for deep system access, while the Next.js auth bypass undermines trust boundaries in modern web apps.
Workers now support breakpoint debugging using VSCode's built-in JavaScript Debug Terminals ↗. All you have to do is open a JS debug terminal (Cmd + Shift + P and then type javascript debug) and run wrangler dev (or vite dev) from within the debug terminal. VSCode will automatically connect to your running Worker (even if you're running multiple Workers at once!) and start a debugging session.
In 2023 we announced breakpoint debugging support ↗ for Workers, which meant that you could easily debug your Worker code in Wrangler's built-in devtools (accessible via the [d] hotkey) as well as multiple other devtools clients, including VSCode ↗. For most developers, breakpoint debugging via VSCode is the most natural flow, but until now it's required manually configuring a launch.json file ↗, running wrangler dev, and connecting via VSCode's built-in debugger. Now it's much more seamless!
You can now specify the number of connections your Hyperdrive configuration uses to connect to your origin database.
All configurations have a minimum of 5 connections. The maximum connection count for a Hyperdrive configuration depends on the Hyperdrive limits of your Workers plan.
This feature allows you to right-size your connection pool based on your database capacity and application requirements. You can configure connection counts through the Cloudflare dashboard or API.
Browser-based RDP with Cloudflare Access is now available in open beta for all Cloudflare customers. It enables secure, remote Windows server access without VPNs or RDP clients.
With browser-based RDP, you can:
Control how users authenticate to internal RDP resources with single sign-on (SSO), multi-factor authentication (MFA), and granular access policies.
Record who is accessing which servers and when to support regulatory compliance requirements and to gain greater visibility in the event of a security event.
Eliminate the need to install and manage software on user devices. You will only need a web browser.
Reduce your attack surface by keeping your RDP servers off the public Internet and protecting them from common threats like credential stuffing or brute-force attacks.
We are introducing a new feature of AI Crawl Control — Pay Per Crawl. Pay Per Crawl enables site owners to require payment from AI crawlers every time the crawlers access their content, thereby fostering a fairer Internet by enabling site owners to control and monetize how their content gets used by AI.
For Site Owners:
Set pricing and select which crawlers to charge for content access
Manage payments via Stripe
Monitor analytics on successful content deliveries
For AI Crawler Owners:
Use HTTP headers to request and accept pricing
Receive clear confirmations on charges for accessed content
These endpoints support filtering and breakdowns by:
bot: Bot name.
bot_operator: The organization or entity operating the bot.
bot_category: Classification of bot type.
The previously available verified_bots endpoints have now been deprecated in favor of this set of bot insights APIs.
While current data still focuses on verified bots, we plan to expand support for unverified bot traffic in the future.
Learn more about the new Radar bot and crawler insights in our blog post ↗.
You can now use any of Vite's static asset handling ↗ features in your Worker as well as in your frontend.
These include importing assets as URLs, importing as strings and importing from the public directory as well as inlining assets.
Additionally, assets imported as URLs in your Worker are now automatically moved to the client build output.
Here is an example that fetches an imported asset using the assets binding and modifies the response.
// Import the asset URL// This returns the resolved path in development and productionimport myImage from "./my-image.png";export default { async fetch(request, env) { // Fetch the asset using the binding const response = await env.ASSETS.fetch(new URL(myImage, request.url)); // Create a new `Response` object that can be modified const modifiedResponse = new Response(response.body, response); // Add an additional header modifiedResponse.headers.append("my-header", "imported-asset"); // Return the modified response return modifiedResponse; },};
Refer to Static Assets in the Cloudflare Vite plugin docs for more info.
A new GA release for the Android Cloudflare One Agent is now available in the Google Play Store ↗. This release
contains improvements and new exciting features, including post-quantum cryptography.
By tunneling your corporate network traffic over Cloudflare, you can now gain the immediate protection of post-quantum cryptography ↗ without needing to upgrade any of your individual corporate applications or systems.
Changes and improvements
QLogs are now disabled by default and can be enabled in the app by turning on Enable qlogs under Settings > Advanced > Diagnostics > Debug Logs. The QLog setting from previous releases will no longer be respected.
DNS over HTTPS traffic is now included in the WARP tunnel by default.
The WARP client now applies post-quantum cryptography ↗ end-to-end on enabled devices accessing resources behind a Cloudflare Tunnel. This feature can be enabled by MDM.
Fixed an issue that caused WARP connection failures on ChromeOS devices.
A new GA release for the iOS Cloudflare One Agent is now available in the iOS App Store ↗. This release
contains improvements and new exciting features, including post-quantum cryptography.
By tunneling your corporate network traffic over Cloudflare, you can now gain the immediate protection of post-quantum cryptography ↗ without needing to upgrade any of your individual corporate applications or systems.
Changes and improvements
QLogs are now disabled by default and can be enabled in the app by turning on Enable qlogs under Settings > Advanced > Diagnostics > Debug Logs. The QLog setting from previous releases will no longer be respected.
DNS over HTTPS traffic is now included in the WARP tunnel by default.
The WARP client now applies post-quantum cryptography ↗ end-to-end on enabled devices accessing resources behind a Cloudflare Tunnel. This feature can be enabled by MDM.
The Email Routing platform supports SPF ↗ records and DKIM (DomainKeys Identified Mail) ↗ signatures and
honors these protocols when the sending domain has them configured. However, if the sending domain doesn't implement them,
we still forward the emails to upstream mailbox providers.
Starting on July 3, 2025, we will require all emails to be authenticated using at least one of the protocols, SPF or DKIM, to
forward them. We also strongly recommend that all senders implement the DMARC protocol.
If you are using a Worker with an Email trigger to receive email messages and forward them upstream, you will need to handle the case where
the forward action may fail due to missing authentication on the incoming email.
SPAM has been a long-standing issue with email. By enforcing mail authentication, we will increase the efficiency of identifying abusive senders and blocking
bad emails.
If you're an email server delivering emails to large mailbox providers, it's likely you already use these protocols; otherwise, please ensure
you have them properly configured.
Magic Transit customers can now configure AS prepending on their BYOIP prefixes advertised at the Cloudflare edge. This allows for smoother traffic migration and minimizes packet loss when changing providers.
AS prepending makes the Cloudflare route less preferred by increasing the AS path length. You can use this to gradually shift traffic away from Cloudflare before withdrawing a prefix, avoiding abrupt routing changes.
Prepending can be configured via the API or through BGP community values when peering with the Magic Transit routing table. For more information, refer to Advertise prefixes.
Now, you can use remote bindings with your Next.js applications through the @opennextjs/cloudflare adaptor ↗ by enabling the experimental feature in your next.config.ts:
Then, all you have to do is specify which bindings you want connected to the deployed resource on your Cloudflare account via the experimental_remote flag in your binding definition:
You can then run next dev to start a local development session (or start a preview with opennextjs-cloudflare preview), and all requests to env.MY_BUCKET will be proxied to the remote testing-bucket — rather than the default local binding simulations.
Remote bindings & ISR
Remote bindings are also used during the build process, which comes with significant benefits for pages using Incremental Static Regeneration (ISR) ↗. During the build step for an ISR page, your server executes the page's code just as it would for normal user requests. If a page needs data to display (like fetching user info from KV), those requests are actually made. The server then uses this fetched data to render the final HTML.
Data fetching is a critical part of this process, as the finished HTML is only as good as the data it was built with. If the build process can't fetch real data, you end up with a pre-rendered page that's empty or incomplete.
With remote bindings support in OpenNext, your pre-rendered pages are built with real data from the start. The build process uses any configured remote bindings, and any data fetching occurs against the deployed resources on your Cloudflare account.
Workers can now talk to each other across separate dev commands using service bindings and tail consumers, whether started with vite dev or wrangler dev.
Simply start each Worker in its own terminal:
# Terminal 1vite dev# Terminal 2wrangler dev
This is useful when different teams maintain different Workers, or when each Worker has its own build setup or tooling.
AI is supercharging app development for everyone, but we need a safe way to run untrusted, LLM-written code. We’re introducing Sandboxes ↗, which let your Worker run actual processes in a secure, container-based environment.
exec(command: string, args: string[], options?: { stream?: boolean }):Execute a command in the sandbox.
gitCheckout(repoUrl: string, options: { branch?: string; targetDir?: string; stream?: boolean }): Checkout a git repository in the sandbox.
mkdir(path: string, options: { recursive?: boolean; stream?: boolean }): Create a directory in the sandbox.
writeFile(path: string, content: string, options: { encoding?: string; stream?: boolean }): Write content to a file in the sandbox.
readFile(path: string, options: { encoding?: string; stream?: boolean }): Read content from a file in the sandbox.
deleteFile(path: string, options?: { stream?: boolean }): Delete a file from the sandbox.
renameFile(oldPath: string, newPath: string, options?: { stream?: boolean }): Rename a file in the sandbox.
moveFile(sourcePath: string, destinationPath: string, options?: { stream?: boolean }): Move a file from one location to another in the sandbox.
ping(): Ping the sandbox.
Sandboxes are still experimental. We're using them to explore how isolated, container-like workloads might scale on Cloudflare — and to help define the developer experience around them.
You can try it today from your Worker, with just a few lines of code. Let us know what you build.
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:
Storage helpers for querying embeddeded, per-object SQLite storage
Storage helpers for managing SQL schema migrations
Alarm helpers for scheduling multiple alarms provided a date, delay in seconds, or cron expression
Actor class for using Durable Objects with a defined pattern
Durable Objects Workers API ↗ is always available for your application as needed
Storage 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:
See patterns and trends in how sensitive data moves across your environment. This helps understand where data is flowing and identify common paths.
Sensitive Data at Rest in SaaS & Cloud:
View an inventory of sensitive data stored within your corporate SaaS applications (for example, Google Drive, Microsoft 365) and cloud accounts (such as AWS S3).
DLP Policy Activity:
Identify which of your Data Loss Prevention (DLP) policies are being triggered most often.
See which specific users are responsible for triggering DLP policies.
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.
