Skip to content
Cloudflare Docs
Docs DirectoryAPIsSDKs

Changelog

New updates and improvements at Cloudflare.

Subscribe to RSS View RSS feeds
All products
hero image

  1. Cloudflare One Agent for iOS (version 1.11)

    Cloudflare One Client

    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.

  1. Mail authentication requirements for Email Routing

    Email Routing

    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.

  1. Graceful withdrawal of BYOIP prefixes

    Magic Transit

    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.

  1. Remote bindings (beta) now works with Next.js — connect to remote resources (D1, KV, R2, etc.) during local development

    Workers

    We recently announced ↗ our public beta for remote bindings, which allow you to connect to deployed resources running on your Cloudflare account (like R2 buckets or D1 databases) while running a local development session.

    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:

    initOpenNextCloudflareForDev();
    initOpenNextCloudflareForDev({
     experimental: { remoteBindings: true }
    });

    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:

    {
      "r2_buckets": [
        {
          "bucket_name": "testing-bucket",
          "binding": "MY_BUCKET",
          "experimental_remote": true,
        },
      ],
    }

    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.

    Want to learn more? Get started with remote bindings and OpenNext ↗.

    Have feedback? Join the discussion in our beta announcement ↗ to share feedback or report any issues.

  1. Run and connect Workers in separate dev commands with the Cloudflare Vite plugin

    Workers

    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 window
    # Terminal 1
    vite dev
    

    # Terminal 2
    wrangler dev

    This is useful when different teams maintain different Workers, or when each Worker has its own build setup or tooling.

    Check out the Developing with multiple Workers guide to learn more about the different approaches and when to use each one.

  1. Run AI-generated code on-demand with Code Sandboxes (new)

    Agents Workers Workflows

    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.

    TypeScript
    import { getSandbox } from "@cloudflare/sandbox";
    export { Sandbox } from "@cloudflare/sandbox";
    

    export default {
      async fetch(request: Request, env: Env) {
        const sandbox = getSandbox(env.Sandbox, "my-sandbox");
        return sandbox.exec("ls", ["-la"]);
      },
    };

    Methods

    • 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.

  1. @cloudflare/actors library - SDK for Durable Objects in beta

    Durable Objects Workers

    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:

    • 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.

    JavaScript
    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".

    JavaScript
    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 ↗.

    JavaScript
    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 ↗.

  1. Data Security Analytics in the Zero Trust dashboard

    Data Loss Prevention CASB Cloudflare One

    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.
    Data Security Analytics

    To access the new dashboard, log in to Cloudflare One ↗ and go to Insights on the sidebar.

  1. Cloudflare User Groups & SCIM User Groups are now in GA

    Cloudflare Fundamentals

    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:

  1. CNI maintenance alerts

    Network Interconnect

    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.

  1. Increased blob size limits in Workers Analytics Engine

    Workers

    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.

    JavaScript
    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"],
        });
      },
    };

  1. View custom metadata in responses and guide AI-search with context in AutoRAG

    AI Search

    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

    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.

  1. Filter your AutoRAG search by file name

    AI Search

    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:

    JavaScript
    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.

  1. Account-level DNS analytics now available via GraphQL Analytics API

    DNS

    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 analytics
    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
          }
        }
      }
    }
    Run in GraphQL API Explorer

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

  1. Automate Worker deployments with a simplified SDK and more reliable Terraform provider

    D1 Workers Workers for Platforms

    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:

    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:

    Terminal window
    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' <<EOF
    export default {
      async fetch(request, env, ctx) {
        return new Response(env.MESSAGE, { status: 200 });
      }
    };
    EOF

    After: SDK interface

    With 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 ↗

    JavaScript
    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 ↗

    Terraform provider improvements

    We've also made several fixes and enhancements to the Cloudflare Terraform provider ↗:

    • Fixed the 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.
    • Fixed the 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.
    • The 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.
    • Using 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.

    API improvements

    We've also properly documented the Workers Script And Version Settings in our public OpenAPI spec and SDKs.

  1. Gateway will now evaluate Network policies before HTTP policies from July 14th, 2025

    Gateway

    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:

    • Add a client notification to your Network policy, or
    • Use only the HTTP policy for that domain.

    Why we’re making this change

    This update is based on user feedback and aims to:

    • Create a more intuitive model by evaluating network-level policies before application-level policies.
    • Minimize 526 connection errors by verifying the network path to an origin before attempting to establish a decrypted TLS connection.

    To learn more, visit the Gateway order of enforcement documentation.

  1. Log Explorer is GA

    Log Explorer

    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.

  1. Remote bindings public beta - Connect to remote resources (D1, KV, R2, etc.) during local development

    Workers

    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-03-26",
    

      "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:

    Have feedback? Join the discussion in our beta announcement ↗ to share feedback or report any issues.

  1. WARP client for Windows (version 2025.5.828.1)

    Cloudflare One Client

    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

    • Improvement to better handle multi-user fast user switching.
    • Fix for an issue causing WARP connectivity to fail without full system reboot.

    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:

      • WARP is in Secure Web Gateway without DNS filtering (tunnel-only) mode.
      • A custom DNS server address is configured on the primary network adapter.
      • The custom DNS server address on the primary network adapter is changed while WARP is connected. To work around this issue, reconnect the WARP client by toggling off and back on.

  1. WARP client for macOS (version 2025.5.828.1)

    Cloudflare One Client

    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

    • Improvement for WARP connectivity issues on macOS due to the operating system not accepting DNS server configurations.

    Known issues

    • macOS Sequoia: Due to changes Apple introduced in macOS 15.0.x, the WARP client may not behave as expected. Cloudflare recommends the use of macOS 15.4 or later.

  1. Terraform v5.6.0 now available

    Cloudflare Fundamentals Terraform

    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
      • cloudflare_zero_trust_device_settings
    • Other bug fixes

    For a more detailed look at all of the changes, see the changelog ↗ in GitHub.

    Issues Closed

    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.

    Upgrading

    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 more info

  1. Control which routes invoke your Worker script for Single Page Applications

    Workers

    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-03-26",
      "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

    To use advanced routing control with run_worker_first, you'll need:

  1. SSRF vulnerability in @opennextjs/cloudflare proactively mitigated for all Cloudflare customers

    Workers

    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:

    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.

  1. Internal DNS (beta) now manageable in the Cloudflare dashboard

    DNS

    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

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

  1. WAF Release - 2025-06-16

    WAF

    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.
    • WooCommerce WordPress Plugin (CVE-2025-47577): Dangerous file upload vulnerability permits unauthenticated users to upload executable payloads, leading to full WordPress site takeover.
    • Cross-Site Scripting (XSS) Detection Improvements: Enhanced detection patterns.

    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.

    RulesetRule IDLegacy Rule IDDescriptionPrevious ActionNew ActionComments
    Cloudflare Managed Ruleset 100783Cisco IOS XE - Remote Code Execution - CVE:CVE-2025-20188LogBlockThis is a New Detection
    Cloudflare Managed Ruleset 100784Axios - SSRF - CVE:CVE-2024-39338LogBlockThis is a New Detection
    Cloudflare Managed Ruleset 100785

    vBulletin - Remote Code Execution - CVE:CVE-2025-48827, CVE:CVE-2025-48828

    		LogBlockThis is a New Detection
    Cloudflare Managed Ruleset 100786Invision Community - Remote Code Execution - CVE:CVE-2025-47916LogBlockThis is a New Detection
    Cloudflare Managed Ruleset 100791CrushFTP - SSRF - CVE:CVE-2025-32102, CVE:CVE-2025-32103LogBlockThis is a New Detection
    Cloudflare Managed Ruleset 100792Roundcube - Remote Code Execution - CVE:CVE-2025-49113LogBlockThis is a New Detection
    Cloudflare Managed Ruleset 100793XSS - OntoggleLogDisabledThis is a New Detection
    Cloudflare Managed Ruleset 100794

    WordPress WooCommerce Plugin - Dangerous File Upload - CVE:CVE-2025-47577

    		LogBlockThis is a New Detection
Search all changelog entries