Core Platform Updates & Release Notes

We're announcing the GA of Optional OAuth Scopes.

OAuth client developers can now classify configured scopes as required or optional in the Cloudflare dashboard. By default, all configured scopes remain required.

What's New

• Optional Scopes: OAuth clients can now mark configured scopes as optional, allowing applications to request them without requiring users to approve them.
• Scope Selection: On the consent screen, users must grant required scopes but can decline optional scopes. This helps customers apply least-privilege access to applications, CLIs, and workloads. Optional scopes are selected by default.
• Templates: The consent screen now includes Read Only and Full Access templates to make scope selection faster and easier.
• Search: Users can now search scopes in the consent screen.

Learn how to select client scopes and edit optional permissions.

Original source

You can now configure origin application settings directly in the Cloudflare dashboard when adding or editing a published application route for a Cloudflare Tunnel. These settings control how cloudflared connects to your origin server and were previously only available in the Cloudflare One dashboard or via local configuration files.

When editing a published application, expand Additional application settings to configure parameters organized into three categories:

HTTP

Set a custom HTTP Host header or disable chunked encoding.

TLS

Configure origin server name, CA pool, TLS timeout, disable TLS verification, match SNI to host, or enable HTTP/2 to origin.

Connection

Tune connect timeout, keep-alive timeout, keep-alive connections, TCP keep-alive interval, proxy type, or disable Happy Eyeballs.

Go to Tunnels ↗

For the full list of origin parameters, refer to Origin parameters.

Original source

Cloudflare has fixed an issue affecting WebSocket data transfer reporting. HTTP Traffic Analytics and HTTP request logs now correctly count data transferred throughout a WebSocket connection, restoring the correct behavior. During the affected period, reporting captured only the initial 101 Switching Protocols handshake for some WebSocket connections, which could underreport their data transfer.

Customers with WebSocket traffic will see the correct Data Transfer in the dashboard and EdgeResponseBytes in analytics and HTTP request logs. The change reflects restored accounting of existing WebSocket traffic, not an increase in traffic caused by this change. WebSocket connection behavior is unaffected.

The separate WebSocket Analytics Logpush dataset continues to provide per-connection directional byte counts, timestamps, and close details.

For more information about HTTP Traffic Analytics, refer to Zone Analytics.

Original source

Cloud Connector now supports public Oracle Cloud Infrastructure (OCI) Object Storage buckets. You can route matching requests to OCI without managing a separate origin-routing configuration.

OCI support uses the Amazon S3 Compatibility API. Both path-style and virtual-hosted endpoint formats are supported, including traditional oraclecloud.com and dedicated customer-oci.com path-style endpoints.

Public buckets only

Cloud Connector does not sign requests or provide OCI credentials. Your bucket must allow anonymous object reads. Private buckets and pre-authenticated request URLs are not supported.

API example

Set provider to oci_storage and provide a supported OCI hostname. The following rule uses a virtual-hosted endpoint:

{
  "expression": "http.request.uri.path wildcard \"/assets/*\"",
  "provider": "oci_storage",
  "description": "Route assets to OCI Object Storage",
  "enabled": true,
  "parameters": {
    "host": "<BUCKET_NAME>.vhcompat.objectstorage.<REGION>.oci.customer-oci.com"
  }
}

For endpoint formats and bucket requirements, refer to Supported cloud providers in Cloud Connector.

Original source

The Cloudflare Status page at www.cloudflarestatus.com ↗ has been rebuilt. It is available at the same address, and every previously documented Status API ↗ endpoint remains supported, so existing bookmarks, integrations, and monitoring continue to work.

Notifications that fire even when Cloudflare is down

The status page now has its own notification system, delivered independently of Cloudflare infrastructure. You can subscribe by email, webhook, Slack, Discord, or Google Chat.

The Maintenance Notification and Incident Alerts in Cloudflare Notifications remain supported, and deliver to the destinations already configured on your account.

Markdown for AI agents

Every page on the status page returns Markdown when requested with an Accept: text/markdown header, so agents can read the current status without parsing HTML:

