Changelog

Cloudflare Snippets are now generally available at no extra cost across all paid plans — giving you a fast, flexible way to programmatically control HTTP traffic using lightweight JavaScript.

You can now use Snippets to modify HTTP requests and responses with confidence, reliability, and scale. Snippets are production-ready and deeply integrated with Cloudflare Rules, making them ideal for everything from quick dynamic header rewrites to advanced routing logic.

What's new:

• Snippets are now GA – Available at no extra cost on all Pro, Business, and Enterprise plans.

• Ready for production – Snippets deliver a production-grade experience built for scale.

• Part of the Cloudflare Rules platform – Snippets inherit request modifications from other Cloudflare products and support sequential execution, allowing you to run multiple Snippets on the same request and apply custom modifications step by step.

• Trace integration – Use Cloudflare Trace to see which Snippets were triggered on a request — helping you understand traffic flow and debug more effectively.

  

Learn more in the launch blog post ↗.

Cloudflare Secrets Store is available today in Beta. You can now store, manage, and deploy account level secrets from a secure, centralized platform to your Workers.

To spin up your Cloudflare Secrets Store, simply click the new Secrets Store tab in the dashboard ↗ or use this Wrangler command:

wrangler secrets-store store create <name> --remote

The following are supported in the Secrets Store beta:

• Secrets Store UI & API: create your store & create, duplicate, update, scope, and delete a secret
• Workers UI: bind a new or existing account level secret to a Worker and deploy in code
• Wrangler: create your store & create, duplicate, update, scope, and delete a secret
• Account Management UI & API: assign Secrets Store permissions roles & view audit logs for actions taken in Secrets Store core platform

For instructions on how to get started, visit our developer documentation.

Update: Mon Mar 24th, 11PM UTC: Next.js has made further changes to address a smaller vulnerability introduced in the patches made to its middleware handling. Users should upgrade to Next.js versions 15.2.4, 14.2.26, 13.5.10 or 12.3.6. If you are unable to immediately upgrade or are running an older version of Next.js, you can enable the WAF rule described in this changelog as a mitigation.

Update: Mon Mar 24th, 8PM UTC: Next.js has now backported the patch for this vulnerability ↗ to cover Next.js v12 and v13. Users on those versions will need to patch to 13.5.9 and 12.3.5 (respectively) to mitigate the vulnerability.

Update: Sat Mar 22nd, 4PM UTC: We have changed this WAF rule to opt-in only, as sites that use auth middleware with third-party auth vendors were observing failing requests.

We strongly recommend updating your version of Next.js (if eligible) to the patched versions, as your app will otherwise be vulnerable to an authentication bypass attack regardless of auth provider.

This rule is opt-in only for sites on the Pro plan or above in the WAF managed ruleset.

To enable the rule:

1. Head to Security > WAF > Managed rules in the Cloudflare dashboard for the zone (website) you want to protect.
2. Click the three dots next to Cloudflare Managed Ruleset and choose Edit
3. Scroll down and choose Browse Rules
4. Search for CVE-2025-29927 (ruleId: 34583778093748cc83ff7b38f472013e)
5. Change the Status to Enabled and the Action to Block. You can optionally set the rule to Log, to validate potential impact before enabling it. Log will not block requests.
6. Click Next
7. Scroll down and choose Save

This will enable the WAF rule and block requests with the x-middleware-subrequest header regardless of Next.js version.

For users on the Free plan, or who want to define a more specific rule, you can create a Custom WAF rule to block requests with the x-middleware-subrequest header regardless of Next.js version.

To create a custom rule:

1. Head to Security > WAF > Custom rules in the Cloudflare dashboard for the zone (website) you want to protect.
2. Give the rule a name - e.g. next-js-CVE-2025-29927
3. Set the matching parameters for the rule match any request where the x-middleware-subrequest header exists per the rule expression below.

(len(http.request.headers["x-middleware-subrequest"]) > 0)

4. Set the action to 'block'. If you want to observe the impact before blocking requests, set the action to 'log' (and edit the rule later).
5. Deploy the rule.

