Cloudflare

196 posts

blog.cloudflare.com

Filter by tag

cloudflare3 min readCurated summary

From reactive to proactive: closing the phishing gap with LLMs

Cloudflare argues that email security must move beyond reacting to user-reported phishing misses. LLMs can analyze millions of emails, reveal emerging threat patterns that traditional systems overlook, and guide specialized detection models before attacks become widespread. Its Sales Outreach phishing program reportedly reduced average daily reported misses by 20.4% from Q3 to Q4 2025, with a further two-thirds decline in Q1 2026. ## The Blind Spot in Reactive Defense - Traditional systems improve mainly after users report messages that were incorrectly classified as clean. - This feedback is valuable but inherently delayed: it reveals attacks that already succeeded. - The authors compare this problem to Abraham Wald’s World War II aircraft analysis: - Engineers studied bullet holes on returning planes. - Wald identified the missing data—the damage on planes that never returned. - Email security faces the same challenge because undetected threats are largely invisible. ## Mapping Threats with LLMs - LLMs can interpret context, intent, urgency, deception, and other nuanced characteristics in natural-language emails. - Cloudflare processes millions of unwanted messages daily, making manual classification and detailed threat mapping impractical. - LLM-generated categories expose emerging patterns and persistent trends, including: - `PrizeNotification` - `SalesOutreach` - These tags give analysts near-real-time, high-fidelity signals and reduce the need for manual investigation. - The resulting intelligence helps Cloudflare create or retrain targeted machine-learning models before threats become widely visible through customer reports. ## Detecting Sales Outreach Phishing - Sales Outreach phishing imitates legitimate B2B communication, using offers, special deals, or transactional requests to encourage malicious clicks or credential disclosure. - After identifying it as a major threat category, Cloudflare used LLM tags to build a continuously growing corpus of relevant messages. - Training data was grouped by linguistic and structural traits such as: - Persuasive framing - Manufactured urgency - Transactional language - Subtle social proof - Feature extraction focused on sentiment and intent rather than static indicators. - A specialized sentiment-analysis model was trained for Sales Outreach behavior instead of overloading a general phishing classifier. ## From Classification to Enforcement - The specialized model produces a risk score based on how closely an email matches known Sales Outreach patterns. - That score is combined with other signals, including: - Sender reputation - Link behavior - Historical context - Messages can then be allowed, quarantined, or blocked. - LLMs serve as the discovery layer, identifying new language variants, while the specialized model provides fast, scalable enforcement. - Newly detected examples continuously feed back into the pipeline as attackers change their tactics. ## Reported Results - Cloudflare says the proactive approach reduced customer-reported Sales Outreach misses. - Average daily submissions fell from 965 in Q3 2025 to 769 in Q4 2025. - This represented a 20.4% quarterly reduction. - The company reports that average daily submissions decreased by another two-thirds in Q1 2026. - Fewer misses mean less analyst work, fewer interruptions for users, and fewer opportunities for phishing messages to reach inboxes. Cloudflare’s approach recommends combining broad LLM-based threat discovery with narrowly focused detection models. This creates a proactive feedback loop that can identify and address emerging phishing techniques before relying on large volumes of user-reported failures.

Read original(opens in new tab)
cloudflare3 min readCurated summary

See risk, fix risk: introducing Remediation in Cloudflare CASB

Cloudflare CASB now lets customers remediate risky SaaS file-sharing directly from the Cloudflare One dashboard, rather than merely identifying problems. The initial release targets Microsoft 365 and Google Workspace, removing public, organization-wide, or external sharing without deleting files or changing ownership. Cloudflare concludes that durable, workflow-based execution makes remediation scalable, observable, and easier to operate. ## CASB as a Centralized SaaS Risk View - CASB connects to services including Microsoft 365, Google Workspace, Slack, Salesforce, Box, GitHub, Jira, and Confluence through APIs. - It provides: - A consolidated view of misconfigurations, overshared files, and risky access. - Continuous scanning as users collaborate and adopt new tools. - Searchable and exportable findings for triage and reporting. - Previously, fixing findings required using each application’s admin interface or submitting tickets to application owners. ## File-Sharing Remediation - The new **Remove sharing** action can address: - Public links that allow anyone to view or edit files. - Company-wide sharing when only a few users need access. - Sharing with external domains or personal accounts. - Any of these risks involving files that match a DLP profile, such as customer records, credentials, or financial data. - Remediation removes the risky sharing configuration only: - Files are not deleted. - Ownership is not changed. - Progress and outcomes are tracked in CASB, while actions are recorded in Cloudflare One Admin logs and can be exported to a SIEM. ## Microsoft 365 and Google Workspace - The initial integrations focus on business-critical documents stored in: - OneDrive and SharePoint. - Google Drive, including Docs, Sheets, and Slides. - Common examples include temporary public editing links, company-wide documents forgotten after an event, and sensitive spreadsheets shared with contractors’ personal accounts. - Teams can now resolve findings directly in CASB instead of exporting CSVs and relying on application owners to make changes. ## Durable Remediation Architecture - Cloudflare designed the system for speed, resilience, and ease of use using: - Workers - Workflows - Queues - Workers KV - Secrets Store - Hyperdrive - The process is: - An API call sends a remediation job to a Worker. - The Worker places it on a Queue. - A second Worker starts a Workflow. - Credentials are securely provided through Workers KV and Secrets Store. - The Workflow gathers information and calls third-party APIs. - Hyperdrive records the final result. - Workflows’ native retries handle vendor API rate limits such as HTTP 429 responses, while built-in step logging shows retry activity. - Load testing and early customer usage produced a median completion time of 48 seconds and a p90 of 72 seconds. ## Planned Expansion - Cloudflare plans to add: - Quarantine actions that move or isolate high-risk files. - Custom Webhooks for ticketing, chat notifications, and external automation. - Carefully scoped autoremediation policies. - Custom CASB findings based on organization-specific patterns, data types, or access conditions. Organizations using Microsoft 365 or Google Workspace can use CASB Remediation to turn detected sharing risks into tracked, auditable fixes. The planned quarantine, webhook, and automated-policy features could further position CASB as an active security control plane rather than a passive reporting tool.