curl -H "Accept: text/markdown" https://www.cloudflarestatus.com/locations

Separate feeds for incidents and maintenance

Incidents and maintenance are published as separate feeds, each available in RSS and Atom, so you can subscribe to one without the other:

https://www.cloudflarestatus.com/api/v3/incidents.rss

https://www.cloudflarestatus.com/api/v3/incidents.atom

https://www.cloudflarestatus.com/api/v3/maintenance.rss

https://www.cloudflarestatus.com/api/v3/maintenance.atom

For more information, refer to Cloudflare Status.

Original source

Hostname routing ↗ is now generally available. Instead of managing static IP lists and routes, you can route traffic by hostname across multiple Cloudflare One connectors:

Cloudflare Tunnel: route a private hostname (for example, wiki.internal.local) to a private application behind your tunnel, or a public hostname (for example, bank.example.com) to egress through a specific tunnel and anchor traffic to a dedicated exit node.

Cloudflare Mesh: attract a private or public hostname's traffic to a Mesh node.

Alongside GA, the default IPv4 range used for initial resolved IPs (also called token IPs) is changing from a Carrier-Grade NAT (CGNAT) range to a public Cloudflare-owned range:

• IPv4: 172.64.128.0/20
• IPv6: 2606:4700:0cf1:4000::/64

This is the default range. You can configure a custom initial resolved IP range for IPv4 if it conflicts with your existing network.

Why this is changing: Starting with Chrome 142 ↗, Local Network Access (LNA) restrictions block background requests to CGNAT addresses (100.64.0.0/10), which included the previous initial resolved IP default (100.80.0.0/16). LNA is implemented at the Chromium engine level, so it affects all Chromium-based browsers (for example, Microsoft Edge, Brave, and Opera), not only Google Chrome. This could silently break hostname-based Gateway features for users of these browsers, and required Chrome Enterprise policy workarounds. The new default range is public Cloudflare address space, so it is not affected by this restriction.

What is affected: Initial resolved IPs are used by several features that associate a DNS query with the network connection that follows it:

• Private and public hostname routing for Cloudflare Tunnel
• Hostname routes for Cloudflare Mesh
• Access private applications on non-HTTPS ports
• Egress policy host selectors (Domain, Host, Application, and Content Categories)

You can check your account's current range, or configure a custom range, at any time from Networking > IP addresses > Address space > Custom IPs, or using the Initial Resolved IP Subnet API.

Go to Custom IPs ↗

For full instructions, refer to Configure initial resolved IPs. The IPv6 range (2606:4700:0cf1:4000::/64) is unchanged and is not affected by this restriction.

The default IPv4 range, and all Cloudflare One IPv6 ranges, are automatically routed through the Cloudflare One Client and do not require any Split Tunnel configuration. Refer to Automatically managed ranges for details.

If you were relying on a Chrome Enterprise policy workaround (such as LocalNetworkAccessRestrictionsTemporaryOptOut) while your account was still on the legacy CGNAT-based range, refer to Google Chrome restricts access to private hostnames for next steps.

Original source

Real-time Tunnel log streaming is now available in the Cloudflare dashboard under Networking > Tunnels. This brings the same live debugging capability previously only available in the Cloudflare One dashboard, including multi-connector aggregated streaming for high-availability deployments.

In the tunnel detail view, a new Live logs tab lets you:

• Stream logs from single or multiple connectors — In highly available deployments with multiple cloudflared replicas, logs from all connectors are merged into a single stream grouped by hostname, making it easy to identify which host machine produced each log entry.
• Filter by log level, event type, and HTTP method — Narrow the stream to only the events you care about (HTTP, TCP, UDP, or cloudflared internal), at any log level.

Go to Tunnels ↗

For more information, refer to Monitor tunnels and Tunnel log streams.

Original source

OAuth consent screens now display a shield icon with explanatory text beneath the consent screen title. Each shield icon indicates who owns the application and whether its domain ownership is verified.