We've made a WAF (Web Application Firewall) rule available to all sites on Cloudflare to protect against the Next.js authentication bypass vulnerability ↗ (CVE-2025-29927) published on March 21st, 2025.

Note: This rule is not enabled by default as it blocked requests across sites for specific authentication middleware.

• This managed rule protects sites using Next.js on Workers and Pages, as well as sites using Cloudflare to protect Next.js applications hosted elsewhere.
• This rule has been made available (but not enabled by default) to all sites as part of our WAF Managed Ruleset and blocks requests that attempt to bypass authentication in Next.js applications.
• The vulnerability affects almost all Next.js versions, and has been fully patched in Next.js 14.2.26 and 15.2.4. Earlier, interim releases did not fully patch this vulnerability.
• Users on older versions of Next.js (11.1.4 to 13.5.6) did not originally have a patch available, but this the patch for this vulnerability and a subsequent additional patch have been backported to Next.js versions 12.3.6 and 13.5.10 as of Monday, March 24th. Users on Next.js v11 will need to deploy the stated workaround or enable the WAF rule.

The managed WAF rule mitigates this by blocking external user requests with the x-middleware-subrequest header regardless of Next.js version, but we recommend users using Next.js 14 and 15 upgrade to the patched versions of Next.js as an additional mitigation.

Now, API Shield automatically labels your API inventory with API-specific risks so that you can track and manage risks to your APIs.

View these risks in Endpoint Management by label:

...or in Security Center Insights:

API Shield will scan for risks on your API inventory daily. Here are the new risks we're scanning for and automatically labelling:

• cf-risk-sensitive: applied if the customer is subscribed to the sensitive data detection ruleset and the WAF detects sensitive data returned on an endpoint in the last seven days.
• cf-risk-missing-auth: applied if the customer has configured a session ID and no successful requests to the endpoint contain the session ID.
• cf-risk-mixed-auth: applied if the customer has configured a session ID and some successful requests to the endpoint contain the session ID while some lack the session ID.
• cf-risk-missing-schema: added when a learned schema is available for an endpoint that has no active schema.
• cf-risk-error-anomaly: added when an endpoint experiences a recent increase in response errors over the last 24 hours.
• cf-risk-latency-anomaly: added when an endpoint experiences a recent increase in response latency over the last 24 hours.
• cf-risk-size-anomaly: added when an endpoint experiences a spike in response body size over the last 24 hours.

In addition, API Shield has two new 'beta' scans for Broken Object Level Authorization (BOLA) attacks. If you're in the beta, you will see the following two labels when API Shield suspects an endpoint is suffering from a BOLA vulnerability:

• cf-risk-bola-enumeration: added when an endpoint experiences successful responses with drastic differences in the number of unique elements requested by different user sessions.
• cf-risk-bola-pollution: added when an endpoint experiences successful responses where parameters are found in multiple places in the request.

We are currently accepting more customers into our beta. Contact your account team if you are interested in BOLA attack detection for your API.

Refer to the blog post ↗ for more information about Cloudflare's expanded posture management capabilities.

Added new records to the leaked credentials database. The record sources are: Have I Been Pwned (HIBP) database, RockYou 2024 dataset, and another third-party database.

Cloudflare has supported both RSA and ECDSA certificates across our platform for a number of years. Both certificates offer the same security, but ECDSA is more performant due to a smaller key size. However, RSA is more widely adopted and ensures compatibility with legacy clients. Instead of choosing between them, you may want both – that way, ECDSA is used when clients support it, but RSA is available if not.

Now, you can upload both an RSA and ECDSA certificate on a custom hostname via the API.

