Changelog

Application Profiles add a positive-security layer to Cloudflare WAF. Instead of looking only for requests that resemble known attacks, Application Profiles learn what valid requests to your application look like and identify traffic that deviates from the expected structure.

The first available profile type, Schema Profiles, can learn path variables, query parameters, headers, cookies, JSON bodies, and form-encoded bodies. Profiles model field types and constraints such as numeric ranges, string lengths, and character classes. After a profile becomes available, an always-on detection classifies requests as conforming or non-conforming without blocking traffic.

Use Profile Analysis in Security Analytics to review conformance trends and sampled violation details before enforcing a profile. When you are ready to mitigate traffic, use a Custom Rule to scope enforcement by hostname, path, operation, or other security signals such as Attack Score.

Customers with API Security already have access to Schema Profiles through Schema Learning and Schema Validation. Cloudflare is also opening a closed beta to invited Enterprise customers without API Security. Contact your Cloudflare account team to express interest.

For more information, refer to Application Profiles.

Attack Signature Detection is now available in Early Access. It evaluates requests against Cloudflare attack signatures and records matches without applying a mitigation action, allowing you to investigate detected traffic before deciding how to respond.

In Security Analytics > Attack Analysis, you can review matching signature references, categories, confidence levels, and request outcomes. You can then use these fields in Security Rules and combine them with request properties such as hostname, path, and HTTP method to apply scoped mitigation.

Attack Signature Detection uses the same signature definitions as Cloudflare Managed Rules, but it does not inherit your Managed Rules actions, overrides, or deployment configuration. Managed Rules remain the recommended baseline protection during Early Access.

Contact your Cloudflare account team to request access. For more information, refer to Attack Signature Detection.

You can now manage Email Routing rules that route emails to Workers from your Wrangler configuration. Add literal addresses or a catch-all address to the top-level addresses field:

{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "name": "invoice-handler",
  "main": "src/index.ts",
  // Set this to today's date
  "compatibility_date": "2026-10-11",
  "addresses": [
    "invoice@yourdomain.com"
  ]
}

name = "invoice-handler"
main = "src/index.ts"
# Set this to today's date
compatibility_date = "2026-10-11"
addresses = ["invoice@yourdomain.com"]

When you run wrangler deploy, Wrangler creates rules for new addresses, updates existing rules managed by the Worker, and removes managed rules that are no longer in the configuration. Wrangler shows the planned changes and asks for confirmation before applying potentially destructive changes.

Email Routing rules created by Wrangler also appear in the dashboard but with an icon that identifies them.

Refer to Configure rules with Wrangler for more information.

Enterprise customers can now configure a zone's CDN Maximum Upload Size up to 5 GB directly from the Network page in the Cloudflare dashboard. This removes the need to contact your account team or Cloudflare Support when applications need to accept request bodies larger than 500 MB and no greater than 5 GB.

The default maximum upload size remains 500 MB. Upload limits above 5 GB still require additional configuration through your account team or Cloudflare Support.

Very large uploads may reach connection or read timeouts before reaching the configured size limit. Make sure clients and origins allow enough time to complete the transfer when increasing this setting.

Refer to Cache upload limits and Workers request body size limits for details.

R2 Data Access Logs are now generally available. Turn on logging for a bucket to record object read, write, list, multipart upload, and delete operations with response status codes below 400.

Data Access Logs cover requests made through the S3-compatible API, Cloudflare API and dashboard, Workers bindings, and public buckets through r2.dev or custom domains. Events are available in Workers Observability, where you can filter by bucket, operation, interface, actor, and other request fields.

Log delivery is asynchronous and best effort. Events may be delayed or omitted, so do not rely on Data Access Logs as a complete record of bucket activity.

Data Access Logs are available for non-jurisdictional buckets. For setup instructions, supported operations, and the event field reference, refer to R2 Data Access Logs.

You can now deploy Workers with larger dependencies, heavier frameworks, and more code without hitting size limits.

When you deploy a Worker, Wrangler bundles your code and compresses it before uploading. Previously, Cloudflare checked that compressed size and rejected deploys over 3 MB (Free) or 10 MB (Paid). That limit has been removed. Cloudflare now only checks the uncompressed size of your bundle, which is 64 MiB across all plans.