• Green filled shield: Cloudflare owns and manages the application.
• Blue outlined shield: A third-party application with verified ownership of its domain.
• Amber filled shield: A third-party application without verified ownership of a domain.
• Domain verification only confirms that the application owner controls the displayed domain.
• For more information, refer to Authorizing an application.

Original source

Limitations

You can now create standalone Free accounts directly from the Cloudflare dashboard using the new Create Account button. This feature is currently available to all users.

When creating a Free account:

• You can create up to 5 Free accounts.
• Your user account must have at least 7 days of tenure to be eligible.
• The account is created immediately and ready to use.

To create a Free account, go to the Cloudflare dashboard ↗ and select Create Account from either the account switcher in the top left (where your account name appears) or from the Accounts page.

This feature can only be used to create a Cloudflare Free account. To create an Enterprise Account under your existing contract, please contact Cloudflare Support.

All users can create a Cloudflare Free account, however, Enterprises wish to restrict this action to only Super Administrators. We will deliver this improvement in a future release.

Next steps

After creating your Free account, you can:

• Add a payment method to enable additional Cloudflare products and services.
• Update billing information to manage payment methods, billing address, or tax IDs.
• Review how Cloudflare billing works to understand the billing lifecycle and charge types.
• Assign accounts to an Enterprise Organization to centrally manage multiple accounts from a single dashboard.

Original source

Audit Logs v2 now includes Resource History. For any audit log entry, you can see the sequence of previous changes to the same resource and view a side-by-side diff of what was modified.

Resource History uses the audit log entries you already have. There is no additional configuration, no backend recapture, and no changes to how audit logs are generated.

Dashboard

Go to Manage Account > Audit Logs.

Open any audit log entry.

Select the History tab to see the full history for that resource.

Select any earlier entry to see a side-by-side diff of the fields that changed between it and the current entry.

API

Use the History endpoint to retrieve the change history for any audit log entry:

GET https://api.cloudflare.com/client/v4/accounts/{account_id}/logs/audit/{id}/history

The endpoint is also available for organization-scoped audit logs at /organizations/{organization_id}/logs/audit/{id}/history.

For more information, refer to the Resource History documentation.

Original source

The Account Roles API is deprecated and is being replaced by the Permission Groups API. An end of life date has not yet been established.

What you need to do

Review the Permission Groups API documentation; the response schema differs from the legacy Roles response.

Highlights

Integrations migrating to the Permission Groups API must obtain Permission Group IDs from that API and use them in the Account Members API policies request shape. Integrations that persist legacy Role IDs will need to remap their assignments.

The legacy Role response includes a top-level description and a permissions object keyed by resource type with edit/read flags.

The PermissionGroup response replaces those with a meta object containing label and scopes. Individual permissions are not returned as part of the permission group.

The new API supports the API Token authorization scheme. The legacy Email + API Key authorization schema is provided for backwards compatibility.

For more information, refer to API deprecations.

Original source

We are turning on budget alerts by default for eligible Pay-as-you-go accounts. If your account does not already have a budget alert, Cloudflare will create one for you with a $10 account-level threshold. Your default alert will enable at the turn of your next billing cycle, so it will not fire based on usage you have already incurred.

We are rolling this out in cohorts over the coming weeks, so eligible accounts may see their default alert appear at different times.

The default alert behaves exactly like an alert you would create yourself. When your cumulative usage-based spend this cycle reaches the threshold, you receive an email notification. The alert is informational only. It does not cap your usage or impact your account in any way.

Usage is processed once per day for the prior day's activity, so budget alerts fire the day after the threshold is reached rather than in real time.

Budget alerts only consider spend on usage-based products. Recurring subscription fees, such as the Workers Paid plan fee or other monthly plan charges, are not included in the threshold calculation.

You can change the threshold, add additional alerts, or remove the default alert entirely from Manage Account > Billing > Billable Usage, or from your Notifications settings. If you already configured your own budget alert, nothing changes.

Enterprise contract accounts are not in scope.

For more information, refer to the Budget alerts documentation.