Read original(opens in new tab)
cloudflare3 min readCurated summary

Beyond the blank slate: how Cloudflare accelerates your Zero Trust journey

Cloudflare argues that a Zero Trust platform’s blank-slate flexibility can become an adoption barrier when customers must configure countless policies and security controls themselves. Project Helix addresses this by codifying Cloudflare experts’ best practices into automated Terraform templates, delivered through a simple web interface. The result is a faster, more consistent way to deploy a secure Cloudflare One baseline within minutes rather than hours. ## The complexity barrier of a blank slate - Cloudflare One offers extensive capabilities across DNS protection, network security, Secure Web Gateway, TLS inspection, DLP, antivirus scanning, and Zero Trust Access. - Tenants are generally provisioned with minimal defaults because enabling advanced protections immediately could disrupt existing traffic and applications. - Customers must therefore manually activate numerous settings, policies, and routing changes. - Some features require coordinated configuration: - Enabling private application access by hostname requires both a platform setting and a specific CGNAT range in the client’s split-tunnel configuration. - Traffic from applications such as Zoom may need to bypass Cloudflare and go directly to the Internet. - Captive portal exceptions can be important for users connecting from hotels, airlines, and other public networks. - Initial setup guides and scenario-based wizards helped, but customers using multiple scenarios still had to complete each workflow separately. ## Project Helix: Turning expertise into automation - Cloudflare gathered deployment knowledge from Solutions Engineers, Professional Services Engineers, and partners. - The team documented desired proof-of-concept and production outcomes, including: - Baseline DNS, network, and HTTP security protections - TLS inspection - QUIC and HTTP/3 security - Remote Browser Isolation for risky categories such as newly registered domains - Visibility and controls for AI applications - Tenant Control policies restricting users to approved SaaS instances - Helix packages these recommendations in a repeatable, codified format that can be applied with a button click. - This avoids relying on individually maintained documentation or the memory of experienced administrators. ## Problems with manual deployment - Configuring the complete baseline on a new tenant can take several hours. - Documentation must be continually updated as Cloudflare features and best practices change. - Repetitive manual steps increase the risk of configuration errors and inconsistent deployments. - Manual work also makes it harder for less experienced users to benefit from Cloudflare One’s full capabilities. ## Terraform, Workers, and ephemeral provisioning - Helix uses scalable Terraform templates to define Cloudflare One settings, configuration snippets, and security policies. - A web interface hosted on Cloudflare Workers accepts basic customer inputs and executes the Terraform configuration. - Cloudflare Containers support the provisioning workflow. - The process uses no persistent storage, reducing risks associated with retaining Terraform logs or authentication tokens. - Within minutes, users can deploy an advanced baseline configuration and review additional recommended policies to enable. ## Layered security configuration - Helix begins with DNS security policies that: - Support corporate DNS for Zero Trust - Block malicious or questionable categories before they resolve - It then applies network policies to protect users across ports and protocols. - The broader configuration also incorporates traffic-routing exceptions, application controls, and user-experience improvements such as captive portal handling. Project Helix’s practical recommendation is to replace manual, blank-slate configuration with expert-designed, automated baselines. This lets customers adopt Cloudflare One’s advanced protections quickly while preserving the flexibility to customize policies for their own environments.

Read original(opens in new tab)
cloudflare3 min readCurated summary

The truly programmable SASE platform

Cloudflare argues that true SASE programmability goes beyond APIs, Terraform, webhooks, and alerts. It means intercepting security events, enriching them with external context, and making real-time decisions through custom logic. By running Cloudflare One and its Developer Platform on the same global edge network, Cloudflare aims to let customers apply programmable, low-latency policies without stitching together separate infrastructure. ## What “Programmability” Means - Traditional programmability supports configuration and automation, such as sending Slack alerts when policies trigger. - True programmability allows security systems to: - Inspect an event before access is granted. - Query external systems for additional context. - Make or change an access decision in real time. - Example: a request to a regulated application could be checked against a learning management system to confirm that the user’s compliance training is current. Expired or missing certification would result in denial and redirection to training. ## Cloudflare’s Programmable SASE Architecture - Cloudflare’s network spans more than 330 cities and reaches approximately 95% of Internet-connected users within 50 milliseconds. - Cloudflare One and the Developer Platform run on the same infrastructure and use shared network primitives. - This enables Workers to extend inline services such as Access without requiring separate cloud infrastructure. - Customers can: - Call external risk APIs. - Add dynamic request headers. - Validate browser attributes. - Route traffic according to custom business logic. - Running custom logic at the edge reduces latency and avoids the operational overhead of webhook-based integrations and disconnected systems. ## Custom Actions in Security Policies - Conventional gateways generally limit policy outcomes to actions such as allow, block, isolate, or quarantine. - Cloudflare is expanding policies to support managed and custom actions. - Potential uses include: - Injecting headers based on user identity claims. - Obtaining real-time verdicts from external risk engines. - Restricting access based on location or working hours. - Updating risk lists based on scheduled analysis of user activity. - Custom actions can invoke a Worker when a Gateway HTTP policy matches, giving the code access to request context and allowing decisions in milliseconds. - Managed actions will offer templates for common use cases such as IT service management, redirects, and compliance workflows. ## Automated Device Session Revocation - One customer needed periodic re-authentication for Cloudflare One Client users, similar to traditional VPN session expiration. - Cloudflare’s built-in session controls were application-specific rather than global and time-based. - The customer implemented a scheduled Worker that: - Queries the Cloudflare Devices API. - Handles cursor-based pagination to retrieve registrations. - Calculates how long each device has been inactive. - Deletes registrations exceeding a configured inactivity threshold. - Forces affected users to authenticate again through their identity provider. - The example also supports environment-based configuration and a dry-run mode for testing before revocations are applied. Cloudflare’s recommendation is to treat SASE policies as programmable decision points rather than fixed allow-or-block rules. Combining Cloudflare One with edge Workers can provide faster, more context-aware security automation while reducing integration complexity.

