-
This week's update
This week’s focus highlights newly disclosed vulnerabilities in web frameworks, enterprise applications, and widely deployed CMS plugins. The vulnerabilities include SSRF, authentication bypass, arbitrary file upload, and remote code execution (RCE), exposing organizations to high-impact risks such as unauthorized access, system compromise, and potential data exposure. In addition, security rule enhancements have been deployed to cover general command injection and server-side injection attacks, further strengthening protections.
Key Findings
-
Next.js (CVE-2025-57822): Improper handling of redirects in custom middleware can lead to server-side request forgery (SSRF) when user-supplied headers are forwarded. Attackers could exploit this to access internal services or cloud metadata endpoints. The issue has been resolved in versions 14.2.32 and 15.4.7. Developers using custom middleware should upgrade and verify proper redirect handling in
next()calls. -
ScriptCase (CVE-2025-47227, CVE-2025-47228): In the Production Environment extension in Netmake ScriptCase through 9.12.006 (23), two vulnerabilities allow attackers to reset admin accounts and execute system commands, potentially leading to full compromise of affected deployments.
-
Sar2HTML (CVE-2025-34030): In Sar2HTML version 3.2.2 and earlier, insufficient input sanitization of the plot parameter allows remote, unauthenticated attackers to execute arbitrary system commands. Exploitation could compromise the underlying server and its data.
-
Zhiyuan OA (CVE-2025-34040): An arbitrary file upload vulnerability exists in the Zhiyuan OA platform. Improper validation in the
wpsAssistServletinterface allows unauthenticated attackers to upload crafted files via path traversal, which can be executed on the web server, leading to remote code execution. -
WordPress:Plugin:InfiniteWP Client (CVE-2020-8772): A vulnerability in the InfiniteWP Client plugin allows attackers to perform restricted actions and gain administrative control of connected WordPress sites.
Impact
These vulnerabilities could allow attackers to gain unauthorized access, execute malicious code, or take full control of affected systems. The Next.js SSRF flaw may expose internal services or cloud metadata endpoints to attackers. Exploitations of ScriptCase and Sar2HTML could result in remote code execution, administrative takeover, and full server compromise. In Zhiyuan OA, the arbitrary file upload vulnerability allows attackers to execute malicious code on the web server, potentially exposing sensitive data and applications. The authentication bypass in WordPress InfiniteWP Client enables attackers to gain administrative access, risking data exposure and unauthorized control of connected sites.
Administrators are strongly advised to apply vendor patches immediately, remove unsupported software, and review authentication and access controls to mitigate these risks.
Ruleset Rule ID Legacy Rule ID Description Previous Action New Action Comments Cloudflare Managed Ruleset 100007D Command Injection - Common Attack Commands Args Log Block This rule has been merged into the original rule "Command Injection - Common Attack Commands" (ID: Cloudflare Managed Ruleset 100617 Next.js - SSRF - CVE:CVE-2025-57822 Log Block This is a New Detection Cloudflare Managed Ruleset 100659_BETA Common Payloads for Server-Side Template Injection - Beta Log Block This rule is merged into the original rule "Common Payloads for Server-Side Template Injection" (ID: Cloudflare Managed Ruleset 100824B CrushFTP - Remote Code Execution - CVE:CVE-2025-54309 - 3 Log Disabled This is a New Detection Cloudflare Managed Ruleset 100848 ScriptCase - Auth Bypass - CVE:CVE-2025-47227 Log Disabled This is a New Detection Cloudflare Managed Ruleset 100849 ScriptCase - Command Injection - CVE:CVE-2025-47228 Log Disabled This is a New Detection Cloudflare Managed Ruleset 100872 WordPress:Plugin:InfiniteWP Client - Missing Authorization - CVE:CVE-2020-8772 Log Block This is a New Detection Cloudflare Managed Ruleset 100873 Sar2HTML - Command Injection - CVE:CVE-2025-34030 Log Block This is a New Detection Cloudflare Managed Ruleset 100875 Zhiyuan OA - Remote Code Execution - CVE:CVE-2025-34040 Log Block This is a New Detection -
-
Announcement Date Release Date Release Behavior Legacy Rule ID Rule ID Description Comments 2025-09-08 2025-09-15 Log 100646 Argo CD - Information Disclosure - CVE:CVE-2025-55190 This is a New Detection 2025-09-08 2025-09-15 Log 100874 DataEase - JNDI injection - CVE:CVE-2025-57773 This is a New Detection 2025-09-08 2025-09-15 Log 100880 Sitecore - Information Disclosure - CVE:CVE-2025-53694 This is a New Detection
-
We're excited to be a launch partner alongside Google ↗ to bring their newest embedding model, EmbeddingGemma, to Workers AI that delivers best-in-class performance for its size, enabling RAG and semantic search use cases.
@cf/google/embeddinggemma-300mis a 300M parameter embedding model from Google, built from Gemma 3 and the same research used to create Gemini models. This multilingual model supports 100+ languages, making it ideal for RAG systems, semantic search, content classification, and clustering tasks.Using EmbeddingGemma in AutoRAG: Now you can leverage EmbeddingGemma directly through AutoRAG for your RAG pipelines. EmbeddingGemma's multilingual capabilities make it perfect for global applications that need to understand and retrieve content across different languages with exceptional accuracy.
To use EmbeddingGemma for your AutoRAG projects:
- Go to Create in the AutoRAG dashboard ↗
- Follow the setup flow for your new RAG instance
- In the Generate Index step, open up More embedding models and select
@cf/google/embeddinggemma-300mas your embedding model - Complete the setup to create an AutoRAG
Try it out and let us know what you think!
-
This week's update
This week, new critical vulnerabilities were disclosed in Sitecore’s Sitecore Experience Manager (XM), Sitecore Experience Platform (XP), specifically versions 9.0 through 9.3, and 10.0 through 10.4. These flaws are caused by unsafe data deserialization and code reflection, leaving affected systems at high risk of exploitation.
Key Findings
- CVE-2025-53690: Remote Code Execution through Insecure Deserialization
- CVE-2025-53691: Remote Code Execution through Insecure Deserialization
- CVE-2025-53693: HTML Cache Poisoning through Unsafe Reflections
Impact
Exploitation could allow attackers to execute arbitrary code remotely on the affected system and conduct cache poisoning attacks, potentially leading to further compromise. Applying the latest vendor-released solution without delay is strongly recommended.
Ruleset Rule ID Legacy Rule ID Description Previous Action New Action Comments Cloudflare Managed Ruleset 100878 Sitecore - Remote Code Execution - CVE:CVE-2025-53691 N/A Block This is a new detection Cloudflare Managed Ruleset 100631 Sitecore - Cache Poisoning - CVE:CVE-2025-53693 N/A Block This is a new detection Cloudflare Managed Ruleset 100879 Sitecore - Remote Code Execution - CVE:CVE-2025-53690 N/A Block This is a new detection
-
You can now upload up to 100,000 static assets per Worker version
- Paid and Workers for Platforms users can now upload up to 100,000 static assets per Worker version, a 5x increase from the previous limit of 20,000.
- Customers on the free plan still have the same limit as before — 20,000 static assets per version of your Worker
- The individual file size limit of 25 MiB remains unchanged for all customers.
This increase allows you to build larger applications with more static assets without hitting limits.
To take advantage of the increased limits, you must use Wrangler version 4.34.0 or higher. Earlier versions of Wrangler will continue to enforce the previous 20,000 file limit.
For more information about Workers static assets, see the Static Assets documentation and Platform Limits.
-
You can now manage Workers, Versions, and Deployments as separate resources with a new, resource-oriented API (Beta).
This new API is supported in the Cloudflare Terraform provider ↗ and the Cloudflare Typescript SDK ↗, allowing platform teams to manage a Worker's infrastructure in Terraform, while development teams handle code deployments from a separate repository or workflow. We also designed this API with AI agents in mind, as a clear, predictable structure is essential for them to reliably build, test, and deploy applications.
- New beta API endpoints
- Cloudflare TypeScript SDK v5.0.0 ↗
- Cloudflare Go SDK v6.0.0 ↗
- Terraform provider v5.9.0 ↗:
cloudflare_worker↗ ,cloudflare_worker_version↗, andcloudflare_workers_deployments↗ resources. - See full examples in our Infrastructure as Code (IaC) guide
The existing API was originally designed for simple, one-shot script uploads:
Terminal window curl -X PUT "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/workers/scripts/$SCRIPT_NAME" \-H "X-Auth-Email: $CLOUDFLARE_EMAIL" \-H "X-Auth-Key: $CLOUDFLARE_API_KEY" \-H "Content-Type: multipart/form-data" \-F 'metadata={"main_module": "worker.js","compatibility_date": "$today$"}' \-F "worker.js=@worker.js;type=application/javascript+module"This API worked for creating a basic Worker, uploading all of its code, and deploying it immediately — but came with challenges:
-
A Worker couldn't exist without code: To create a Worker, you had to upload its code in the same API request. This meant platform teams couldn't provision Workers with the proper settings, and then hand them off to development teams to deploy the actual code.
-
Several endpoints implicitly created deployments: Simple updates like adding a secret or changing a script's content would implicitly create a new version and immediately deploy it.
-
Updating a setting was confusing: Configuration was scattered across eight endpoints with overlapping responsibilities. This ambiguity made it difficult for human developers (and even more so for AI agents) to reliably update a Worker via API.
-
Scripts used names as primary identifiers: This meant simple renames could turn into a risky migration, requiring you to create a brand new Worker and update every reference. If you were using Terraform, this could inadvertently destroy your Worker altogether.
All endpoints now use simple JSON payloads, with script content embedded as
base64-encoded strings -- a more consistent and reliable approach than the previousmultipart/form-dataformat.-
Worker: The parent resource representing your application. It has a stable UUID and holds persistent settings like
name,tags, andlogpush. You can now create a Worker to establish its identity and settings before any code is uploaded. -
Version: An immutable snapshot of your code and its specific configuration, like bindings and
compatibility_date. Creating a new version is a safe action that doesn't affect live traffic. -
Deployment: An explicit action that directs traffic to a specific version.
Workers are now standalone resources that can be created and configured without any code. Platform teams can provision Workers with the right settings, then hand them off to development teams for implementation.
// Step 1: Platform team creates the Worker resource (no code needed)const worker = await client.workers.beta.workers.create({name: "payment-service",account_id: "...",observability: {enabled: true,},});// Step 2: Development team adds code and creates a version laterconst version = await client.workers.beta.workers.versions.create(worker.id, {account_id: "...",main_module: "worker.js",compatibility_date: "$today",bindings: [ /*...*/ ],modules: [{name: "worker.js",content_type: "application/javascript+module",content_base64: Buffer.from(scriptContent).toString("base64"),},],});// Step 3: Deploy explicitly when readyconst deployment = await client.workers.scripts.deployments.create(worker.name, {account_id: "...",strategy: "percentage",versions: [{percentage: 100,version_id: version.id,},],});If you use Terraform, you can now declare the Worker in your Terraform configuration and manage configuration outside of Terraform in your Worker's
wrangler.jsoncfile and deploy code changes using Wrangler.resource "cloudflare_worker" "my_worker" {account_id = "..."name = "my-important-service"}# Manage Versions and Deployments here or outside of Terraform# resource "cloudflare_worker_version" "my_worker_version" {}# resource "cloudflare_workers_deployment" "my_worker_deployment" {}Creating a version and deploying it are now always explicit, separate actions - never implicit side effects. To update version-specific settings (like bindings), you create a new version with those changes. The existing deployed version remains unchanged until you explicitly deploy the new one.
Terminal window # Step 1: Create a new version with updated settings (doesn't affect live traffic)POST /workers/workers/{id}/versions{"compatibility_date": "$today","bindings": [{"name": "MY_NEW_ENV_VAR","text": "new_value","type": "plain_text"}],"modules": [...]}# Step 2: Explicitly deploy when ready (now affects live traffic)POST /workers/scripts/{script_name}/deployments{"strategy": "percentage","versions": [{"percentage": 100,"version_id": "new_version_id"}]}Configuration is now logically divided: Worker settings (like
nameandtags) persist across all versions, while Version settings (likebindingsandcompatibility_date) are specific to each code snapshot.Terminal window # Worker settings (the parent resource)PUT /workers/workers/{id}{"name": "payment-service","tags": ["production"],"logpush": true,}Terminal window # Version settings (the "code")POST /workers/workers/{id}/versions{"compatibility_date": "$today","bindings": [...],"modules": [...]}The
/workers/workers/path now supports addressing a Worker by both its immutable UUID and its mutable name.Terminal window # Both work for the same WorkerGET /workers/workers/29494978e03748669e8effb243cf2515 # UUID (stable for automation)GET /workers/workers/payment-service # Name (convenient for humans)This dual approach means:
- Developers can use readable names for debugging.
- Automation can rely on stable UUIDs to prevent errors when Workers are renamed.
- Terraform can rename Workers without destroying and recreating them.
- The pre-existing Workers REST API remains fully supported. Once the new API exits beta, we'll provide a migration timeline with ample notice and comprehensive migration guides.
- Existing Terraform resources and SDK methods will continue to be fully supported through the current major version.
- While the Deployments API currently remains on the
/scripts/endpoint, we plan to introduce a new Deployments endpoint under/workers/to match the new API structure.
-
Cloudflare's API now supports rate limiting headers using the pattern developed by the IETF draft on rate limiting ↗. This allows API consumers to know how many more calls are left until the rate limit is reached, as well as how long you will need to wait until more capacity is available.
Our SDKs automatically work with these new headers, backing off when rate limits are approached. There is no action required for users of the latest Cloudflare SDKs to take advantage of this.
As always, if you need any help with rate limits, please contact Support.
Headers that are always returned:
- X-RateLimit-Limit: Total Number of requests the caller can make
- X-RateLimit-Remaining: Number of requests before Rate Limit kicks in
Returned only when a rate limit has been reached (error code: 429):
- Retry-After: Number of Seconds until more capacity is available, rounded up
- X-RateLimit-Reset: RFC 1123 Formatted Date as to when more capacity is available
- All SDKs will automatically respond to the headers, instituting a backoff when limits are approached.
These new headers and back offs are only available for Cloudflare REST APIs, and will not affect GraphQL.
-
Starting December 1, 2025, list endpoints for the Cloudflare Tunnel API and Zero Trust Networks API will no longer return deleted tunnels, routes, subnets and virtual networks by default. This change makes the API behavior more intuitive by only returning active resources unless otherwise specified.
No action is required if you already explicitly set
is_deleted=falseor if you only need to list active resources.This change affects the following API endpoints:
- List all tunnels:
GET /accounts/{account_id}/tunnels - List Cloudflare Tunnels:
GET /accounts/{account_id}/cfd_tunnel - List WARP Connector tunnels:
GET /accounts/{account_id}/warp_connector - List tunnel routes:
GET /accounts/{account_id}/teamnet/routes - List subnets:
GET /accounts/{account_id}/zerotrust/subnets - List virtual networks:
GET /accounts/{account_id}/teamnet/virtual_networks
The default behavior of the
is_deletedquery parameter will be updated.Scenario Previous behavior (before December 1, 2025) New behavior (from December 1, 2025) is_deletedparameter is omittedReturns active & deleted tunnels, routes, subnets and virtual networks Returns only active tunnels, routes, subnets and virtual networks If you need to retrieve deleted (or all) resources, please update your API calls to explicitly include the
is_deletedparameter before December 1, 2025.To get a list of only deleted resources, you must now explicitly add the
is_deleted=truequery parameter to your request:Terminal window # Example: Get ONLY deleted Tunnelscurl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/tunnels?is_deleted=true" \-H "Authorization: Bearer $API_TOKEN"# Example: Get ONLY deleted Virtual Networkscurl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/virtual_networks?is_deleted=true" \-H "Authorization: Bearer $API_TOKEN"Following this change, retrieving a complete list of both active and deleted resources will require two separate API calls: one to get active items (by omitting the parameter or using
is_deleted=false) and one to get deleted items (is_deleted=true).This update is based on user feedback and aims to:
- Create a more intuitive default: Aligning with common API design principles where list operations return only active resources by default.
- Reduce unexpected results: Prevents users from accidentally operating on deleted resources that were returned unexpectedly.
- Improve performance: For most users, the default query result will now be smaller and more relevant.
To learn more, please visit the Cloudflare Tunnel API and Zero Trust Networks API documentation.
- List all tunnels:
-
To provide more granular controls, we refined the existing roles for Email Security and launched a new Email Security role as well.
All Email Security roles no longer have read or write access to any of the other Zero Trust products:
- Email Configuration Admin
- Email Integration Admin
- Email Security Read Only
- Email Security Analyst
- Email Security Policy Admin
- Email Security Reporting
To configure Data Loss Prevention (DLP) or Remote Browser Isolation (RBI), you now need to be an admin for the Zero Trust dashboard with the Cloudflare Zero Trust role.
Also through customer feedback, we have created a new additive role to allow Email Security Analyst to create, edit, and delete Email Security policies, without needing to provide access via the Email Configuration Admin role. This role is called Email Security Policy Admin, which can read all settings, but has write access to allow policies, trusted domains, and blocked senders.
This feature is available across these Email Security packages:
- Advantage
- Enterprise
- Enterprise + PhishGuard
-
This week's update
This week, a critical vulnerability was disclosed in Fortinet FortiWeb (versions 7.6.3 and below, versions 7.4.7 and below, versions 7.2.10 and below, and versions 7.0.10 and below), linked to improper parameter handling that could allow unauthorized access.
Key Findings
- Fortinet FortiWeb (CVE-2025-52970): A vulnerability may allow an unauthenticated remote attacker with access to non-public information to log in as any existing user on the device via a specially crafted request.
Impact
Exploitation could allow an unauthenticated attacker to impersonate any existing user on the device, potentially enabling them to modify system settings or exfiltrate sensitive information, posing a serious security risk. Upgrading to the latest vendor-released version is strongly recommended.
Ruleset Rule ID Legacy Rule ID Description Previous Action New Action Comments Cloudflare Managed Ruleset 100586 Fortinet FortiWeb - Auth Bypass - CVE:CVE-2025-52970 Log Disabled This is a New Detection Cloudflare Managed Ruleset 100136C XSS - JavaScript - Headers and Body N/A N/A Rule metadata description refined. Detection unchanged.