To check your Worker's bundle size before deploying:

wrangler deploy --outdir bundled/ --dry-run

Total Upload: 259.61 KiB / gzip: 47.23 KiB

The Total Upload value is your uncompressed bundle size. This is what counts against the 64 MiB limit. The gzip value is shown for reference but is no longer a limit.

For more information, refer to the Worker size limits documentation.

The Rulesets API now supports Origin Range Requests in Cache Rules. This setting lets Cloudflare fetch large files from your origin in cache-aligned byte ranges. Cloudflare may expand a client range and issue several single-range origin requests.

Set origin_range_requests.mode to on, off, or default for any traffic matched by a Cache Rule.

To override Cloudflare's default Origin Range Requests behavior, set the mode to off. The following rule turns off generated origin range requests for all traffic without changing cache eligibility:

{
  "expression": "true",
  "action": "set_cache_settings",
  "action_parameters": {
    "origin_range_requests": {
      "mode": "off"
    }
  }
}

Origin Range Requests do not make otherwise ineligible content cacheable. If your origin ignores Range and returns a complete 200 OK, Cloudflare can use the response but must download the complete file. Origins should honor Accept-Encoding: identity and return consistent, unencoded partial responses.

For configuration details and mode behavior, refer to Origin Range Requests in Cache Rules. For client responses and the complete origin contract, refer to Range request behavior.

You can now define custom applications for breakout and prioritized traffic on the Cloudflare One Appliance directly from the dashboard, without calling the API.

• In Traffic Steering > Breakout traffic or Prioritized traffic, select Assign application traffic > Add to create a custom application matched by Hostnames, IP subnets, and/or the new Source subnets field, alongside Cloudflare-managed applications.
• Edit or delete an existing custom application from the same panel, no API round-trip required.
• Source subnets lets you match traffic by its source IP range, complementing the existing source LAN interface breakout criteria.

This complements the existing API and Terraform workflow for managing applications.

For details, refer to Breakout traffic and Prioritized traffic.

You can now configure custom DHCP options directly from the dashboard when the Cloudflare One Appliance is acting as the DHCP server for a LAN.

• In LAN configuration, under DHCP server options, select Add DHCP option to choose from common options for PXE / iPXE boot, VoIP phone provisioning, and vendor-specific configuration, or select Add custom option to enter your own option code, type, and value.
• This complements the existing API and Terraform workflow for configuring DHCP options.

For details, refer to DHCP server options.

We've added more ways to manage and manipulate images with the Images binding. Here's what's new:

Render text into an image. Output a string of text into its own image or draw it over another image.

• Use the .text() method to rasterize text with the Images binding.
• Style content using the font, size, and color options.
• The draw array in cf.image now accepts a text key.

Manage hosted images without an API token.

• Metadata filtering: Pass filter.metadata to .list() to return images by custom metadata. Match a bounded range by setting two operators in one condition, for example, priority: { gte: 2, lte: 5 }.
• Server-side signing: Get a signed URL for a private image with .signedUrl().
• User uploads: Create a Direct Creator Upload link with .createDirectUpload() so that a client can upload an image to your storage.

Set headers in a single call.

• Pass a headers option to .response() to set headers without rebuilding the Response.
• Content-Type is always taken from the optimized image and can't be overridden by a specified header.
• Set Cache-Control with Workers Cache to cache your optimized image at the edge.

For more information, refer to Optimize with Workers, Draw overlays and watermarks, and Manage hosted images with Workers.

You can now create multiple Cloudflare Tunnel and Cloudflare Mesh routes from the Routes page in a single action, instead of submitting one route at a time.

When creating a route, you can now:

• Add multiple destinations at once — Enter a comma-separated list of CIDR ranges or hostnames to create several routes of the same type and connector together.
• Queue up multiple routes — Select Add another to stage additional routes, including different types or connectors, before creating them all in one action.
• Retry only what failed — If some routes in a batch fail (for example, an invalid CIDR), the routes that were created successfully are removed from the form automatically, so you only need to fix and resubmit the ones that failed.

The same Routes UI already supports bulk creation for Cloudflare WAN static routes, so you can add multiple WAN destinations or queue up several WAN routes before creating them together as well.

For setup steps, refer to Add routes.