Read original(opens in new tab)
cloudflare3 min readCurated summary

Modernizing with agile SASE: a Cloudflare One blog takeover

The post argues that changing work patterns, AI agents, and Internet-based perimeters require organizations to move beyond fragmented legacy networks toward “agile SASE.” It presents Cloudflare One as a composable platform that combines networking and security on a global connectivity cloud, using single-pass processing to avoid service-chaining bottlenecks. Cloudflare positions this architecture as a faster path to modernization, beginning with focused use cases rather than a large-scale “big bang” migration. ## The Case for Agile SASE - Hybrid work and AI-driven traffic are making traditional corporate perimeters and office-based networks obsolete. - Legacy firewalls, VPN concentrators, and hardware appliances create a “fragmentation penalty.” - Technical debt accumulates through: - Conflicting firewall rules - Manual patching - Aging hardware - Infrastructure unable to handle AI-scale traffic - First-generation SASE platforms often shifted fragmentation from physical hardware into isolated cloud and operational silos. - The resulting problem is not a shortage of security data, but difficulty enforcing consistent policies across a borderless enterprise. ## Cloudflare One’s Single-Pass Architecture - Cloudflare describes zero trust as the security model and Cloudflare One as the platform for implementing it. - The platform converges networking and security through a global connectivity cloud spanning more than 300 cities. - Security checks can run simultaneously on every server rather than processing traffic sequentially through separate services. - This avoids service chaining, which can introduce latency and operational complexity. - Cloudflare frames the result as a programmable, composable platform rather than a collection of acquired or loosely connected tools. ## Five Themes for Network Modernization The company’s planned technical series focuses on: - **A new network standard:** Building a programmable, future-ready Internet foundation. - **Identity beyond passwords:** Combining human and device verification instead of relying only on credentials. - **Signal over noise:** Using AI to convert large volumes of security data into actionable guidance. - **The autonomous edge:** Improving performance and reducing friction as part of the security strategy. - **A unified vision:** Showing how enterprises and partners can standardize on Cloudflare One at scale. ## Programmability and Developer Integration - Cloudflare One runs alongside Cloudflare Workers, allowing teams to write code that responds to security events in real time. - This extends policy enforcement beyond simple allow/block decisions. - Organizations can automate more sophisticated security and operational workflows. - Cloudflare argues that this flexibility helps technology teams support faster business growth while improving protection. ## Practical Starting Points The post recommends beginning with focused modernization projects: - **Remote access:** Replace maintenance-heavy VPNs with clientless access and faster zero trust adoption. - **Email protection:** Detect phishing, Business Email Compromise, and related multi-channel threats with AI-powered controls. - **DNS filtering:** Block malicious websites for hybrid workers using DNS protection based on the 1.1.1.1 resolver. - **AI governance:** Identify shadow AI usage and control how organizational data enters generative and agentic AI systems. - **Branch networking:** Treat offices and coffee-shop workspaces as remote sites, reducing dependence on dedicated hardware. Organizations evaluating SASE should favor platforms that provide consistent policy enforcement, programmable controls, and incremental adoption. Cloudflare’s recommended entry point is to start with a specific need—such as VPN replacement or AI governance—and expand toward a unified connectivity and security architecture.

Read original(opens in new tab)
cloudflare3 min readCurated summary

Toxic combinations: when small signals add up to a security incident