Original source

Distributor, MSSP, and Agency partners on Cloudflare Organizations can now add and manage Organization Members directly from the Cloudflare dashboard, without help from Cloudflare.

Previously, adding a member to a Distributor, MSSP, or Agency Organization was a manual, Cloudflare-assisted process that required a request to Cloudflare and enrollment in a closed beta, and the dashboard Add member flow was blocked for these Organizations.

Now, Organization admins can add members themselves from Organization > Members > Add member, with no beta enrollment required.

New members receive access to the Organization's accounts through the same implicit-access model already used for enterprise Organizations. The Accounts list and the account switcher classify Distributor, MSSP, and Agency Organizations consistently with enterprise Organizations, so their accounts are labeled and grouped correctly in the dashboard.

Agency partners also gain access to the Organizations dashboard, while retaining access to their existing Tenant management dashboard.

Distributor, MSSP, and Agency Organizations are currently in beta.

For more information, refer to Manage Organization members.

Original source

Bot management fields and ASN support in Cache Rules

Cache Rules now supports bot management fields and the ip.src.asnum field in expression filters. You can now build cache policies that differentiate between automated and human traffic, or segment caching behavior by autonomous system number (ASN).

This allows you to apply different caching strategies for verified bots, high-risk traffic, or specific network operators without affecting legitimate user requests. For example, you can set shorter cache TTLs for suspected bot traffic or bypass cache entirely for requests from specific ASNs.

New fields

The following fields are now available in Cache Rules expressions:

Field Type Description cf.bot_management.score Number Bot score from 1 to 99, where a lower value indicates a higher likelihood that the request originates from a bot. cf.bot_management.ja3_hash String JA3 fingerprint of the request, which helps identify the client making the connection. cf.bot_management.ja4 String JA4 fingerprint of the request, which provides a more detailed client identification than JA3. cf.bot_management.verified_bot Boolean Whether the request originates from a verified bot, such as a search engine crawler. cf.bot_management.static_resource Boolean Whether the request is for a static resource and therefore exempt from bot detection. cf.bot_management.js_detection.passed Boolean Whether the browser passed JavaScript detection when the feature is enabled. cf.bot_management.attack_score Number Classifies the request by attack score, from 1 (likely automated) to 99 (likely human). cf.bot_management.api_score Number Classifies the request by API score, from 1 (likely automated) to 99 (likely human). cf.bot_management.bot_tags["<TAG>"] Boolean Whether the bot traffic matches the specified tag, such as google or bing. cf.bot_management.corporate_proxy Boolean Whether the request originates from a known corporate proxy. ip.src.asnum Number The autonomous system number (ASN) of the incoming request's IP address.

Note

Bot management fields require a Bot Management subscription. ip.src.asnum is available on all plans.

Example

Cache Rules expressions support combining these fields with other criteria. The following example sets a shorter cache TTL for API requests that originate from a high-risk bot or an unexpected ASN:

(http.request.uri.path contains "/api/" and cf.bot_management.score lt 30)
or
(http.request.uri.path contains "/api/" and not ip.src.asnum in {12345 67890})

To learn more, refer to the Cache Rules documentation and the Fields reference.

Original source

Markdown for Agents now preserves security- and cache-relevant response headers from your origin when converting HTML to Markdown

Markdown for Agents preserves security headers such as Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Frame-Options, Set-Cookie, and CORS headers (for example, Access-Control-Allow-Origin) on the converted response.

Caching headers (Cache-Control, Expires, Age) continue to pass through.

Your origin's Content Signals policy is now authoritative. If your origin sets a content-signal header, Markdown for Agents preserves it. When the origin does not send one, Cloudflare adds the default Content-Signal: ai-train=yes, search=yes, ai-input=yes.

This release also fixes relative link resolution for directory-style base URLs (those ending in a trailing slash). Previously, relative links such as ../page/ could resolve one path segment too high and return a 404. Links are now resolved correctly per RFC 3986.

Refer to our developer documentation for more details.

Original source