Cursor self-hosted machines ↗︎ let you run Cursor Cloud Agents on Cloudflare. Each assigned session runs in its own isolated environment backed by Cloudflare Containers.

Cursor hosts the agent loop, inference, and planning. Cloudflare runs commands, file edits, repository operations, and other tools inside infrastructure that you control. The open-source Cursor Cloudflare Workers template ↗︎ deploys the Worker, Durable Object namespace, container application, R2 bucket binding, and cron trigger used by the integration.

To get started, refer to Run Cursor Cloud Agents on Cloudflare via self-hosted machines.

Python web frameworks following the Web Server Gateway Interface (WSGI) ↗︎ or Asynchronous Server Gateway Interface (ASGI) ↗︎ specification can now be used in Python Workers.

Based on the web framework you are using, you can use either wsgi or asgi from the workers module.

For WSGI frameworks like Django or Flask:

from workers import wsgi

from django.core.wsgi import get_wsgi_application

app = get_wsgi_application()
Default = wsgi.entrypoint(app)

The wsgi.entrypoint is equivalent to creating a WorkerEntrypoint class and using the wsgi.fetch method. If you want more control over the WorkerEntrypoint class, you can do so:

from workers import wsgi, WorkerEntrypoint

class Default(WorkerEntrypoint):
    async def fetch(self, request):
        return await wsgi.fetch(app, request, self.env)

For ASGI frameworks like FastAPI or Starlette:

from workers import asgi

from fastapi import FastAPI

app = FastAPI()
Default = asgi.entrypoint(app)

For more information about using individual web frameworks, refer to the packages documentation in Python Workers.

AI Gateway monthly usage invoices, issued at the beginning of each month for the previous month's usage, now show a single total cost for each model. These invoices no longer break out input and output token quantities and unit prices into separate line items. This change does not apply to invoices for AI Gateway credit purchases.

For example, an invoice that previously included these separate line items:

• anthropic claude-haiku-4-5-20251001 Input Tokens: 40,000 tokens at $0.000001 ($0.04)
• anthropic claude-haiku-4-5-20251001 Output Tokens: 24,000 tokens at $0.000005 ($0.12)

The updated invoice includes one line item: anthropic/claude-haiku-4.5: $0.16.

AI Gateway has also standardized model names across invoices and logs. Model variants that previously appeared with provider-specific version suffixes now use a consistent provider/model identifier.

For more information, refer to the Unified Billing documentation and AI Gateway logging documentation.

Beginning September 1, 2026, D1 queries on the Workers Free plan will fail when an account exceeds the daily row read or row write limits. Queries via the Workers Binding API and the REST API will return errors until the limit resets at midnight UTC. Stored data is not affected.

You will receive email alerts when the daily limit is reached. The following errors indicate that a limit has been exceeded:

Inspect database query activity before the enforcement date to identify queries that may exceed these limits. To reduce row reads, add indexes to tables and review queries that perform full table scans. If usage requires higher limits after optimization, upgrade to a Workers Paid plan.

For more information on D1 errors and how to handle them, refer to the D1 error list.

AI Security for Apps now supports an updated set of categories for detecting personally identifiable information (PII) in incoming prompts.

The values available in cf.llm.prompt.pii_categories have changed. Existing WAF custom rules remain valid, but rules that reference a removed or renamed category will no longer match that category. Review any rules that use this field and update their expressions to use the currently supported values.

For the complete category list and configuration guidance, refer to PII detection.

This release introduces a new threat detection to enhance protection against SQL injection (SQLi) attempts exploiting complex query syntax.

Key Findings

• SQLi Protection: Improved coverage for SQL injection patterns involving WHERE comparisons combined with WITH clauses.

The /crawl endpoint now respects the use directive of the Content Signals ↗︎ standard, letting site owners express the maximum level at which their content may be used.

You can declare your intended level with the new contentUse parameter. Allowed values, from least to most permissive, are reference and full, and the default is full. If a target site's robots.txt sets a use level that is more restrictive than your declared contentUse, the crawl request is rejected with a 400 error.

curl -X POST 'https://api.cloudflare.com/client/v4/accounts/{account_id}/browser-rendering/crawl' \
  -H 'Authorization: Bearer <apiToken>' \
  -H 'Content-Type: application/json' \
  -d '{
    "url": "https://example.com",
    "contentUse": "reference",
    "formats": ["markdown"]
  }'