Small security signals can become dangerous when combined: automated bots probing sensitive paths, unusual request behavior, and weak authentication or configuration. Cloudflare argues that analyzing these signals together—rather than judging each request independently—can reveal likely attack campaigns before compromise. Although toxic combinations are uncommon outside WordPress, the affected hosts may be highly exposed. ## What “Toxic Combinations” Mean - A toxic combination occurs when attackers compound several minor weaknesses into a viable breach. - Relevant signals include: - Bot activity and automated scanning - Sensitive paths such as `/admin`, `/debug`, `/metrics`, search, and payment endpoints - Anomalies such as unexpected HTTP status codes, geographic jumps, identity mismatches, high identifier churn, distributed rate-limit evasion, and traffic spikes - Missing session cookies or authorization headers and predictable identifiers - Traditional WAF, bot, and API defenses often assess the risk of individual requests. - Cloudflare’s approach examines the broader context across multiple requests, hosts, and paths. ## Measuring Exposure - Cloudflare analyzed a 24-hour sample of application-security data. - About 11% of analyzed hosts appeared susceptible to toxic combinations, largely because of vulnerable WordPress sites. - Excluding WordPress, only about 0.25% of hosts showed signs of exploitable combinations. - The analysis separated attacks into three stages: - **Hosts probed:** systems receiving requests for sensitive paths such as `/wp-admin` - **Hosts matching a toxic combination:** systems meeting the full detection criteria - **Reachable hosts:** systems that successfully responded to an exploit attempt - A `200 OK` response alone is not proof of exposure. Cloudflare recommends validating results against authentication requirements, redirects, and origin configurations to eliminate false positives. ## Probing Administrative Endpoints - Automated scanners targeted common administrative interfaces, including: - WordPress `/wp-admin` pages - Database management tools - Server dashboards - Cloudflare’s Log Explorer query groups successful requests by host, filters for likely bot traffic using a low bot score, and searches for configurable path patterns. - The query also excludes hosts represented only by raw IP addresses unless that filter is removed. ## Why Public Admin Panels Are Dangerous - Exposed administrative panels enable brute-force login attempts. - A successful compromise can allow attackers to: - Identify software and versions such as WordPress or Tomcat - Search for relevant CVEs and launch targeted exploits - Add the compromised host to a botnet that scans other websites - A sensitive endpoint returning successfully should therefore be tested for actual reachability and authentication weakness, not treated as conclusive evidence on its own. ## Practical Recommendation Monitor combinations of bot activity, sensitive-path access, anomalous behavior, and missing authentication signals. Investigate confirmed reachable endpoints, restrict or protect administrative interfaces, remove debug exposure, and validate detection queries against real application behavior to distinguish exploitable systems from false positives.

Read original(opens in new tab)
cloudflare3 min readCurated summary

Bringing more transparency to post-quantum usage, encrypted messaging, and routing security

Cloudflare Radar is expanding its security coverage with new visibility into post-quantum encryption, Key Transparency for encrypted messaging, and ASPA deployment for routing security. The updates extend monitoring from user-to-Cloudflare connections to origin servers, provide tools for testing individual websites, and expose verification data that users can independently inspect. Together, they aim to make emerging Internet security technologies more measurable and transparent. ## Measuring Origin Post-Quantum Support - Cloudflare has tracked browser and client support for post-quantum encryption since 2024, rising from below 3% to more than 60% by February 2026. - The monitored algorithm, `X25519MLKEM768`, combines: - Classical X25519 key exchange - NIST-standardized ML-KEM post-quantum cryptography - Radar now measures whether customer origin servers support the same hybrid key exchange. - Cloudflare’s automated TLS scanner probes TLS 1.3-compatible origins and aggregates results daily. - The data measures algorithm support, not necessarily algorithm preference; a server’s TLS configuration can still choose a classical exchange even when post-quantum support exists. - Approximately 10% of origins currently support post-quantum-preferred key agreement, up from less than 1% in early 2025. - Adoption has accelerated as newer versions of OpenSSL, GnuTLS, and Go enabled hybrid post-quantum support by default. - Origin readiness data is available through Radar, Data Explorer, and the Radar API. ## Website Post-Quantum Compatibility Testing - Radar now includes a tool for testing whether a publicly accessible hostname supports post-quantum encryption. - Users can enter a hostname and optionally specify a port, with HTTPS port 443 used by default. - Results show: - Whether the connection is post-quantum secure - The negotiated TLS key exchange algorithm - The tool uses Cloudflare Containers to run a Go-based TLS scanner. - Because Workers cannot inspect the underlying TLS handshake, the container uses Go’s `crypto/tls` package to perform the connection and report the negotiated algorithm. - Cloudflare has consolidated its client- and origin-facing post-quantum measurements into a dedicated Radar section. ## Key Transparency for Encrypted Messaging - End-to-end encrypted services such as WhatsApp and Signal depend on correct public-key distribution. - If a messaging provider’s key database were compromised, an attacker could replace a contact’s public key and potentially intercept messages without detection. - Key Transparency mitigates this risk through an auditable, append-only public-key log. - The model is comparable to Certificate Transparency: - Messaging services publish users’ public keys to a transparency log. - Independent auditors verify that the log is correctly built and remains consistent. - Radar now provides a public dashboard for Key Transparency Logs used by E2EE messaging services. - The dashboard shows when each log was last signed and verified by Cloudflare’s Auditor. - Users can also access an API to independently validate the Auditor’s proofs. ## Routing Security and ASPA - Radar’s routing security coverage now includes global, country-level, and network-level information about ASPA deployment. - ASPA is an emerging standard intended to help detect and prevent BGP route leaks. - The new data extends Radar’s broader monitoring of Internet routing security. Cloudflare’s additions make post-quantum readiness, encrypted-message key integrity, and routing protection easier to measure and verify. Organizations can use the Radar dashboards, API, and hostname testing tool to assess their own migration and security posture.

Read original(opens in new tab)
cloudflare3 min readCurated summary

ASPA: making Internet routing more secure

