This week highlights four important vendor- and component-specific issues: an authentication bypass in SimpleHelp (CVE-2024-57727), an information-disclosure flaw in Flowise Cloud (CVE-2025-58434), an SSRF in the WordPress plugin Ditty (CVE-2025-8085), and a directory-traversal bug in Vite (CVE-2025-30208). These are paired with improvements to our generic detection coverage (SQLi, SSRF) to raise the baseline and reduce noisy gaps.
Key Findings
-
SimpleHelp (CVE-2024-57727): Authentication bypass in SimpleHelp that can allow unauthorized access to management interfaces or sessions.
-
Flowise Cloud (CVE-2025-58434): Information-disclosure vulnerability in Flowise Cloud that may expose sensitive configuration or user data to unauthenticated or low-privileged actors.
-
WordPress:Plugin: Ditty (CVE-2025-8085): SSRF in the Ditty WordPress plugin enabling server-side requests that could reach internal services or cloud metadata endpoints.
-
Vite (CVE-2025-30208): Directory-traversal vulnerability in Vite allowing access to filesystem paths outside the intended web root.
Impact
These vulnerabilities allow attackers to gain access, escalate privileges, or execute actions that were previously unavailable:
-
SimpleHelp (CVE-2024-57727): An authentication bypass that can let unauthenticated attackers access management interfaces or hijack sessions — enabling lateral movement, credential theft, or privilege escalation within affected environments.
-
Flowise Cloud (CVE-2025-58434): Information-disclosure flaw that can expose sensitive configuration, tokens, or user data; leaked secrets may be chained into account takeover or privileged access to backend services.
-
WordPress:Plugin: Ditty (CVE-2025-8085): SSRF that enables server-side requests to internal services or cloud metadata endpoints, potentially allowing attackers to retrieve credentials or reach otherwise inaccessible infrastructure, leading to privilege escalation or cloud resource compromise.
-
Vite (CVE-2025-30208): Directory-traversal vulnerability that can expose filesystem contents outside the web root (configuration files, keys, source code), which attackers can use to escalate privileges or further compromise systems.
Ruleset Rule ID Legacy Rule ID Description Previous Action New Action Comments Cloudflare Managed Ruleset 100717 SimpleHelp - Auth Bypass - CVE:CVE-2024-57727 Log Block This rule is merged to 100717 in legacy WAF and Cloudflare Managed Ruleset 100775 Flowise Cloud - Information Disclosure - CVE:CVE-2025-58434 Log Block This is a New Detection Cloudflare Managed Ruleset 100881 WordPress:Plugin:Ditty - SSRF - CVE:CVE-2025-8085 Log Block This is a New Detection Cloudflare Managed Ruleset 100887 Vite - Directory Traversal - CVE:CVE-2025-30208 Log Block This is a New Detection -
This week highlights multiple critical Cisco vulnerabilities (CVE-2025-20363, CVE-2025-20333, CVE-2025-20362). This flaw stems from improper input validation in HTTP(S) requests. An authenticated VPN user could send crafted requests to execute code as root, potentially compromising the device.
Key Findings
- Cisco (CVE-2025-20333, CVE-2025-20362, CVE-2025-20363): Multiple vulnerabilities that could allow attackers to exploit unsafe deserialization and input validation flaws. Successful exploitation may result in arbitrary code execution, privilege escalation, or command injection on affected systems.
Impact
Cisco (CVE-2025-20333, CVE-2025-20362, CVE-2025-20363): Exploitation enables attackers to escalate privileges or achieve remote code execution via command injection.
Ruleset Rule ID Legacy Rule ID Description Previous Action New Action Comments Cloudflare Managed Ruleset 100788 Cisco Secure Firewall Adaptive Security Appliance - Remote Code Execution - CVE:CVE-2025-20333, CVE:CVE-2025-20362, CVE:CVE-2025-20363 N/A Disabled This is a New Detection Cloudflare Managed Ruleset 100788A Cisco Secure Firewall Adaptive Security Appliance - Remote Code Execution - CVE:CVE-2025-20333, CVE:CVE-2025-20362, CVE:CVE-2025-20363 N/A Disabled This is a New Detection
Managed Ruleset Updated
This update introduces 11 new detections in the Cloudflare Managed Ruleset (all currently set to Disabled mode to preserve remediation logic and allow quick activation if needed). The rules cover a broad spectrum of threats - SQL injection techniques, command and code injection, information disclosure of common files, URL anomalies, and cross-site scripting.
Ruleset Rule ID Legacy Rule ID Description Previous Action New Action Comments Cloudflare Managed Ruleset 100859A SQLi - UNION - 3 N/A Disabled This is a New Detection Cloudflare Managed Ruleset 100889 Command Injection - Generic 9 N/A Disabled This is a New Detection Cloudflare Managed Ruleset 100890 Information Disclosure - Common Files - 2 N/A Disabled This is a New Detection Cloudflare Managed Ruleset 100891 Anomaly:URL - Relative Paths N/A Disabled This is a New Detection Cloudflare Managed Ruleset 100894 XSS - Inline Function N/A Disabled This is a New Detection Cloudflare Managed Ruleset 100895 XSS - DOM N/A Disabled This is a New Detection Cloudflare Managed Ruleset 100896 SQLi - MSSQL Length Enumeration N/A Disabled This is a New Detection Cloudflare Managed Ruleset 100897 Generic Rules - Code Injection - 3 N/A Disabled This is a New Detection Cloudflare Managed Ruleset 100898 SQLi - Evasion N/A Disabled This is a New Detection Cloudflare Managed Ruleset 100899 SQLi - Probing 2 N/A Disabled This is a New Detection Cloudflare Managed Ruleset 100900 SQLi - Probing N/A Disabled This is a New Detection
The
ctx.exportsAPI contains automatically-configured bindings corresponding to your Worker's top-level exports. For each top-level export extendingWorkerEntrypoint,ctx.exportswill contain a Service Binding by the same name, and for each export extendingDurableObject(and for which storage has been configured via a migration),ctx.exportswill contain a Durable Object namespace binding. This means you no longer have to configure these bindings explicitly inwrangler.jsonc/wrangler.toml.Example:
JavaScript import { WorkerEntrypoint } from "cloudflare:workers";export class Greeter extends WorkerEntrypoint {greet(name) {return `Hello, ${name}!`;}}export default {async fetch(request, env, ctx) {let greeting = await ctx.exports.Greeter.greet("World")return new Response(greeting);}}At present, you must use the
enable_ctx_exportscompatibility flag to enable this API, though it will be on by default in the future.
Today, we're launching the new Cloudflare Pipelines: a streaming data platform that ingests events, transforms them with SQL, and writes to R2 as Apache Iceberg ↗ tables or Parquet files.
Pipelines can receive events via HTTP endpoints or Worker bindings, transform them with SQL, and deliver to R2 with exactly-once guarantees. This makes it easy to build analytics-ready warehouses for server logs, mobile application events, IoT telemetry, or clickstream data without managing streaming infrastructure.
For example, here's a pipeline that ingests clickstream events and filters out bot traffic while extracting domain information:
INSERT into events_tableSELECTuser_id,lower(event) AS event_type,to_timestamp_micros(ts_us) AS event_time,regexp_match(url, '^https?://([^/]+)')[1] AS domain,url,referrer,user_agentFROM events_jsonWHERE event = 'page_view'AND NOT regexp_like(user_agent, '(?i)bot|spider');Get started by creating a pipeline in the dashboard or running a single command in Wrangler:
Terminal window npx wrangler pipelines setupCheck out our getting started guide to learn how to create a pipeline that delivers events to an Iceberg table you can query with R2 SQL. Read more about today's announcement in our blog post ↗.
Today, we're launching the open beta for R2 SQL: A serverless, distributed query engine that can efficiently analyze petabytes of data in Apache Iceberg ↗ tables managed by R2 Data Catalog.
R2 SQL is ideal for exploring analytical and time-series data stored in R2, such as logs, events from Pipelines, or clickstream and user behavior data.
If you already have a table in R2 Data Catalog, running queries is as simple as:
Terminal window npx wrangler r2 sql query YOUR_WAREHOUSE "SELECTuser_id,event_type,valueFROM events.user_eventsWHERE event_type = 'CHANGELOG' or event_type = 'BLOG'AND __ingest_ts > '2025-09-24T00:00:00Z'ORDER BY __ingest_ts DESCLIMIT 100"To get started with R2 SQL, check out our getting started guide or learn more about supported features in the SQL reference. For a technical deep dive into how we built R2 SQL, read our blog post ↗.
We’re shipping three updates to Browser Rendering:
- Playwright support is now Generally Available and synced with Playwright v1.55 ↗, giving you a stable foundation for critical automation and AI-agent workflows.
- We’re also adding Stagehand support (Beta) so you can combine code with natural language instructions to build more resilient automations.
- Finally, we’ve tripled limits for paid plans across both the REST API and Workers Bindings to help you scale.
To get started with Stagehand, refer to the Stagehand example that uses Stagehand and Workers AI to search for a movie on this example movie directory ↗, extract its details using natural language (title, year, rating, duration, and genre), and return the information along with a screenshot of the webpage.
Stagehand example const stagehand = new Stagehand({env: "LOCAL",localBrowserLaunchOptions: { cdpUrl: endpointURLString(env.BROWSER) },llmClient: new WorkersAIClient(env.AI),verbose: 1,});await stagehand.init();const page = stagehand.page;await page.goto('https://demo.playwright.dev/movies');// if search is a multi-step action, stagehand will return an array of actions it needs to act onconst actions = await page.observe('Search for "Furiosa"');for (const action of actions)await page.act(action);await page.act('Click the search result');// normal playwright functions work as expectedawait page.waitForSelector('.info-wrapper .cast');let movieInfo = await page.extract({instruction: 'Extract movie information',schema: z.object({title: z.string(),year: z.number(),rating: z.number(),genres: z.array(z.string()),duration: z.number().describe("Duration in minutes"),}),});await stagehand.close();
AutoRAG is now AI Search! The new name marks a new and bigger mission: to make world-class search infrastructure available to every developer and business.
With AI Search you can now use models from different providers like OpenAI and Anthropic. By attaching your provider keys to the AI Gateway linked to your AI Search instance, you can use many more models for both embedding and inference.
To use AI Search with other model providers:
- Add provider keys to AI Gateway
- Go to AI > AI Gateway in the dashboard.
- Select or create an AI gateway.
- In Provider Keys, choose your provider, click Add, and enter the key.
- Connect a gateway to AI Search: When creating a new AI Search, select the AI Gateway with your provider keys. For an existing AI Search, go to Settings and switch to a gateway that has your keys under Resources.
- Select models: Embedding models are only available to be changed when creating a new AI Search. Generation model can be selected when creating a new AI Search and can be changed at any time in Settings.
Once configured, your AI Search instance will be able to reference models available through your AI Gateway when making a
/ai-searchrequest:JavaScript export default {async fetch(request, env) {// Query your AI Search instance with a natural language question to an OpenAI modelconst result = await env.AI.autorag("my-ai-search").aiSearch({query: "What's new for Cloudflare Birthday Week?",model: "openai/gpt-5"});// Return only the generated answer as plain textreturn new Response(result.response, {headers: { "Content-Type": "text/plain" },});},};In the coming weeks we will also roll out updates to align the APIs with the new name. The existing APIs will continue to be supported for the time being. Stay tuned to the AI Search Changelog and Discord ↗ for more updates!
- Add provider keys to AI Gateway
You can now run more Containers concurrently with higher limits on CPU, memory, and disk.
Limit New Limit Previous Limit Memory for concurrent live Container instances 400GiB 40GiB vCPU for concurrent live Container instances 100 20 Disk for concurrent live Container instances 2TB 100GB You can now run 1000 instances of the
devinstance type, 400 instances ofbasic, or 100 instances ofstandardconcurrently.This opens up new possibilities for running larger-scale workloads on Containers.
See the getting started guide to deploy your first Container, and the limits documentation for more details on the available instance types and limits.
You can now more precisely control your HTTP DLP policies by specifying whether to scan the request or response body, helping to reduce false positives and target specific data flows.
In the Gateway HTTP policy builder, you will find a new selector called Body Phase. This allows you to define the direction of traffic the DLP engine will inspect:
- Request Body: Scans data sent from a user's machine to an upstream service. This is ideal for monitoring data uploads, form submissions, or other user-initiated data exfiltration attempts.
- Response Body: Scans data sent to a user's machine from an upstream service. Use this to inspect file downloads and website content for sensitive data.
For example, consider a policy that blocks Social Security Numbers (SSNs). Previously, this policy might trigger when a user visits a website that contains example SSNs in its content (the response body). Now, by setting the Body Phase to Request Body, the policy will only trigger if the user attempts to upload or submit an SSN, ignoring the content of the web page itself.
All policies without this selector will continue to scan both request and response bodies to ensure continued protection.
For more information, refer to Gateway HTTP policy selectors.
Cloudflare has launched sign in with GitHub as a log in option. This feature is available to all users with a verified email address who are not using SSO. To use it, simply click on the
Sign in with GitHubbutton on the dashboard login page. You will be logged in with your primary GitHub email address.
Single sign-on (SSO) streamlines the process of logging into Cloudflare for Enterprise customers who manage a custom email domain and manage their own identity provider. Instead of managing a password and two-factor authentication credentials directly for Cloudflare, SSO lets you reuse your existing login infrastructure to seamlessly log in. SSO also provides additional security opportunities such as device health checks which are not available natively within Cloudflare.
Historically, SSO was only available for Enterprise accounts. Today, we are announcing that we are making SSO available to all users for free. We have also added the ability to directly manage SSO configurations using the API. This removes the previous requirement to contact support to configure SSO.
You can now enable automatic compaction for Apache Iceberg ↗ tables in R2 Data Catalog to improve query performance.
Compaction is the process of taking a group of small files and combining them into fewer larger files. This is an important maintenance operation as it helps ensure that query performance remains consistent by reducing the number of files that needs to be scanned.
To enable automatic compaction in R2 Data Catalog, find it under R2 Data Catalog in your R2 bucket settings in the dashboard.
Or with Wrangler, run:
Terminal window npx wrangler r2 bucket catalog compaction enable <BUCKET_NAME> --target-size 128 --token <API_TOKEN>To get started with compaction, check out manage catalogs. For best practices and limitations, refer to about compaction.
This week highlights a critical vendor-specific vulnerability: a deserialization flaw in the License Servlet of Fortra’s GoAnywhere MFT. By forging a license response signature, an attacker can trigger deserialization of arbitrary objects, potentially leading to command injection.
Key Findings
- GoAnywhere MFT (CVE-2025-10035): Deserialization vulnerability in the License Servlet that allows attackers with a forged license response signature to deserialize arbitrary objects, potentially resulting in command injection.
Impact
GoAnywhere MFT (CVE-2025-10035): Exploitation enables attackers to escalate privileges or achieve remote code execution via command injection.
Ruleset Rule ID Legacy Rule ID Description Previous Action New Action Comments Cloudflare Managed Ruleset 100787 Fortra GoAnywhere - Auth Bypass - CVE:CVE-2025-10035 N/A Block This is a New Detection
Email security relies on your submissions to continuously improve our detection models. However, we often receive submissions in formats that cannot be ingested, such as incomplete EMLs, screenshots, or text files.
To ensure all customer feedback is actionable, we have launched two new features to manage invalid submissions sent to our team and user submission aliases:
- Email Notifications: We now automatically notify users by email when they provide an invalid submission, educating them on the correct format. To disable notifications, go to Settings ↗ > Invalid submission emails and turn the feature off.
- Invalid Submission dashboard: You can quickly identify which users need education to provide valid submissions so Cloudflare can provide continuous protection.
Learn more about this feature on invalid submissions.
This feature is available across these Email security packages:
- Advantage
- Enterprise
- Enterprise + PhishGuard
You can run multiple Workers in a single dev command by passing multiple config files to
wrangler dev:Terminal window wrangler dev --config ./web/wrangler.jsonc --config ./api/wrangler.jsoncPreviously, if you ran the command above and then also ran wrangler dev for a different Worker, the Workers running in separate wrangler dev sessions could not communicate with each other. This prevented you from being able to use Service Bindings ↗ and Tail Workers ↗ in local development, when running separate wrangler dev sessions.
Now, the following works as expected:
Terminal window # Terminal 1: Run your application that includes both Web and API workerswrangler dev --config ./web/wrangler.jsonc --config ./api/wrangler.jsonc# Terminal 2: Run your auth worker separatelywrangler dev --config ./auth/wrangler.jsoncThese Workers can now communicate with each other across separate dev commands, regardless of your development setup.
./api/src/index.ts export default {async fetch(request, env) {// This service binding call now works across dev commandsconst authorized = await env.AUTH.isAuthorized(request);if (!authorized) {return new Response('Unauthorized', { status: 401 });}return new Response('Hello from API Worker!', { status: 200 });},};Check out the Developing with multiple Workers guide to learn more about the different approaches and when to use each one.
Browser-based RDP with Cloudflare Access is now generally available for all Cloudflare customers. It enables secure, remote Windows server access without VPNs or RDP clients.
Since we announced our open beta, we've made a few improvements:
- Support for targets with IPv6.
- Support for Magic WAN and WARP Connector as on-ramps.
- More robust error messaging on the login page to help you if you encounter an issue.
- Worldwide keyboard support. Whether your day-to-day is in Portuguese, Chinese, or something in between, your browser-based RDP experience will look and feel exactly like you are using a desktop RDP client.
- Cleaned up some other miscellaneous issues, including but not limited to enhanced support for Entra ID accounts and support for usernames with spaces, quotes, and special characters.
As a refresher, here are some benefits browser-based RDP provides:
- 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.
To get started, refer to Connect to RDP in a browser.
This week emphasizes two critical vendor-specific vulnerabilities: a full elevation-of-privilege in Microsoft Azure Networking (CVE-2025-54914) and a server-side template injection (SSTI) leading to remote code execution (RCE) in Skyvern (CVE-2025-49619). These are complemented by enhancements in generic detections (SQLi, SSRF) to improve baseline coverage.
Key Findings
-
Azure (CVE-2025-54914): Vulnerability in Azure Networking allowing elevation of privileges.
-
Skyvern (CVE-2025-49619): Skyvern ≤ 0.1.85 has a server-side template injection (SSTI) vulnerability in its Prompt field (workflow blocks) via Jinja2. Authenticated users with low privileges can get remote code execution (blind).
-
Generic SQLi / SSRF improvements: Expanded rule coverage to detect obfuscated SQL injection patterns and SSRF across host, local, and cloud contexts.
Impact
These vulnerabilities allow attackers to escalate privileges or execute code under conditions where previously they could not:
-
Azure CVE-2025-54914 enables an attacker from the network with no credentials to gain high-level access within Azure Networking; could lead to full compromise of networking components.
-
Skyvern CVE-2025-49619 allows authenticated users with minimal privilege to exploit SSTI for remote code execution, undermining isolation of workflow components.
-
The improvements for SQLi and SSRF reduce risk from common injection and request-based attacks.
Ruleset Rule ID Legacy Rule ID Description Previous Action New Action Comments Cloudflare Managed Ruleset 100146 SSRF - Host - 2 Log Disabled This is a New Detection Cloudflare Managed Ruleset 100146B SSRF - Local - 2 Log Disabled This is a New Detection Cloudflare Managed Ruleset 100146C SSRF - Cloud - 2 Log Disabled This is a New Detection Cloudflare Managed Ruleset 100714 Azure - Auth Bypass - CVE:CVE-2025-54914 Log Block This is a New Detection Cloudflare Managed Ruleset 100758 Skyvern - Remote Code Execution - CVE:CVE-2025-49619 Log Block This is a New Detection Cloudflare Managed Ruleset 100773 Next.js - SSRF Log Block This is a New Detection Cloudflare Managed Ruleset 100774 Adobe Commerce - Remote Code Execution - CVE:CVE-2025-54236 Log Block This is a New Detection Cloudflare Managed Ruleset 100800_BETA SQLi - Obfuscated Boolean - Beta Log Block This rule has been merged into the original rule (ID: -
AutoRAG now includes a Metrics tab that shows how your data is indexed and searched. Get a clear view of the health of your indexing pipeline, compare usage between
ai-searchandsearch, and see which files are retrieved most often.
You can find these metrics within each AutoRAG instance:
- Indexing: Track how files are ingested and see status changes over time.
- Search breakdown: Compare usage between
ai-searchandsearchendpoints. - Top file retrievals: Identify which files are most frequently retrieved in a given period.
Try it today in AutoRAG.
Rate Limiting within Cloudflare Workers is now Generally Available (GA).
The
ratelimitbinding is now stable and recommended for all production workloads. Existing deployments using the unsafe binding will continue to function to allow for a smooth transition.For more details, refer to Workers Rate Limiting documentation.
In workers-rs ↗, Rust panics were previously non-recoverable. A panic would put the Worker into an invalid state, and further function calls could result in memory overflows or exceptions.
Now, when a panic occurs, in-flight requests will throw 500 errors, but the Worker will automatically and instantly recover for future requests.
This ensures more reliable deployments. Automatic panic recovery is enabled for all new workers-rs deployments as of version 0.6.5, with no configuration required.
Rust Workers are built with Wasm Bindgen, which treats panics as non-recoverable. After a panic, the entire Wasm application is considered to be in an invalid state.
We now attach a default panic handler in Rust:
std::panic::set_hook(Box::new(move |panic_info| {hook_impl(panic_info);}));Which is registered by default in the JS initialization:
JavaScript import { setPanicHook } from "./index.js";setPanicHook(function (err) {console.error("Panic handler!", err);});When a panic occurs, we reset the Wasm state to revert the Wasm application to how it was when the application started.
We worked upstream on the Wasm Bindgen project to implement a new
--experimental-reset-state-functioncompilation option ↗ which outputs a new__wbg_reset_statefunction.This function clears all internal state related to the Wasm VM, and updates all function bindings in place to reference the new WebAssembly instance.
One other necessary change here was associating Wasm-created JS objects with an instance identity. If a JS object created by an earlier instance is then passed into a new instance later on, a new "stale object" error is specially thrown when using this feature.
Building on this new Wasm Bindgen feature, layered with our new default panic handler, we also added a proxy wrapper to ensure all top-level exported class instantiations (such as for Rust Durable Objects) are tracked and fully reinitialized when resetting the Wasm instance. This was necessary because the workerd runtime will instantiate exported classes, which would then be associated with the Wasm instance.
This approach now provides full panic recovery for Rust Workers on subsequent requests.
Of course, we never want panics, but when they do happen they are isolated and can be investigated further from the error logs - avoiding broader service disruption.
In the future, full support for recoverable panics could be implemented without needing reinitialization at all, utilizing the WebAssembly Exception Handling ↗ proposal, part of the newly announced WebAssembly 3.0 ↗ specification. This would allow unwinding panics as normal JS errors, and concurrent requests would no longer fail.
We're making significant improvements to the reliability of Rust Workers ↗. Join us in
#rust-on-workerson the Cloudflare Developers Discord ↗ to stay updated.
You can now route private traffic to Cloudflare Tunnel based on a hostname or domain, moving beyond the limitations of IP-based routing. This new capability is free for all Cloudflare One customers.
Previously, Tunnel routes could only be defined by IP address or CIDR range. This created a challenge for modern applications with dynamic or ephemeral IP addresses, often forcing administrators to maintain complex and brittle IP lists.
What’s new:
- Hostname & Domain Routing: Create routes for individual hostnames (e.g.,
payroll.acme.local) or entire domains (e.g.,*.acme.local) and direct their traffic to a specific Tunnel. - Simplified Zero Trust Policies: Build resilient policies in Cloudflare Access and Gateway using stable hostnames, making it dramatically easier to apply per-resource authorization for your private applications.
- Precise Egress Control: Route traffic for public hostnames (e.g.,
bank.example.com) through a specific Tunnel to enforce a dedicated source IP, solving the IP allowlist problem for third-party services. - No More IP Lists: This feature makes the workaround of maintaining dynamic IP Lists for Tunnel connections obsolete.
Get started in the Tunnels section of the Zero Trust dashboard with your first private hostname or public hostname route.
Learn more in our blog post ↗.
- Hostname & Domain Routing: Create routes for individual hostnames (e.g.,
We recently increased the available disk space from 8 GB to 20 GB for all plans. Building on that improvement, we’re now doubling the CPU power available for paid plans — from 2 vCPU to 4 vCPU.
These changes continue our focus on making Workers Builds faster and more reliable.
Metric Free Plan Paid Plans CPU 2 vCPU 4 vCPU - Fast build times: Even single-threaded workloads benefit from having more vCPUs
- 2x faster multi-threaded builds: Tools like esbuild ↗ and webpack ↗ can now utilize additional cores, delivering near-linear performance scaling
All other build limits — including memory, build minutes, and timeout remain unchanged.
To prevent the accidental exposure of applications, we've updated how Worker preview URLs (
<PREVIEW>-<WORKER_NAME>.<SUBDOMAIN>.workers.dev) are handled. We made this change to ensure preview URLs are only active when intentionally configured, improving the default security posture of your Workers.We performed a one-time update to disable preview URLs for existing Workers where the workers.dev subdomain was also disabled.
Because preview URLs were historically enabled by default, users who had intentionally disabled their workers.dev route may not have realized their Worker was still accessible at a separate preview URL. This update was performed to ensure that using a preview URL is always an intentional, opt-in choice.
If your Worker was affected, its preview URL (
<PREVIEW>-<WORKER_NAME>.<SUBDOMAIN>.workers.dev) will now direct to an informational page explaining this change.How to Re-enable Your Preview URL
If your preview URL was disabled, you can re-enable it via the Cloudflare dashboard by navigating to your Worker's Settings page and toggling on the Preview URL.
Alternatively, you can use Wrangler by adding the
preview_urls = truesetting to your Wrangler file and redeploying the Worker.{"preview_urls": true}preview_urls = trueNote: You can set
preview_urls = truewith any Wrangler version that supports the preview URL flag (v3.91.0+). However, we recommend updating to v4.34.0 or newer, as this version defaultspreview_urlsto false, ensuring preview URLs are always enabled by explicit choice.
Zero Trust Dashboard has a brand new, AI-powered search functionality. You can search your account by resources (applications, policies, device profiles, settings, etc.), pages, products, and more.
Ask Cloudy — You can also ask Cloudy, our AI agent, questions about Cloudflare Zero Trust. Cloudy is trained on our developer documentation and implementation guides, so it can tell you how to configure functionality, best practices, and can make recommendations.
Cloudy can then stay open with you as you move between pages to build configuration or answer more questions.
Find Recents — Recent searches and Cloudy questions also have a new tab under Zero Trust Overview.