For more information, refer to Content Signals in the /crawl endpoint documentation.

Cloudflare Load Balancing now supports pool sets through the API. Pool sets combine geographic matching with location-specific traffic steering. One load balancer can now use different routing behavior for different locations.

Each pool set can match a Cloudflare data center, country, or region. It then supplies the candidate pools and can apply its own steering policy, pool weights, and fallback pool. Cloudflare evaluates pool sets in array order and applies the first matching pool set.

For example, this pool set uses Dynamic Latency steering for traffic from Germany:

{
	"pool_sets": [
		{
			"name": "germany-lowest-latency",
			"match": { "topology": { "countries": ["DE"] } },
			"overrides": {
				"pools": [
					"0930eec54a4c7ae6616985b79f678210",
					"c8b4f5a6d7e84910a2b3c4d5e6f70819"
				],
				"steering_policy": "dynamic_latency"
			}
		}
	]
}

Use pool sets for active-active traffic distribution, location-specific failover, and regional routing policies. For proxied traffic, a pool set can also return a fixed HTTP response instead of selecting a pool.

For configuration details and more examples, refer to Pool sets.

AI Search now supports @cf/zai-org/glm-5.3-flash for text generation. The model has a 1,048,576-token context window and runs on Workers AI.

To configure the model for an AI Search instance, refer to Supported models.

A new GA release for the macOS Cloudflare One Client is now available on the stable releases downloads page.

This hotfix resolves an issue where a small but noticeable percentage of DNS queries fail across platforms.

A new GA release for the Windows Cloudflare One Client is now available on the stable releases downloads page.

Fixed a rare but critical issue where the client could fail to connect or switch organizations due to an invalid registration after switching installed client versions. Additionally, this hotfix resolves an issue where a small but noticeable percentage of DNS queries fail across platforms.

A new GA release for the Linux Cloudflare One Client is now available on the stable releases downloads page.

This hotfix resolves an issue where a small but noticeable percentage of DNS queries fail across platforms.

Log Explorer has a refreshed dataset configuration experience in the Cloudflare dashboard. The new controls make it easier to choose which fields and events Log Explorer ingests.

• Grouped field selection organizes fields by category and shows the number selected in each group.
• Field details identify each field's data type and mark required or deprecated fields.
• Bulk controls let you select all fields or reset the selection to the dataset defaults.
• Ingestion filters let you ingest all events or only events that match your conditions.

These controls are available when you add a dataset or select Actions > Edit for an enabled dataset.

For more information, refer to Configure fields and filters.

@cf/zai-org/glm-5.3 is now available on Workers AI. It is Z.ai's flagship agentic coding model, built for long-running, tool-driven development workflows rather than single-turn chat.

GLM-5.3 uses the same base model as GLM-5.2, with every gain coming from post-training. The results are substantial on coding and agentic benchmarks: Z.ai reports ↗︎ a 50% improvement over GLM-5.2 on its in-house Z.ai Code Bench, and calls GLM-5.3 the most capable open-weights model for coding. On public benchmarks, it scores 88.2 on Terminal Bench 2.1 (up from 81.0), 28.3 on Terminal Bench 3.0 — open-source state of the art, up from 4.6 — 66.9 on DeepSWE (up from 46.2), 78.1 on FrontierSWE (up from 67.5), and 42.5 on SWE-Marathon (up from 19.4). It is also the top-scoring model in Z.ai's comparisons on CyberGym for vulnerability discovery (84.5) and on long-horizon automation tasks like AutomationBench (48.2).

The price-to-performance ratio is the compelling part. On Workers AI, GLM-5.3 costs the same as GLM-5.2 — $1.40 per M input tokens, $0.26 per M cached input tokens, and $4.40 per M output tokens — while roughly doubling GLM-5.2's scores on long-horizon benchmarks like SWE-Marathon, and improving them by more than 6x on Terminal Bench 3.0.

GLM-5.3 requires the Workers Paid plan or prepaid AI Gateway credits.

Use GLM-5.3 through the Workers AI binding (env.AI.run()), the REST API, the OpenAI-compatible endpoint, or AI Gateway.

For more information, refer to the GLM-5.3 model page and pricing.