ASPA (Autonomous System Provider Authorization) extends RPKI-based routing security from verifying a route’s destination to validating the path it takes. By publishing cryptographically signed lists of authorized providers, networks can detect BGP route leaks and some forged-origin hijacks. Cloudflare Radar now tracks ASPA adoption and records across the five Regional Internet Registries. ## From Origin Validation to Path Validation - RPKI uses Route Origin Authorizations (ROAs) to verify that an Autonomous System (AS) is authorized to announce specific IP prefixes. - ROAs protect against origin hijacks, where an attacker falsely claims ownership of someone else’s address space. - ASPA complements ROAs by validating the AS_PATH—the sequence of networks through which a route propagates. - Each AS publishes its authorized upstream providers, allowing other networks to check whether the observed path follows approved relationships. ## Detecting Route Leaks - Normal Internet routing generally follows a “valley-free” pattern: - Traffic moves upward from a customer through providers. - It may cross a peering connection near the top. - It then moves downward through providers toward the destination. - A route leak creates a “valley,” such as traffic traveling down to a customer and then back up to another provider. - ASPA evaluates the path from both directions: - The “up-ramp” is checked from the route origin toward its providers. - The “down-ramp” is checked backward from the destination. - A path is valid when both authorized chains meet. If they leave a gap, the route is considered ASPA Invalid, indicating a likely leak or unauthorized propagation. ## Example of ASPA Validation - In the example, AS65539 receives a route from customer AS65538. - AS65538 improperly propagates traffic received from provider AS65537 toward another provider, acting as a bridge between providers. - The upstream validation chain ends at AS65537, while the downstream chain ends at AS65538. - Because the two chains do not connect, ASPA identifies the route as invalid. ## Protection Against Forged-Origin Hijacks - ASPA can detect attacks in which the legitimate origin AS is retained but the attacker fabricates the path leading to it. - The victim’s signed provider list reveals that the attacker is not an authorized provider, allowing the route to be rejected. - ASPA is not universal protection: the article notes that a provider may still forge a path advertisement to its customer, a case the supplied text does not fully explain. ## Monitoring ASPA Adoption - Cloudflare Radar’s ASPA deployment monitoring feature shows adoption trends across all five RIRs. - It also lets users inspect ASPA records and changes for individual Autonomous Systems. ASPA provides an important second layer of routing security: ROAs verify where traffic should end, while ASPA helps verify how it gets there. Wider publication and validation of ASPA records should make route leaks and path manipulation easier to detect and prevent.

Read original(opens in new tab)
cloudflare3 min readCurated summary

We deserve a better streams API for JavaScript

Web Streams established a cross-runtime standard for handling streaming data, but their design reflects constraints from 2014–2016 rather than modern JavaScript practices. James M. Snell argues that the API’s reader, lock, and controller machinery creates unnecessary complexity and performance costs. He presents an alternative based on JavaScript language primitives that reportedly runs 2× to 120× faster across browsers and major runtimes. ## Historical Design Constraints - The WHATWG Streams Standard aimed to provide portable APIs for creating, composing, and consuming streams. - It was adopted by browsers, Cloudflare Workers, Node.js, Deno, Bun, and APIs such as `fetch()`. - The design predates JavaScript async iteration, which was standardized in ES2018. - Because `for await...of` did not yet exist, Web Streams introduced a separate reader/writer acquisition model. ## Excessive Ceremony for Basic Reads - Reading a stream to completion traditionally requires: - Calling `stream.getReader()`. - Repeatedly awaiting `reader.read()`. - Checking `{ value, done }` on every iteration. - Releasing the reader lock in a `finally` block. - These steps are API choices rather than inherent requirements of streaming. - Modern async iteration reduces the same operation to: ```js for await (const chunk of stream) { chunks.push(chunk); } ``` - However, async iteration was added after the original design, so it does not eliminate the underlying reader, lock, and controller complexity. - Advanced features such as BYOB reads still require developers to use the lower-level APIs. ## Problems with Manual Locking - Calling `getReader()` places an exclusive lock on the stream. - While locked, other code cannot read, pipe, or cancel the stream directly. - Forgetting `reader.releaseLock()` can permanently prevent later consumers from using the stream. - The `locked` property indicates that a lock exists, but not who owns it, why it exists, or whether the reader remains usable. - Internal operations such as piping also acquire locks, which can make stream behavior surprising. - Lock-release behavior with pending reads was historically unclear and varied between implementations before being clarified by the specification. - Async iterables improve the user experience by handling reader and lock management automatically, but the underlying model remains complex. ## Proposed Direction - The post argues that Web Streams’ limitations are fundamental design consequences, not isolated bugs easily fixed through incremental changes. - A better API should be built around modern JavaScript primitives, especially async iteration. - The author’s alternative reportedly achieves between 2× and 120× the performance of Web Streams across Cloudflare Workers, Node.js, Deno, Bun, and major browsers. - The claimed gains come from different architectural choices rather than narrowly optimized implementations. A more modern streams API should make common operations natural, avoid exposing fragile manual lock management, and use JavaScript’s native asynchronous iteration model from the start.

Read original(opens in new tab)
cloudflare3 min readCurated summary

The most-seen UI on the Internet? Redesigning Turnstile and Challenge Pages

