In January 2025, we announced the launch of the new Terraform v5 Provider. We greatly appreciate the proactive engagement and valuable feedback from the Cloudflare community following the v5 release. In response, we have established a consistent and rapid 2-3 week cadence for releasing targeted improvements, demonstrating our commitment to stability and reliability. With the help of the community, we have a growing number of resources that we have marked as stable, with that list continuing to grow with every release. The most used resources are on track to be stable by the end of March 2026, when we will also be releasing a new migration tool to help you migrate from v4 to v5 with ease. This release brings new capabilities for AI Search, enhanced Workers Script placement controls, and numerous bug fixes based on community feedback. We also begun laying foundational work for improving the v4 to v5 migration process. Stay tuned for more details as we approach the March 2026 release timeline. Thank you for continuing to raise issues. They make our provider stronger and help us build products that reflect your needs. Features
ai_search_instance: add data source for querying AI Search instances ai_search_token: add data source for querying AI Search tokens account: add support for tenant unit management with new unit field account: add automatic mapping from managed_by.parent_org_id to unit.id authenticated_origin_pulls_certificate: add data source for querying authenticated origin pull certificates authenticated_origin_pulls_hostname_certificate: add data source for querying hostname-specific authenticated origin pull certificates authenticated_origin_pulls_settings: add data source for querying authenticated origin pull settings workers_kv: add value field to data source to retrieve KV values directly workers_script: add script field to data source to retrieve script content workers_script: add support for simple rate limit binding workers_script: add support for targeted placement mode with placement.target array for specifying placement targets (region, hostname, host) workers_script: add placement_mode and placement_status computed fields zero_trust_dex_test: add data source with filter support for finding specific tests zero_trust_dlp_predefined_profile: add enabled_entries field for flexible entry management
Bug Fixes
account: map managed_by.parent_org_id to unit.id in unmarshall and add acceptance tests authenticated_origin_pulls_certificate: add certificate normalization to prevent drift authenticated_origin_pulls: handle array response and implement full lifecycle authenticated_origin_pulls_hostname_certificate: fix resource and tests cloudforce_one_request_message: use correct request_id field instead of id in API calls dns_zone_transfers_incoming: use correct zone_id field instead of id in API calls dns_zone_transfers_outgoing: use correct zone_id field instead of id in API calls email_routing_settings: use correct zone_id field instead of id in API calls hyperdrive_config: add proper handling for write-only fields to prevent state drift hyperdrive_config: add normalization for empty mtls objects to prevent unnecessary diffs magic_network_monitoring_rule: use correct account_id field instead of id in API calls mtls_certificates: fix resource and test pages_project: revert build_config to computed optional stream_key: use correct account_id field instead of id in API calls total_tls: use upsert pattern for singleton zone setting waiting_room_rules: use correct waiting_room_id field instead of id in API calls workers_script: add support for placement mode/status zero_trust_access_application: update v4 version on migration tests zero_trust_device_posture_rule: update tests to match API zero_trust_dlp_integration_entry: use correct entry_id field instead of id in API calls zero_trust_dlp_predefined_entry: use correct entry_id field instead of id in API calls zero_trust_organization: fix plan issues
Chores
add state upgraders to 95+ resources to lay the foundation for replacing Grit (still under active development) certificate_pack: add state migration handler for SDKv2 to Framework conversion custom_hostname_fallback_origin: add comprehensive lifecycle test and migration support dns_record: add state migration handler for SDKv2 to Framework conversion leaked_credential_check: add import functionality and tests load_balancer_pool: add state migration handler with detection for v4 vs v5 format pages_project: add state migration handlers tiered_cache: add state migration handlers zero_trust_dlp_predefined_profile: deprecate entries field in favor of enabled_entries
For more information
Terraform Provider Documentation on using Terraform with Cloudflare List of stabilized resources
Cloudflare One Appliance version 2026.2.0 adds post-quantum encryption support using hybrid ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism). The appliance now uses TLS 1.3 with hybrid ML-KEM for its connection to the Cloudflare edge. During the TLS handshake, the appliance and the edge share a symmetric secret over the TLS connection and inject it into the ESP layer of IPsec. This protects IPsec data plane traffic against harvest-now, decrypt-later attacks. This upgrade deploys automatically to all appliances during their configured interrupt windows with no manual action required. For more information, refer to Cloudflare One Appliance.
Workers no longer have a limit of 1000 subrequests per invocation, allowing you to make more fetch() calls or requests
to Cloudflare services on every incoming request. This is especially important for long-running Workers requests, such as
open websockets on Durable Objects or long-running Workflows, as these could often exceed this limit and error.
By default, Workers on paid plans are now limited to 10,000 subrequests per invocation, but this
limit can be increased up to 10 million by setting the new subrequests limit in your Wrangler configuration file.
wrangler.jsonc { "limits": { "subrequests": 50000, },} wrangler.toml [limits]subrequests = 50_000
Workers on the free plan remain limited to 50 external subrequests and 1000 subrequests to Cloudflare services per invocation.
To protect against runaway code or unexpected costs, you can also set a lower limit for both subrequests and CPU usage.
wrangler.jsonc { "limits": { "subrequests": 10, "cpu_ms": 1000, },} wrangler.toml [limits]subrequests = 10cpu_ms = 1_000
For more information, refer to the Wrangler configuration documentation for limits and subrequest limits.
The Cloudflare Vite plugin now integrates seamlessly @vitejs/plugin-rsc, the official Vite plugin for React Server Components. A childEnvironments option has been added to the plugin config to enable using multiple environments within a single Worker. The parent environment can then import modules from a child environment in order to access a separate module graph. For a typical RSC use case, the plugin might be configured as in the following example: export default defineConfig({ plugins: [ cloudflare({ viteEnvironment: { name: "rsc", childEnvironments: ["ssr"], }, }), ],}); @vitejs/plugin-rsc provides the lower level functionality that frameworks, such as React Router, build upon. The GitHub repository includes a basic Cloudflare example.
This week’s release changes the rule action from BLOCK to Disabled for Anomaly:Header:User-Agent - Fake Google Bot. RulesetRule IDLegacy Rule IDDescriptionPrevious ActionNew ActionCommentsCloudflare Managed Rulesetce11be543594412bb4bb92516aa0bef8 N/AAnomaly:Header:User-Agent - Fake Google BotEnabledDisabledWe are changing the action for this rule from BLOCK to Disabled
AI Crawl Control metrics have been enhanced with new views, improved filtering, and better data visualization. Path pattern grouping
In the Metrics tab > Most popular paths table, use the new Patterns tab that groups requests by URI pattern (/blog/, /api/v1/, /docs/*) to identify which site areas crawlers target most. Refer to the screenshot above.
Enhanced referral analytics
Destination patterns show which site areas receive AI-driven referral traffic. In the Metrics tab, a new Referrals over time chart shows trends by operator or source.
Data transfer metrics
In the Metrics tab > Allowed requests over time chart, toggle Bytes to show bandwidth consumption. In the Crawlers tab, a new Bytes Transferred column shows bandwidth per crawler.
Image exports
Export charts and tables as images for reports and presentations.
Learn more about analyzing AI traffic.
R2 SQL now supports five approximate aggregation functions for fast analysis of large datasets. These functions trade minor precision for improved performance on high-cardinality data. New functions
APPROX_PERCENTILE_CONT(column, percentile) — Returns the approximate value at a given percentile (0.0 to 1.0). Works on integer and decimal columns. APPROX_PERCENTILE_CONT_WITH_WEIGHT(column, weight, percentile) — Weighted percentile calculation where each row contributes proportionally to its weight column value. APPROX_MEDIAN(column) — Returns the approximate median. Equivalent to APPROX_PERCENTILE_CONT(column, 0.5). APPROX_DISTINCT(column) — Returns the approximate number of distinct values. Works on any column type. APPROX_TOP_K(column, k) — Returns the k most frequent values with their counts as a JSON array.
All functions support WHERE filters. All except APPROX_TOP_K support GROUP BY. Examples -- Percentile analysis on revenue dataSELECT approx_percentile_cont(total_amount, 0.25), approx_percentile_cont(total_amount, 0.5), approx_percentile_cont(total_amount, 0.75)FROM my_namespace.sales_data -- Median per departmentSELECT department, approx_median(total_amount)FROM my_namespace.sales_dataGROUP BY department -- Approximate distinct customers by regionSELECT region, approx_distinct(customer_id)FROM my_namespace.sales_dataGROUP BY region -- Top 5 most frequent departmentsSELECT approx_top_k(department, 5)FROM my_namespace.sales_data -- Combine approximate and standard aggregationsSELECT COUNT(*), AVG(total_amount), approx_percentile_cont(total_amount, 0.5), approx_distinct(customer_id)FROM my_namespace.sales_dataWHERE region = 'North' For the full syntax and additional examples, refer to the SQL reference.
Get your content updates into AI Search faster and avoid a full rescan when you do not need it. Reindex individual files without a full sync Updated a file or need to retry one that errored? When you know exactly which file changed, you can now reindex it directly instead of rescanning your entire data source. Go to Overview > Indexed Items and select the sync icon next to any file to reindex it immediately. Crawl only the sitemap you need By default, AI Search crawls all sitemaps listed in your robots.txt, up to the maximum files per index limit. If your site has multiple sitemaps but you only want to index a specific set, you can now specify a single sitemap URL to limit what the crawler visits. For example, if your robots.txt lists both blog-sitemap.xml and docs-sitemap.xml, you can specify just https://example.com/docs-sitemap.xml to index only your documentation. Configure your selection anytime in Settings > Parsing options > Specific sitemaps, then trigger a sync to apply the changes. Learn more about indexing controls and website crawling configuration.
The Sandbox SDK now supports PTY (pseudo-terminal) passthrough, enabling browser-based terminal UIs to connect to sandbox shells via WebSocket.
sandbox.terminal(request)
The new terminal() method proxies a WebSocket upgrade to the container's PTY endpoint, with output buffering for replay on reconnect.
JavaScript // Worker: proxy WebSocket to container terminalreturn sandbox.terminal(request, { cols: 80, rows: 24 }); TypeScript // Worker: proxy WebSocket to container terminalreturn sandbox.terminal(request, { cols: 80, rows: 24 });
Multiple terminals per sandbox
Each session can have its own terminal with an isolated working directory and environment, so users can run separate shells side-by-side in the same container.
JavaScript // Multiple isolated terminals in the same sandboxconst dev = await sandbox.getSession("dev");return dev.terminal(request); TypeScript // Multiple isolated terminals in the same sandboxconst dev = await sandbox.getSession("dev");return dev.terminal(request);
xterm.js addon
The new @cloudflare/sandbox/xterm export provides a SandboxAddon for xterm.js with automatic reconnection (exponential backoff + jitter), buffered output replay, and resize forwarding.
JavaScript import { SandboxAddon } from "@cloudflare/sandbox/xterm";
const addon = new SandboxAddon({ getWebSocketUrl: ({ sandboxId, origin }) => ${origin}/ws/terminal?id=${sandboxId}, onStateChange: (state, error) => updateUI(state),});terminal.loadAddon(addon);addon.connect({ sandboxId: "my-sandbox" }); TypeScript import { SandboxAddon } from "@cloudflare/sandbox/xterm";
const addon = new SandboxAddon({ getWebSocketUrl: ({ sandboxId, origin }) => ${origin}/ws/terminal?id=${sandboxId}, onStateChange: (state, error) => updateUI(state),});terminal.loadAddon(addon);addon.connect({ sandboxId: "my-sandbox" });
Upgrade
To update to the latest version:
npm i @cloudflare/sandbox@latest
Log Explorer now supports multiple concurrent queries with the new Tabs feature. Work with multiple queries simultaneously and pivot between datasets to investigate malicious activity more effectively. Key capabilities
Multiple tabs: Open and switch between multiple query tabs to compare results across different datasets. Quick filtering: Select the filter button from query results to add a value as a filter to your current query. Pivot to new tab: Use Cmd + click on the filter button to start a new query tab with that filter applied. Preserved progress: Your query progress is preserved on each tab if you navigate away and return.
For more information, refer to the Log Explorer documentation.
The latest release of the Agents SDK brings readonly connections, MCP protocol and security improvements, x402 payment protocol v2 migration, and the ability to customize OAuth for MCP server connections.
Readonly connections
Agents can now restrict WebSocket clients to read-only access, preventing them from modifying agent state. This is useful for dashboards, spectator views, or any scenario where clients should observe but not mutate.
New hooks: shouldConnectionBeReadonly, setConnectionReadonly, isConnectionReadonly. Readonly connections block both client-side setState() and mutating @callable() methods, and the readonly flag survives hibernation.
JavaScript class MyAgent extends Agent { shouldConnectionBeReadonly(connection) { // Make spectators readonly return connection.url.includes("spectator"); }} TypeScript class MyAgent extends Agent { shouldConnectionBeReadonly(connection) { // Make spectators readonly return connection.url.includes("spectator"); }}
Custom MCP OAuth providers
The new createMcpOAuthProvider method on the Agent class allows subclasses to override the default OAuth provider used when connecting to MCP servers. This enables custom authentication strategies such as pre-registered client credentials or mTLS, beyond the built-in dynamic client registration.
JavaScript class MyAgent extends Agent { createMcpOAuthProvider(callbackUrl) { return new MyCustomOAuthProvider(this.ctx.storage, this.name, callbackUrl); }} TypeScript class MyAgent extends Agent { createMcpOAuthProvider(callbackUrl: string): AgentMcpOAuthProvider { return new MyCustomOAuthProvider(this.ctx.storage, this.name, callbackUrl); }}
MCP SDK upgrade to 1.26.0
Upgraded the MCP SDK to 1.26.0 to prevent cross-client response leakage. Stateless MCP Servers should now create a new McpServer instance per request instead of sharing a single instance. A guard is added in this version of the MCP SDK which will prevent connection to a Server instance that has already been connected to a transport. Developers will need to modify their code if they declare their McpServer instance as a global variable.
MCP OAuth callback URL security fix
Added callbackPath option to addMcpServer to prevent instance name leakage in MCP OAuth callback URLs. When sendIdentityOnConnect is false, callbackPath is now required — the default callback URL would expose the instance name, undermining the security intent. Also fixes callback request detection to match via the state parameter instead of a loose /callback URL substring check, enabling custom callback paths.
Deprecate onStateUpdate in favor of onStateChanged
onStateChanged is a drop-in rename of onStateUpdate (same signature, same behavior). onStateUpdate still works but emits a one-time console warning per class. validateStateChange rejections now propagate a CF_AGENT_STATE_ERROR message back to the client.
x402 v2 migration
Migrated the x402 MCP payment integration from the legacy x402 package to @x402/core and @x402/evm v2.
Breaking changes for x402 users:
Peer dependencies changed: replace x402 with @x402/core and @x402/evm PaymentRequirements type now uses v2 fields (e.g. amount instead of maxAmountRequired) X402ClientConfig.account type changed from viem.Account to ClientEvmSigner (structurally compatible with privateKeyToAccount())
npm uninstall x402npm install @x402/core @x402/evm Network identifiers now accept both legacy names and CAIP-2 format: // Legacy name (auto-converted){ network: "base-sepolia",} // CAIP-2 format (preferred){ network: "eip155:84532",} Other x402 changes:
X402ClientConfig.network is now optional — the client auto-selects from available payment requirements Server-side lazy initialization: facilitator connection is deferred until the first paid tool invocation Payment tokens support both v2 (PAYMENT-SIGNATURE) and v1 (X-PAYMENT) HTTP headers Added normalizeNetwork export for converting legacy network names to CAIP-2 format Re-exports PaymentRequirements, PaymentRequired, Network, FacilitatorConfig, and ClientEvmSigner from agents/x402
Other improvements
Fix useAgent and AgentClient crashing when using basePath routing CORS handling delegated to partyserver's native support (simpler, more reliable) Client-side onStateUpdateError callback for handling rejected state updates
Upgrade To update to the latest version: npm i agents@latest
The Workers Observability dashboard has some major updates to make it easier to debug your application's issues and share findings with your team. You can now:
Create visualizations — Build charts from your Worker data directly in a Worker's Observability tab Export data as JSON or CSV — Download logs and traces for offline analysis or to share with teammates Share events and traces — Generate direct URLs to specific events, invocations, and traces that open standalone pages with full context Customize table columns — Improved field picker to add, remove, and reorder columns in the events table Expandable event details — Expand events inline to view full details without leaving the table Keyboard shortcuts — Navigate the dashboard with hotkey support
These updates are now live in the Cloudflare dashboard, both in a Worker's Observability tab and in the account-level Observability dashboard for a unified experience. To get started, go to Workers & Pages > select your Worker > Observability.
Cloudflare Workflows now automatically generates visual diagrams from your code Your Workflow is parsed to provide a visual map of the Workflow structure, allowing you to:
Understand how steps connect and execute Visualize loops and nested logic Follow branching paths for conditional logic
You can collapse loops and nested logic to see the high-level flow, or expand them to see every step. Workflow diagrams are available in beta for all JavaScript and TypeScript Workflows. Find your Workflows in the Cloudflare dashboard to see their diagrams.
Cloudflare Queues is now part of the Workers free plan, offering guaranteed message delivery across up to 10,000 queues to either Cloudflare Workers or HTTP pull consumers. Every Cloudflare account now includes 10,000 operations per day across reads, writes, and deletes. For more details on how each operation is defined, refer to Queues pricing. All features of the existing Queues functionality are available on the free plan, including unlimited event subscriptions. Note that the maximum retention period on the free tier, however, is 24 hours rather than 14 days. If you are new to Cloudflare Queues, follow this guide or try one of our tutorials to get started.
New reference documentation is now available for AI Crawl Control:
GraphQL API reference — Query examples for crawler requests, top paths, referral traffic, and data transfer. Includes key filters for detection IDs, user agents, and referrer domains. Bot reference — Detection IDs and user agents for major AI crawlers from OpenAI, Anthropic, Google, Meta, and others. Worker templates — Deploy the x402 Payment-Gated Proxy to monetize crawler access or charge bots while letting humans through free.
Local Uploads is now available in open beta. Enable it on your R2 bucket to improve upload performance when clients upload data from a different region than your bucket. With Local Uploads enabled, object data is written to storage infrastructure near the client, then asynchronously replicated to your bucket. The object is immediately accessible and remains strongly consistent throughout. Refer to How R2 works for details on how data is written to your bucket. In our tests, we observed up to 75% reduction in Time to Last Byte (TTLB) for upload requests when Local Uploads is enabled. This feature is ideal when:
Your users are globally distributed Upload performance and reliability is critical to your application You want to optimize write performance without changing your bucket's primary location
To enable Local Uploads on your bucket, find Local Uploads in your bucket settings in the Cloudflare Dashboard, or run: npx wrangler r2 bucket local-uploads enable Enabling Local Uploads on a bucket is seamless: existing uploads will complete as expected and there’s no interruption to traffic. There is no additional cost to enable Local Uploads. Upload requests incur the standard Class A operation costs same as upload requests made without Local Uploads. For more information, refer to Local Uploads.
Identifying threat actors can be challenging, because naming conventions often vary across the security industry. To simplify your research, Cloudflare Threat Events now include an Also known as field, providing a list of common aliases and industry-standard names for the groups we track. This new field is available in both the Cloudflare dashboard and via the API. In the dashboard, you can view these aliases by expanding the event details side panel (under the Attacker field) or by adding it as a column in your configurable table view. Key benefits
Easily map Cloudflare-tracked actors to the naming conventions used by other vendors without manual cross-referencing. Quickly identify if a detected threat actor matches a group your team is already monitoring via other intelligence feeds.
For more information on how to access this data, refer to the Threat Events API documentation.
The latest release of the Agents SDK brings first-class support for Cloudflare Workflows, synchronous state management, and new scheduling capabilities.
Cloudflare Workflows integration
Agents excel at real-time communication and state management. Workflows excel at durable execution. Together, they enable powerful patterns where Agents handle WebSocket connections while Workflows handle long-running tasks, retries, and human-in-the-loop flows.
Use the new AgentWorkflow class to define workflows with typed access to your Agent:
JavaScript import { AgentWorkflow } from "agents/workflows";export class ProcessingWorkflow extends AgentWorkflow { async run(event, step) { // Call Agent methods via RPC await this.agent.updateStatus(event.payload.taskId, "processing");
// Non-durable: progress reporting to clients await this.reportProgress({ step: "process", percent: 0.5 }); this.broadcastToClients({ type: "update", taskId: event.payload.taskId });
// Durable via step: idempotent, won't repeat on retry await step.mergeAgentState({ taskProgress: 0.5 });
const result = await step.do("process", async () => { return processData(event.payload.data); });
await step.reportComplete(result); return result; }} TypeScript import { AgentWorkflow } from "agents/workflows";import type { AgentWorkflowEvent, AgentWorkflowStep } from "agents/workflows";
export class ProcessingWorkflow extends AgentWorkflowMyAgent, TaskParams> { async run(event: AgentWorkflowEventTaskParams>, step: AgentWorkflowStep) { // Call Agent methods via RPC await this.agent.updateStatus(event.payload.taskId, "processing");
// Non-durable: progress reporting to clients await this.reportProgress({ step: "process", percent: 0.5 }); this.broadcastToClients({ type: "update", taskId: event.payload.taskId });
// Durable via step: idempotent, won't repeat on retry await step.mergeAgentState({ taskProgress: 0.5 });
const result = await step.do("process", async () => { return processData(event.payload.data); });
await step.reportComplete(result); return result; }}
Start workflows from your Agent with runWorkflow() and handle lifecycle events:
JavaScript export class MyAgent extends Agent { async startTask(taskId, data) { const instanceId = await this.runWorkflow("PROCESSING_WORKFLOW", { taskId, data, }); return { instanceId }; }
async onWorkflowProgress(workflowName, instanceId, progress) { this.broadcast(JSON.stringify({ type: "progress", progress })); }
async onWorkflowComplete(workflowName, instanceId, result) { console.log(Workflow ${instanceId} completed); }
async onWorkflowError(workflowName, instanceId, error) { console.error(Workflow ${instanceId} failed:, error); }} TypeScript export class MyAgent extends Agent { async startTask(taskId: string, data: string) { const instanceId = await this.runWorkflow("PROCESSING_WORKFLOW", { taskId, data, }); return { instanceId }; }
async onWorkflowProgress( workflowName: string, instanceId: string, progress: unknown, ) { this.broadcast(JSON.stringify({ type: "progress", progress })); }
async onWorkflowComplete( workflowName: string, instanceId: string, result?: unknown, ) { console.log(Workflow ${instanceId} completed); }
async onWorkflowError( workflowName: string, instanceId: string, error: unknown, ) { console.error(Workflow ${instanceId} failed:, error); }}
Key workflow methods on your Agent:
runWorkflow(workflowName, params, options?) — Start a workflow with optional metadata getWorkflow(workflowId) / getWorkflows(criteria?) — Query workflows with cursor-based pagination approveWorkflow(workflowId) / rejectWorkflow(workflowId) — Human-in-the-loop approval flows pauseWorkflow(), resumeWorkflow(), terminateWorkflow() — Workflow control
Synchronous setState()
State updates are now synchronous with a new validateStateChange() validation hook:
JavaScript export class MyAgent extends Agent { validateStateChange(oldState, newState) { // Return false to reject the change if (newState.count 0) return false; // Return modified state to transform return { ...newState, lastUpdated: Date.now() }; }} TypeScript export class MyAgent extends AgentEnv, State> { validateStateChange(oldState: State, newState: State): State | false { // Return false to reject the change if (newState.count 0) return false; // Return modified state to transform return { ...newState, lastUpdated: Date.now() }; }}
scheduleEvery() for recurring tasks
The new scheduleEvery() method enables fixed-interval recurring tasks with built-in overlap prevention:
JavaScript // Run every 5 minutesawait this.scheduleEvery("syncData", 5 * 60 * 1000, { source: "api" }); TypeScript // Run every 5 minutesawait this.scheduleEvery("syncData", 5 * 60 * 1000, { source: "api" });
Callable system improvements
Client-side RPC timeout — Set timeouts on callable method invocations StreamingResponse.error(message) — Graceful stream error signaling getCallableMethods() — Introspection API for discovering callable methods Connection close handling — Pending calls are automatically rejected on disconnect
JavaScript await agent.call("method", [args], { timeout: 5000, stream: { onChunk, onDone, onError },}); TypeScript await agent.call("method", [args], { timeout: 5000, stream: { onChunk, onDone, onError },});
Email and routing enhancements
Secure email reply routing — Email replies are now secured with HMAC-SHA256 signed headers, preventing unauthorized routing of emails to agent instances.
Routing improvements:
basePath option to bypass default URL construction for custom routing Server-sent identity — Agents send name and agent type on connect New onIdentity and onIdentityChange callbacks on the client
JavaScript const agent = useAgent({ basePath: "user", onIdentity: (name, agentType) => console.log(Connected to ${name}),}); TypeScript const agent = useAgent({ basePath: "user", onIdentity: (name, agentType) => console.log(Connected to ${name}),});
Upgrade
To update to the latest version:
npm i agents@latest
For the complete Workflows API reference and patterns, see Run Workflows.
We have updated the Monitoring page to provide a more streamlined and insightful experience for administrators, improving both data visualization and dashboard accessibility.
Enhanced Visual Layout: Optimized contrast and the introduction of stacked bar charts for clearer data visualization and trend analysis. Improved Accessibility & Usability:
Widget Search: Added search functionality to multiple widgets, including Policies, Submitters, and Impersonation. Actionable UI: All available actions are now accessible via dedicated buttons. State Indicators: Improved UI states to clearly communicate loading, empty datasets, and error conditions.
Granular Data Breakdowns: New views for dispositions by month, malicious email details, link actions, and impersonations.
This applies to all Email Security packages:
Advantage Enterprise Enterprise + PhishGuard
This week’s release introduces new detections for CVE-2025-64459 and CVE-2025-24893. Key Findings
CVE-2025-64459: Django versions prior to 5.1.14, 5.2.8, and 4.2.26 are vulnerable to SQL injection via crafted dictionaries passed to QuerySet methods and the Q() class. CVE-2025-24893: XWiki allows unauthenticated remote code execution through crafted requests to the SolrSearch endpoint, affecting the entire installation.
RulesetRule IDLegacy Rule IDDescriptionPrevious ActionNew ActionCommentsCloudflare Managed Ruleset7a47683eacce4abd870ab2c630698ff3 N/AXWiki - Remote Code Execution - CVE:CVE-2025-24893 2LogBlockThis is a new detection.Cloudflare Managed Rulesetad5c52f6ca334ef4a844e5e5da8ba7e6 N/ADjango SQLI - CVE:CVE-2025-64459LogBlockThis is a new detection.Cloudflare Managed Ruleset8f0d5c98bd24460a9305a1558d667511 N/ANoSQL, MongoDB - SQLi - Comparison - 2BlockBlockRule metadata description refined. Detection unchanged.