curl -X POST https://api.cloudflare.com/client/v4/zones/$ZONE_ID/custom_hostnames \
    -H 'Content-Type: application/json' \
    -H "X-Auth-Email: $CLOUDFLARE_EMAIL" \
    -H "X-Auth-Key: $CLOUDFLARE_API_KEY" \
    -d '{
    "hostname": "hostname",
    "ssl": {
        "custom_cert_bundle": [
            {
                "custom_certificate": "RSA Cert",
                "custom_key": "RSA Key"
            },
            {
                "custom_certificate": "ECDSA Cert",
                "custom_key": "ECDSA Key"
            }
        ],
        "bundle_method": "force",
        "wildcard": false,
        "settings": {
            "min_tls_version": "1.0"
        }
    }
}’

You can also:

• Upload an RSA or ECDSA certificate to a custom hostname with an existing ECDSA or RSA certificate, respectively.

• Replace the RSA or ECDSA certificate with a certificate of its same type.

• Delete the RSA or ECDSA certificate (if the custom hostname has both an RSA and ECDSA uploaded).

This feature is available for Business and Enterprise customers who have purchased custom certificates.

We have upgraded and streamlined Cloudflare Rules limits across all plans, simplifying rule management and improving scalability for everyone.

New limits by product:

• Bulk Redirects
  • Free: 20 → 10,000 URL redirects across lists
  • Pro: 500 → 25,000 URL redirects across lists
  • Business: 500 → 50,000 URL redirects across lists
  • Enterprise: 10,000 → 1,000,000 URL redirects across lists
• Cloud Connector
  • Free: 5 → 10 connectors
  • Enterprise: 125 → 300 connectors
• Custom Errors
  • Pro: 5 → 25 error assets and rules
  • Business: 20 → 50 error assets and rules
  • Enterprise: 50 → 300 error assets and rules
• Snippets
  • Pro: 10 → 25 code snippets and rules
  • Business: 25 → 50 code snippets and rules
  • Enterprise: 50 → 300 code snippets and rules
• Cache Rules, Configuration Rules, Compression Rules, Origin Rules, Single Redirects, and Transform Rules
  • Enterprise: 125 → 300 rules

We're introducing Custom Errors (beta), which builds on our existing Custom Error Responses feature with new asset storage capabilities.

This update allows you to store externally hosted error pages on Cloudflare and reference them in custom error rules, eliminating the need to supply inline content.

This brings the following new capabilities:

• Custom error assets – Fetch and store external error pages at the edge for use in error responses.
• Account-Level custom errors – Define error handling rules and assets at the account level for consistency across multiple zones. Zone-level rules take precedence over account-level ones, and assets are not shared between levels.

You can use Cloudflare API to upload your existing assets for use with Custom Errors:

curl "https://api.cloudflare.com/client/v4/zones/{zone_id}/custom_pages/assets" \
--header "Authorization: Bearer <API_TOKEN>" \
--header 'Content-Type: application/json' \
--data '{
  "name": "maintenance",
  "description": "Maintenance template page",
  "url": "https://example.com/"
}'

You can then reference the stored asset in a Custom Error rule:

curl --request PUT \
"https://api.cloudflare.com/client/v4/zones/{zone_id}/rulesets/phases/http_custom_errors/entrypoint" \
--header "Authorization: Bearer <API_TOKEN>" \
--header 'Content-Type: application/json' \
--data '{
  "rules": [
		{
			"action": "serve_error",
			"action_parameters": {
				"asset_name": "maintenance",
				"content_type": "text/html",
				"status_code": 503
			},
			"enabled": true,
			"expression": "http.request.uri.path contains \"error\""
		}
	]
}'

Added new records to the leaked credentials database from a third-party database.

The new Snippets code editor lets you edit Snippet code and rule in one place, making it easier to test and deploy changes without switching between pages.

What’s new:

• Single-page editing for code and rule – No need to jump between screens.
• Auto-complete & syntax highlighting – Get suggestions and avoid mistakes.
• Code formatting & refactoring – Write cleaner, more readable code.

Try it now in Rules > Snippets ↗.

Rules Overview gives you a single page to manage all your Cloudflare Rules.

What you can do:

• See all your rules in one place – No more clicking around.
• Find rules faster – Search by name.
• Understand execution order – See how rules run in sequence.
• Debug easily – Use Trace without switching tabs.

Check it out in Rules > Overview ↗.