Cloudflare redesigned Turnstile and Challenge Pages because these security interfaces are encountered billions of times daily and increasingly interrupt users as bot attacks grow. The redesign focused on reducing frustration through consistent information architecture, clearer language, better accessibility, and a deeper understanding of user journeys. The central conclusion is that security products must be designed not only to stop bots, but also to provide a humane, understandable experience for people at global scale. ## A Security Interface Seen Everywhere - Turnstile and Challenge Pages are served approximately **7.67 billion times per day**. - Their enormous reach creates a responsibility to support users across: - Different languages and cultures - A wide range of technical abilities - Different ages and accessibility needs - Varying devices, network conditions, and environments - As bot attacks increase, users are encountering verification challenges more frequently: - **2023:** 2.14 billion daily checks - **2024:** 3 billion - **2025:** 5.35 billion - This represented an average year-over-year increase of **58.1%**, making usability increasingly important. ## Auditing the Existing Experience Cloudflare reviewed every state, error message, and interaction in both products. - The audit found no consistent approach to error handling. - Some messages were overly technical and verbose, such as explanations involving incorrect device clocks or cached challenge pages. - Other messages were too vague, such as simply saying “Timed out.” - Layouts, visual hierarchy, and tone varied substantially between states. - User feedback mechanisms used ambiguous options like: - “The widget sometimes fails” - “The widget fails all the time” - These choices required frustrated users to interpret unclear distinctions and produced less useful feedback. - Challenge Pages also contained confusing states, technical jargon, and insufficient guidance about what users should do next. ## Mapping the Complete User Journey The team mapped both successful and unsuccessful paths through the verification experience. - The process covered initial encounters, errors, retries, and escalating frustration. - Designers collaborated with engineers who understood technical edge cases and product specialists who tracked user sentiment. - The team emphasized that technical sophistication does not automatically produce clear communication. - Interfaces needed to work for people with different: - Physical and mental capabilities - Cultural backgrounds - Ages - Levels of technical knowledge - At Cloudflare’s scale, unusual cases are common enough that they cannot be treated as negligible edge cases. ## Establishing a Unified Information Architecture Cloudflare applied the principle from *Don’t Make Me Think*: every moment users spend interpreting an interface creates friction, especially when they are already frustrated. - Previously, Turnstile and Challenge Pages placed information differently across states. - Users had to relearn where to find explanations, actions, and documentation links. - The redesign introduced one shared structure for both products. - Each experience would use: - The same visual hierarchy - Consistent placement for explanatory text - Consistent locations for actions - Consistent placement of documentation links - This approach limited some creative design options, but the team viewed those constraints as useful for improving clarity and consistency. Cloudflare’s redesign treats verification as a human-facing product rather than merely a security mechanism. A consistent structure, clearer messaging, and attention to accessibility can reduce the unnecessary frustration caused by challenges while preserving their protective purpose.

Read original(opens in new tab)
cloudflare4 min readCurated summary

How we rebuilt Next.js with AI in one week

Vinext is an experimental, Vite-based reimplementation of Next.js built in one week by one engineer and an AI model. It preserves much of Next.js’s API and project structure while avoiding the fragile process of adapting Next.js/Turbopack output for serverless platforms. Early results suggest builds can be up to 4× faster, client bundles up to 57% smaller, and Cloudflare Workers deployment can be handled with a single command. ## The Deployment Challenges of Next.js - Next.js provides an excellent developer experience but relies on a bespoke build and deployment toolchain. - Deploying to platforms such as Cloudflare, Netlify, or AWS Lambda requires reshaping Next.js output. - OpenNext addresses this problem but must reverse-engineer build artifacts, making it vulnerable to changes between Next.js versions. - Next.js’s planned adapters API improves deployment support but does not solve the underlying Turbopack dependency. - `next dev` runs only in Node.js, making it difficult to develop against platform-specific APIs such as Durable Objects, KV, and AI bindings. ## Vinext’s Vite-Based Architecture - Vinext reimplements the Next.js API surface directly on Vite rather than wrapping or adapting Next.js output. - Existing `app/`, `pages/`, and `next.config.js` files can be reused. - Developers install it with `npm install vinext` and replace `next` scripts with `vinext`. - It supports: - Routing - Server-side rendering - React Server Components - Server actions - Caching - Middleware - Hot module replacement - Vite’s Environment API allows the output to run across different platforms. ## Early Performance Results - Benchmarks compared vinext with Next.js 16 using the same 33-route App Router application. - Type checking and ESLint were disabled for Next.js to focus on compilation and bundling. - Static pre-rendering was disabled with `force-dynamic` for a fairer comparison. - Early results showed: - Production builds up to 4× faster - Gzipped client bundles up to 57% smaller - The results measure build performance, not serving performance, and come from a single test application. - The authors describe the figures as directional because both vinext and its supporting tools are still evolving. - Vite’s architecture and the upcoming Rust-based Rolldown bundler are identified as major sources of potential performance gains. ## Cloudflare Workers Deployment - `vinext deploy` builds the application, generates Worker configuration, and deploys it automatically. - Both the App Router and Pages Router are supported. - Applications retain client-side hydration, interactive components, navigation, and React state. - A Cloudflare KV cache handler provides Incremental Static Regeneration: ```ts import { KVCacheHandler } from "vinext/cloudflare"; import { setCacheHandler } from "next/cache"; setCacheHandler(new KVCacheHandler(env.MY_KV_NAMESPACE)); ``` - The cache layer is pluggable, allowing alternatives such as R2 or future Cache API improvements. - Because development and deployment can both run in `workerd`, applications can use Durable Objects, AI bindings, and other Cloudflare services without Node.js compatibility workarounds. ## Broader Ecosystem Potential - Although Cloudflare Workers is the initial target, roughly 95% of vinext is platform-independent Vite code. - Its routing, SSR pipeline, module shims, and React Server Components integration are not Cloudflare-specific. - A proof of concept reportedly ran on Vercel in under 30 minutes. - The project is open source and invites other hosting providers to contribute deployment targets. ## Experimental Status - Vinext is less than a week old and has not been tested under meaningful production-scale traffic. - The authors recommend caution before adopting it for critical applications. - Its test suite already includes more than 1,700 Vitest tests and 380 Playwright end-to-end tests, including tests ported from Next.js and OpenNext. - The project reportedly cost approximately $1,100 in AI-token usage to build. Vinext is best viewed as a promising experimental alternative rather than a drop-in replacement ready for every production workload. Teams interested in platform-native development and faster Vite-based builds can evaluate it carefully, while waiting for broader compatibility and real-world validation.

Read original(opens in new tab)
cloudflare3 min readCurated summary

Cloudflare One is the first SASE offering modern post-quantum encryption across the full platform

Cloudflare says Cloudflare One is now the first SASE platform to provide standards-compliant post-quantum hybrid ML-KEM encryption across Secure Web Gateway, Zero Trust, and WAN connectivity. The update extends protection to Cloudflare IPsec and Cloudflare One Appliance, addressing both current “harvest now, decrypt later” attacks and future quantum threats. The appliance support is generally available in version 2026.2.0, while Cloudflare IPsec is in closed beta. ## Post-Quantum Cryptography Is an Immediate Concern - NIST has set 2030 as the target for phasing out RSA and elliptic-curve cryptography in favor of post-quantum algorithms. - Cryptographic migrations can take decades, as demonstrated by vulnerabilities involving deprecated algorithms such as MD5. - Organizations face “harvest now, decrypt later” attacks, in which encrypted traffic is collected today for future decryption. - Cloudflare argues that built-in crypto agility makes it easier for enterprises to upgrade algorithms without redesigning remote-access and WAN infrastructure. ## Two Required Cryptographic Migrations - **Key establishment:** ML-KEM is becoming the standard post-quantum mechanism for establishing shared encryption keys. - Cloudflare uses hybrid ML-KEM, combining ML-KEM with classical ECDHE. - This approach protects against harvested traffic, requires no specialized hardware like quantum key distribution, and has limited performance impact. - More than 60% of human-generated TLS traffic reaching Cloudflare is already protected by hybrid ML-KEM. - **Digital signatures:** Post-quantum signatures protect against server impersonation but are larger than current ECC signatures. - Their migration is considered less urgent because they primarily defend against active quantum adversaries, which do not yet exist. - Cloudflare’s current IPsec work therefore focuses on post-quantum key establishment rather than signatures. ## Post-Quantum Protection for Cloudflare IPsec - Cloudflare upgraded its IPsec products to support hybrid ML-KEM within IKEv2. - Cloudflare IPsec creates encrypted tunnels from customer networks to Cloudflare’s global network. - IP Anycast routes tunnels to the nearest data center and automatically redirects traffic if a location becomes unavailable. - The service supports site-to-site WAN connectivity as well as outbound Internet connections. - Cloudflare One Appliance, which establishes Cloudflare IPsec connections, supports the upgrade starting with version 2026.2.0. - The Cloudflare IPsec upgrade remains in closed beta. ## Limitations of Earlier IPsec Approaches - IPsec has historically evolved differently from TLS because it is commonly used between devices from the same vendor, making interoperability less central. - RFC 8784 proposed combining long-lived pre-shared keys with Diffie-Hellman exchange. - While this can help protect against harvest-now-decrypt-later attacks, it does not provide forward secrecy against quantum attackers. - Quantum key distribution is also impractical for many enterprise environments because it requires specialized physical connectivity. Cloudflare’s recommendation is to begin post-quantum migration now, starting with hybrid ML-KEM for key establishment across Internet access, Zero Trust, and WAN connections.

Read original(opens in new tab)
cloudflare3 min readCurated summary

Cloudflare outage on February 20, 2026

Cloudflare suffered a 6-hour, 7-minute outage on February 20, 2026, after a software change unintentionally withdrew Internet routes for some Bring Your Own IP (BYOIP) customers. The incident was not related to a cyberattack; a buggy automated cleanup task altered customer prefix and service configurations. Cloudflare reverted the change, restored affected prefixes, and is revising its Addressing API workflows to reduce production risk. ## Customer Impact - Approximately 1,100 of Cloudflare’s 6,500 advertised prefixes were withdrawn between 17:56 and 18:46 UTC. - This affected about 25% of the 4,306 BYOIP prefixes advertised globally. - Impacted applications became unreachable from the Internet and experienced connection failures and timeouts. - Customers initially encountered BGP Path Hunting, where networks repeatedly searched for a route until connections timed out. - The `one.one.one.one` website returned HTTP 403 errors and an “Edge IP Restricted” message. - DNS resolution through the 1.1.1.1 resolver, including DNS over HTTPS, was not affected. - The incident did not affect every BYOIP customer because the configuration change was applied incrementally and was reverted before reaching everyone. ## Recovery Efforts - Engineers detected the issue through failures involving `one.one.one.one` and reverted the change. - Cloudflare published dashboard guidance at 19:19 UTC, allowing many customers to re-advertise their prefixes themselves. - Around 800 prefixes were restored by approximately 20:20 UTC. - About 300 prefixes could not be restored through the dashboard because their service configurations had been removed from edge servers. - Engineers manually restored those remaining prefixes at 23:03 UTC. - Some customers continued to experience latency and failures while addressing configuration state propagated back to the edge. ## The Addressing API - Cloudflare’s Addressing API is the authoritative dataset for IP addresses present on its network. - Changes to the API drive workflows that propagate address and routing updates across Cloudflare’s edge. - The normal process is: - Customers request advertisement or withdrawal through the Addressing API or BGP Control. - The API instructs machines to change prefix advertisements. - Routers update BGP after enough machines receive the change. - Customers bind Cloudflare products to their BYOIP ranges. - Because the API is closely connected to production systems, manual changes are risky. - Cloudflare’s “Code Orange: Fail Small” initiative aims to replace manual Addressing API operations with safer, automated, health-checked workflows. ## Root Cause: Faulty BYOIP Cleanup Automation - The failed change automated the removal of prefixes from BYOIP, a task that had previously been performed manually. - A recurring cleanup sub-task searched for BYOIP prefixes marked for deletion and removed them. - The cleanup task issued the API request: ```go /v1/prefixes?pending_delete ``` - The request contained a bug in how the API query was interpreted. - As a result, the cleanup process unintentionally withdrew customer prefixes and removed related service configurations from some edge servers. - The incident lasted much longer than the initial withdrawal because restoring both advertisements and edge configuration state required extensive automated and manual recovery. Cloudflare’s main corrective direction is to make Addressing API changes safer through incremental, health-mediated deployment, stronger safeguards around automated deletion, and elimination of risky manual production workflows.

Read original(opens in new tab)
cloudflare3 min readCurated summary

Code Mode: give agents an entire API in 1,000 tokens

Code Mode addresses a central MCP problem: giving agents broad tool access without overwhelming their context windows. Instead of exposing thousands of individually described tools, it provides a typed SDK and lets agents write sandboxed JavaScript to search specifications and execute API calls. Cloudflare’s new MCP server applies this approach to its entire API using only `search()` and `execute()`, reducing context usage by 99.9% to roughly 1,000 tokens. ## The Context-Window Problem - MCP makes external tools available to AI agents, but each tool’s description consumes model context. - Large APIs can require enormous token budgets merely to describe their endpoints. - A conventional MCP server for the Cloudflare API would consume approximately 1.17 million tokens. - This can exceed the context window of even advanced foundation models. ## Code Mode as a Compact API Interface - Agents write code against a typed SDK rather than selecting from thousands of separate tools. - Generated code serves as a compact, composable plan. - Agents can: - Explore available operations. - Chain multiple API calls. - Handle pagination and errors. - Return only the data needed for the task. - The tool footprint remains fixed as the underlying API grows. ## Cloudflare’s Two-Tool MCP Server - The server exposes only: - `search()` — searches the Cloudflare OpenAPI specification. - `execute()` — runs JavaScript against the Cloudflare API. - The full OpenAPI specification stays outside the model context. - `$refs` are pre-resolved, allowing agents to inspect endpoint metadata directly through code. - Agents can filter endpoints by product, path, tags, or other metadata. ## Sandboxed Execution - Both tools execute code inside a Dynamic Worker isolate based on lightweight V8 sandboxes. - The environment has: - No filesystem access. - No environment variables exposed to generated code. - External fetches disabled by default. - Outbound requests can be explicitly enabled through controlled fetch handlers. ## Example: Finding DDoS Protection Endpoints - For a request to protect an origin from DDoS attacks, an agent can first consult documentation or skills. - It then uses `search()` to inspect the OpenAPI specification. - A JavaScript query can locate zone endpoints related to WAF and rulesets. - The search narrows more than 2,500 Cloudflare endpoints to relevant operations such as: - Listing and updating WAF packages and rules. - Listing and creating zone rulesets. - Reading and updating entry-point rulesets. - Creating and updating rules within a ruleset. - Once the relevant endpoints are identified, `execute()` can perform coordinated API requests in one sandboxed run. ## SDK Availability - Cloudflare is open-sourcing a Code Mode SDK as part of the Cloudflare Agents SDK. - The same pattern can be used to build more context-efficient MCP servers and AI agents. Code Mode is most useful for large, evolving APIs: expose a small, stable tool surface, let agents discover capabilities programmatically, and execute only the focused operations required for each task.

Read original(opens in new tab)
cloudflare3 min readCurated summary

Shedding old code with ecdysis: graceful restarts for Rust services at Cloudflare

Cloudflare’s open-source Rust library **ecdysis** enables zero-downtime restarts for high-volume network services. It preserves listening sockets and existing connections while a new process initializes, avoiding refused connections and dropped requests. After five years of production use, Cloudflare uses it to safely deploy fixes, security patches, and new features across its global infrastructure. ## Why Conventional Restarts Fail - Stopping the old process before starting the new one creates a period when no process is listening. - New clients receive `ECONNREFUSED`; even a 100 ms gap can drop hundreds of connections at a busy location. - Existing connections—including file uploads, video streams, WebSockets, and gRPC streams—are terminated when the old process exits. - `SO_REUSEPORT` allows multiple processes to bind the same port, but can orphan connections: - The kernel assigns an incoming `SYN` to one listening socket. - If that process exits before calling `accept()`, the queued connection is terminated. - This makes simply overlapping two independently bound processes unsafe for graceful upgrades. ## The ecdysis Restart Model ecdysis uses a process-forking approach pioneered by NGINX: - The parent calls `fork()` to create a child. - The child replaces itself with the new executable using `execve()`. - The child inherits the listening socket file descriptors through a named pipe shared with the parent. - The parent continues serving traffic while the child initializes. - Once the child signals readiness, the parent closes its copy of the listening socket and drains existing connections. - Both processes may briefly accept connections during the transition, but this is intentional and avoids coverage gaps. ## Crash Safety and Upgrade Requirements - The old process can fully shut down after the replacement is ready. - The new process receives time to initialize before taking over. - If initialization fails—for example, because of invalid configuration—the child exits while the parent continues serving normally. - Upgrades are serialized so that only one runs at a time, preventing cascading failures. - The unchanged listening socket ensures that new connections are not refused during the handoff. ## Rust and System Integration - ecdysis provides native Tokio stream wrappers for asynchronous Rust services. - Synchronous services can use it without an async runtime. - With the `systemd_notify` feature enabled, it integrates with systemd lifecycle notifications. - Configuring a service with `Type=notify-reload` allows systemd to track graceful upgrades correctly. Cloudflare’s approach demonstrates that graceful restarts require coordination between processes rather than simply starting a second server. Services needing reliable zero-downtime upgrades can use ecdysis to preserve connections, tolerate failed deployments, and safely roll out new Rust binaries.

Read original(opens in new tab)