cloudflareAug 11, 2026

Cloudflare DDoS Threat Report H1 2026: 1 Tbps attacks soar as DNS floods and geopolitical tensions drive a new wave (opens in new tab)

Cloudflare’s H1 2026 DDoS report shows a sharp rise in extreme attacks alongside a shift toward reflection and amplification techniques. Although most attacks remained brief and relatively small, 935 network-layer attacks exceeded 1 Tbps, making automated, always-on protection essential. Geopolitical events also strongly influenced which industries and countries were targeted. ## DDoS Activity Reached Record Levels - Cloudflare mitigated: - 23.2 million network-layer DDoS attacks - 29.64 trillion HTTP DDoS requests - This equals roughly 5,343 network-layer attacks per hour, or 128,000 per day. - April was the peak month, with 6.46 trillion requests and 165 petabytes of traffic. - Activity declined afterward, possibly following Operation PowerOFF, which targeted: - More than 75,000 DDoS-for-hire users - 53 domains - 25 search warrants - Four arrests across 21 countries ## Hyper-Volumetric Attacks Surge - Cloudflare mitigated 935 network-layer attacks exceeding 1 Tbps during H1. - Q2 alone accounted for 805 such attacks, more than six times Q1’s total. - Hyper-volumetric attacks are defined as exceeding: - 1 Tbps - 1 billion packets per second - 1 million requests per second ## Most Attacks Remained Short and Small - Despite record-breaking incidents: - 96.62% of network-layer attacks stayed below 500 Mbps. - 90.60% lasted less than 10 minutes. - Even “small” attacks can be damaging: - 100 Mbps can overwhelm an individual server or website. - 100 Gbps can disable most unprotected data centers. - Attacks above 1 Tbps can stress major infrastructure. - Attackers may combine high packet rates with lower bandwidth, or the reverse, to target different network weaknesses. - Some extreme attacks lasted only 35 seconds, leaving no realistic opportunity for manual intervention. - Short attacks can still cause prolonged routing instability, retransmissions, timeouts, and downstream outages. ## Media and Government Organizations Were Major Targets - Media, Production & Publishing was the most targeted industry in both quarters. - It represented 14.2% of mitigated HTTP DDoS requests. - Coverage of conflicts in Iran and Ukraine, along with the World Cup, contributed to sustained targeting. - Following Operation Epic Fury against Iran, government organizations experienced a major spike: - Researchers recorded 149 hacktivist DDoS claims against 110 organizations in 16 countries. - Nearly 47.8% of targeted organizations were in the government sector. - Government moved from 29th place in Q1 to 9th in Q2. ## China and Turkey Rose Among Targeted Locations - China was the most attacked location in Q2, receiving 22.4% of global HTTP DDoS requests. - The United States ranked second with 18.8%. - Turkey more than doubled its share of attack traffic and reached third place. - The increase coincided with security activity surrounding the 2026 Ankara NATO Summit. ## Brazil Became the Leading Attack Source - Brazil overtook the United States as the leading source country: - Brazil: 14.9% during H1, rising to 21.4% in Q2 - United States: 13.4% - Indonesia remained the third-largest source country. ## DNS and CLDAP Attacks Gained Ground - DNS-based attacks accounted for 34.3% of network-layer activity. - DNS Floods rose from 25.7% to 40.0% of network-layer attacks between Q1 and Q2. - DNS Floods directly overwhelm authoritative DNS servers with query volume. - DNS Amplification abuses open resolvers and spoofed source addresses to send larger responses to victims. - CLDAP Floods increased 580% quarter-over-quarter and became the third-most common vector in Q2. - These attacks exploit exposed LDAP-over-UDP endpoints, particularly those associated with Active Directory. - Overall, the attack landscape shifted from conventional botnet floods toward reflection and amplification methods. Cloudflare’s findings reinforce that DDoS defenses must be automated, distributed, and continuously active. Short attack durations and rapidly increasing traffic volumes make manual or on-demand mitigation too slow to protect services reliably.

network-securitycloudflarednsddos+3

cloudflareJun 3, 2026

Enforcing the First AS in BGP AS PATHs (opens in new tab)

Forged BGP AS_PATHs can let attackers impersonate legitimate networks, misdirect traffic, and conceal their true origin. Recent hijacks suggest some providers accept routes whose first AS does not match the customer peer that advertised them. Enforcing this “First AS” relationship check is a straightforward defense that complements RPKI and ASPA. ## Route Hijacks Involving Forged Paths - A reported hijack of Orange’s `90.98.0.0/15` included the path: `48237 1299 199524 270118 17072 41128`. - The path implied implausible commercial relationships: - `AS41128` was an unused Orange ASN. - `AS17072` was a Mexican ISP. - `AS270118` was a Mexican hosting provider. - `AS199524` was Gcore. - `AS1299` was Arelion, a Tier 1 provider. - Another hijack included Cloudflare’s ASN in the path: `199524 270118 17072 13335 36429`. - Cloudflare confirmed it had no adjacency with the unused `AS36429`, indicating that the path was fabricated. - The routes appeared to terminate behind Gcore rather than actually traversing the networks listed in the forged path. - The suspected attack sequence was: - Announce parked or unused prefixes. - Completely forge the AS_PATH without including the attacker’s ASN. - Send the route to Gcore. - Rely on the provider accepting the route without verifying its first AS. - Once accepted, the forged route could be propagated to upstream providers and peers. ## Why First AS Checking Matters - The BGP AS_PATH records the networks a route is expected to traverse. - It supports: - Route selection. - Loop prevention. - Operator routing policies. - BGP permits AS_PATH manipulation for legitimate purposes, such as AS prepending, but the same flexibility enables attackers to shorten or fabricate paths. - First AS enforcement verifies that the first AS in an advertised path matches the ASN of the customer or peer that sent the update. - Without this check, a customer can advertise a path that appears to originate from another network. ## Limits of RPKI and ASPA Alone - RPKI ROAs validate whether an origin ASN is authorized to announce a prefix. - ASPA validates provider-to-customer relationships. - However, an attacker may still bypass these mechanisms by: - Claiming an RPKI-valid origin ASN. - Including a legitimate ASPA provider in the forged path. - Omitting the attacker’s own ASN when the receiving provider does not enforce First AS. - In the example, a route forged to appear as though it originated from `AS64506` could remain RPKI-valid and attract traffic if `AS64502` accepted it without checking the peer’s first AS. ## Practical Recommendation Network operators should enable strict First AS checking on BGP sessions, alongside RPKI route-origin validation and ASPA deployment. These controls address different parts of the attack: RPKI validates the origin, ASPA checks authorized provider relationships, and First AS enforcement prevents a peer from presenting a path that does not begin with its own ASN.

network-securitybgpasparpki+2

cloudflareApr 10, 2026

500 Tbps of capacity: 16 years of scaling our global network (opens in new tab)

Cloudflare’s network has grown from a single transit provider in 2010 to more than 500 Tbps of provisioned external capacity across 330+ cities. The company argues that this scale is not merely about bandwidth: it enables security decisions, application execution, and routing validation to happen locally on every server. Its distributed architecture can absorb massive attacks automatically while supporting edge computing and emerging Internet protocols. ## From Transit Provider to Global Network - Cloudflare began with nLayer Communications as its first transit provider. - Expansion required city-by-city work: colocation contracts, fiber installation, hardware deployment, and Internet exchange peering. - In 2018, Cloudflare opened 31 cities in 24 days, despite logistical challenges such as customs delays and missing equipment. - The network now spans more than 330 cities and protects over 20% of the web. - The 500 Tbps figure represents provisioned interconnection capacity across transit, private peering, Internet exchanges, and Cloudflare Network Interconnect ports—not peak traffic. ## Turning the Network into a Security Layer - Cloudflare expanded from caching websites to securing employees and enterprise networks. - Its systems establish secure tunnels to private subnets and advertise customer IP space through BGP. - In 2025, Cloudflare mitigated a 31.4 Tbps DDoS attack lasting 35 seconds. - The attack was part of more than 5,000 attacks blocked that day, without paging an engineer. - Distributed automation allows attacks that once required nation-state resources to be handled in seconds. ## Packet-Level DDoS Mitigation - Incoming packets enter an XDP program chain in driver mode immediately after reaching the network interface card. - The `l4drop` eBPF program applies mitigation rules generated by `dosd`, Cloudflare’s denial-of-service daemon. - Each server identifies heavy traffic sources and shares the information across its colocation facility. - Mitigation rules spread globally through Quicksilver, Cloudflare’s distributed key-value store. - Only legitimate traffic reaches Unimog, the Layer 4 load balancer; Magic Transit traffic receives additional stateful inspection through `flowtrackd`. - The 31.4 Tbps attack was stopped at line rate without centralized scrubbing or human intervention. - Sufficient physical port capacity remains essential: software defenses cannot work if the network cannot first absorb the traffic. ## A Developer Platform at the Edge - Because Cloudflare already runs software on every server for packet filtering, it extended the same infrastructure to customer code through Workers. - Workers, KV, and Durable Objects run across Cloudflare’s global footprint rather than in a small number of cloud regions. - Workers Containers, introduced in 2025, support heavier workloads at the edge. - V8 isolates and custom filesystem layers reduce cold-start times. - Applications run on the same servers that discard malicious traffic before it reaches the network stack. ## Securing Routing with RPKI and ASPA - Cloudflare uses IPv6 and RPKI to reduce the risk of BGP hijacks. - It signs Route Origin Authorizations and rejects routes that fail Route Origin Validation, even when misconfigured networks become temporarily unreachable. - ASPA will extend protection by validating the network path, not just the organization authorized to originate a prefix. - The post compares RPKI to checking a destination passport and ASPA to verifying the entire flight manifest. - Cloudflare says 867,000 prefixes now have valid RPKI certificates, compared with nearly none a decade ago. - The company promotes early adoption of routing security standards because delays leave the Internet exposed to hijacks and route leaks. ## AI Agents and Internet Traffic - AI crawlers, training systems, and autonomous agents now generate more than 4% of HTML requests on Cloudflare’s network. - Human-initiated “user action” crawling increased more than 15-fold in 2025. - Unlike browsers, crawlers may retrieve every linked resource at maximum speed, making legitimate activity difficult to distinguish from attacks. - Cloudflare uses verified bot IP ranges, TLS fingerprints, behavioral analysis, and robots.txt signals to classify AI crawlers. - These signals help site owners decide which automated agents to permit. Cloudflare’s central lesson is that a global network must combine abundant capacity with intelligence distributed across every server. Its continued investment in automated mitigation, edge execution, routing security, and traffic classification is intended to make the Internet faster, safer, and more resilient as traffic patterns evolve.

network-securitycloudflaredistributed-systemsebpf+4

cloudflareApr 8, 2026

From bytecode to bytes- automated magic packet generation (opens in new tab)

Classic BPF filters can hide Linux malware until a precisely crafted “magic” packet arrives, but manually reverse-engineering large filters is slow and error-prone. The post presents a symbolic-execution approach using the Z3 theorem prover to model BPF instructions as packet constraints and automatically generate triggering packets. This reduces analysis from hours of manual work to seconds, even for filters exceeding 100 instructions. ## Why BPF Filters Are Difficult to Analyze - Classic BPF is a small, efficient virtual machine used to filter network traffic inside the Linux kernel. - Unlike eBPF, classic BPF has a simple two-register design but can still contain many conditional jumps and packet-offset calculations. - Malware authors exploit BPF because kernel-level filtering can hide traffic from ordinary user-space monitoring tools. - Short programs are manageable manually, but complexity grows rapidly as filters reach 100 or more instructions. - The core problem is determining which packet bytes satisfy the conditions along an accepting execution path. ## BPFDoor as a Practical Example - BPFDoor is a stealthy Linux backdoor associated with cyberespionage campaigns and groups including Red Menshen/Earth Bluecrow. - It uses BPF to inspect incoming traffic without listening on a dedicated open port. - The example filter checks: - IPv6 or IPv4 EtherType. - UDP protocol. - DNS destination port 53. - Fragmentation status for IPv4 packets. - The IPv4 header length when locating the UDP destination port. - The filter contains two paths leading to acceptance: - An IPv6 UDP packet destined for port 53. - A non-fragmented IPv4 UDP packet destined for port 53. - These paths expose the byte offsets and values that a generated packet must satisfy. ## Finding the Shortest Accepting Path - The tool explores the BPF control-flow graph using a queue. - Each queued item records: - The next instruction pointer. - The sequence of instructions already traversed. - Conditional jumps are explored in both directions. - Paths ending in a drop result are discarded, while paths reaching a nonzero return value are recorded as accepting paths. - Breadth-first traversal prioritizes paths with fewer conditions, helping identify the shortest route to acceptance. - Unconditional jumps are followed directly, while conditional branches enqueue true and false destinations in order of path length. ## Turning Paths into Packets - Once accepting paths are identified, each branch condition becomes a constraint on packet contents. - The required byte offsets, widths, and values can be collected from the executed instructions. - Symbolic execution represents these checks as constraints instead of requiring analysts to reason through every instruction manually. - Z3 can then solve the resulting constraint set and produce packet bytes that satisfy the selected accepting path. - This approach is especially useful for large or heavily branched BPF programs where manual packet construction becomes impractical. The recommended workflow is to combine control-flow exploration with symbolic constraint solving: first identify viable accepting paths, then use Z3 to generate packets satisfying their byte-level requirements. This automates a formerly labor-intensive part of malware analysis and makes complex BPF-based backdoors much faster to investigate.

network-securityebpfberkeley-packet-filterbpf+4

cloudflareApr 1, 2026

Our ongoing commitment to privacy for the 1.1.1.1 public DNS resolver (opens in new tab)

Cloudflare reports that an independent Big Four accounting firm has confirmed its 1.1.1.1 public DNS resolver continues to meet its privacy commitments. The review was conducted because Cloudflare’s DNS infrastructure has expanded and become more complex since the previous examination in 2020. Cloudflare says it aims to make privacy the default and encourages other public DNS providers to undergo similar independent reviews. ## Renewed Independent Privacy Examination - Cloudflare launched 1.1.1.1 in 2018 as a fast, privacy-focused DNS resolver. - A first independent review took place in 2020. - After major changes to its technology stack and DNS platform, Cloudflare commissioned the same accounting firm to conduct another examination. - The latest review examined evidence collected after the 2024 calendar year and took several months to complete. - The resulting report is available through Cloudflare’s compliance resources. ## Confirmed Privacy Commitments The examination confirmed that: - Cloudflare does not sell or share public resolver users’ personal data with third parties. - Resolver data is not used to target users with advertisements. - Cloudflare retains or uses the requested DNS information, rather than information identifying the person making the request. - Source IP addresses are anonymized and deleted within 25 hours. - DNS query information is not combined with other Cloudflare or third-party data in a way that could identify individual users. ## Limited Network Troubleshooting Data - Cloudflare may use randomly sampled network packets for troubleshooting and attack mitigation. - These samples represent no more than 0.05% of total traffic. - The samples can include the querying IP address, but are used solely for operational security and network reliability purposes. ## Scope of the Latest Review - Unlike the broader 2020 examination, the latest review focused exclusively on privacy commitments. - The earlier review also covered how Cloudflare handled anonymized transaction and debug logs, known as “Public Resolver Logs.” - Cloudflare says the use of those logs has evolved, including supporting services such as Cloudflare Radar. - The company maintains that these changes do not affect personal information or user privacy. Cloudflare’s practical position is that 1.1.1.1 users should not have to trust privacy promises alone: independent examinations should verify them. It recommends reviewing the published accountant’s report and continues to present 1.1.1.1 as a privacy-first DNS option.

network-securitycloudflarednsdata-protection+1

cloudflareMar 31, 2026

Introducing Programmable Flow Protection: custom DDoS mitigation logic for Magic Transit customers (opens in new tab)

Programmable Flow Protection lets Magic Transit Enterprise customers define custom DDoS mitigation logic for proprietary UDP protocols. Customers write eBPF programs that identify valid and malicious packets, then deploy them across Cloudflare’s global network to pass, drop, or challenge traffic. Currently in beta for an additional cost, the system addresses the limitations of generic blocking and rate limiting. ## Custom Protection for Proprietary UDP - Existing Cloudflare protections understand established protocols such as TCP, DNS, NTP, RDP, and SIP. - Proprietary UDP protocols are harder to protect because Cloudflare cannot interpret their application-level payloads. - Customers can now define what constitutes “good” and “bad” traffic using their own protocol knowledge. - Programs can drop or challenge invalid packets before they reach the customer’s origin. ## Why Generic UDP Mitigation Falls Short - UDP is connectionless and optimized for speed, making it useful for gaming, VoIP, and streaming. - When traffic does not match a known protocol, mitigation typically falls back to: - Blocking a destination IP and port - Applying a generic rate limit - These approaches cannot distinguish legitimate packets from attack traffic, potentially causing lag or connection loss for real users. - Fixed rate limits may also be inappropriate: - A network expecting 1 Gbps may need stricter limits. - A network expecting 25 Gbps may require more permissive thresholds. ## How Programmable Flow Protection Works - Customers upload custom eBPF programs that run on every packet destined for their network. - Programs execute in userspace rather than kernel space, providing isolation and flexibility across different customers and use cases. - Execution occurs after Cloudflare’s existing DDoS protections, preserving baseline security coverage. - Like kernel-based XDP eBPF programs, these programs: - Compile to BPF bytecode - Pass safety and termination verification - Run inside a lightweight, isolated virtual machine - Cloudflare provides specialized helpers for: - Maintaining client state between packet executions - Performing cryptographic validation - Sending challenge packets to clients ## Example: Protecting a Proprietary Game Protocol - A gaming provider running on UDP port 207 could inspect its proprietary application header. - If the header contains a protocol-specific token, the customer’s eBPF program can: - Parse the packet - Extract part of the token, such as its final byte - Pass packets with the expected value - Drop packets that fail validation - This allows legitimate players’ traffic through even when attacks use randomized source addresses, ports, and payloads. Programmable Flow Protection is best suited to Magic Transit customers whose custom UDP protocols cannot be protected effectively by standard protocol-aware controls. By combining customer-specific packet logic with Cloudflare’s global network and stateful challenge mechanisms, it enables more precise mitigation than blanket blocking or generic rate limiting.

network-securitycloudflareebpftcp+4

cloudflareMar 10, 2026

Investigating multi-vector attacks in Log Explorer (opens in new tab)

Cloudflare Log Explorer provides a unified view for investigating multi-vector attacks across application, network, identity, and endpoint activity. By correlating 14 new datasets from Cloudflare Application Services and Cloudflare One, analysts can connect reconnaissance, credential abuse, DDoS activity, lateral movement, and data-exposure risks. This broader visibility helps reduce Mean Time to Detect and supports faster, more complete forensic investigations. ## Unified Telemetry Across the Stack - Cloudflare describes logs as a “flight recorder” for digital infrastructure, capturing requests, attacks, configuration changes, and performance issues before traffic reaches origin servers. - Log Explorer centralizes telemetry in one interface, allowing analysts to correlate events across: - Application-layer HTTP traffic - Firewall and DDoS activity - DNS queries - Zero Trust access and network sessions - Endpoint, browser, email, and device events ## Zone-Scoped Logs These datasets focus on public websites, edge security, and application performance. - **HTTP Requests:** Reconstruct sessions, exploit attempts, and bot activity. - **Firewall Events:** Show blocked or challenged requests and the rules, IP reputations, or filters involved. - **DNS Logs:** Help detect cache poisoning, domain hijacking, and reconnaissance. - **NEL Reports:** Separate Layer 7 attacks from legitimate client connectivity problems. - **Spectrum Events:** Reveal Layer 4 anomalies and brute-force attempts against services such as SSH or RDP. - **Page Shield and Zaraz Events:** Track unauthorized JavaScript, outbound connections, third-party tools, and privacy-related behavior. ## Account-Scoped Logs Account-level datasets cover internal security, administration, identity, and network operations. - **Access Requests and Zero Trust Network Sessions:** Show who accessed protected applications and how long sessions lasted. - **Audit Logs:** Identify unauthorized Cloudflare configuration changes. - **CASB Findings:** Detect SaaS misconfigurations and potential data exposure. - **Gateway DNS, HTTP, and Network Logs:** Reveal malware callbacks, shadow IT, malicious downloads, unauthorized ports, and lateral movement. - **Magic IDS and Network Analytics:** Detect known exploit signatures, unusual traffic spikes, and volumetric attacks. - **Browser Isolation and Device Posture Logs:** Track risky user actions and whether connecting devices meet security requirements. - **Email Security Alerts:** Trace phishing and other email-based entry points. - **WARP and IPSec Logs:** Identify tampering with security connectivity and monitor encrypted tunnel health. - **DEX telemetry:** Help distinguish security incidents from ordinary application or device-performance problems. - **Sinkhole HTTP Logs:** Confirm attempts by internal devices to contact known botnet infrastructure. ## Investigating Attacks Across Multiple Stages - Public-facing telemetry can reveal how attackers probe websites, while account and Gateway logs show subsequent internal activity. - Analysts can correlate compromised credentials with the applications, devices, and network resources accessed by an attacker. - Magic IDS and Network Analytics extend investigations beyond HTTP to detect network-layer attacks and east-west movement. - Combining these sources gives investigators a timeline spanning initial reconnaissance, exploitation, internal access, and possible command-and-control activity. ## Detecting Reconnaissance - Query `http_requests` for repeated `401`, `403`, or `404` responses from a single IP address. - Look for requests targeting sensitive paths such as: - `/.env` - `/.git` - `/wp-admin` - Use `magic_ids_detections` to identify network-layer scanning. - Suspicious patterns include: - One source IP triggering multiple unique detections - Probes across many destination ports - Activity occurring within a short time window - Magic IDS signatures can identify techniques such as Nmap scans and SYN stealth scans. Log Explorer is most valuable when teams correlate its datasets rather than examining each log source in isolation. Combining application, identity, DNS, network, and endpoint telemetry provides the context needed to identify sophisticated attacks quickly and reconstruct their full scope.

network-securitycloudflarezero-trusthttp-requests+4

cloudflareMar 4, 2026

Mind the gap: new tools for continuous enforcement from boot to login (opens in new tab)

Cloudflare introduces two tools to enforce security continuously from device boot through application access: mandatory authentication and independent MFA. Mandatory authentication prevents unauthenticated devices from accessing the Internet, while Cloudflare MFA adds a second trust authority beyond the identity provider. Together, they reduce visibility gaps and limit the impact of compromised credentials. ## Closing the Authentication Gap - Cloudflare One Client provides policy enforcement and traffic inspection, but historically left devices exposed before a user authenticated or after a session expired. - In these “unknown device” states, users could potentially bypass controls using local machine connectivity. - Mandatory authentication, configured through MDM, makes the client enforce access from system boot: - Blocks Internet traffic using the system firewall. - Permits only the client’s authentication flow through a process-specific exception. - Prompts users to authenticate directly. - The feature will initially support Windows, with other platforms planned. ## Independent MFA at the Network Edge - SSO providers such as Okta, Entra ID, and Google are valuable security anchors but also high-value targets. - If an attacker hijacks an SSO session, they may gain access to every connected application. - Cloudflare MFA provides an independent, network-edge “step-up” factor, requiring attackers to overcome a second authority even if the primary IdP is compromised. - Supported methods include: - Biometrics such as Windows Hello, Touch ID, and Face ID. - WebAuthn, FIDO2, and PIV security keys. - TOTP authenticator applications. ## Granular Policy Enforcement - Administrators can require MFA globally, per application, or within specific access policies. - Organizations can match authentication strength to resource sensitivity—for example, weaker methods for chat and security keys for source-code repositories. - Strong MFA can be imposed on contractors using personal identities or social logins. - Legacy applications can receive modern MFA protection without code changes. - Cloudflare’s independent MFA is currently in closed beta. ## Reducing Attack Impact - Requiring authentication before Internet access ensures managed devices remain registered and visible. - Independent MFA reduces the blast radius of stolen passwords or compromised SSO sessions. - Cloudflare positions these capabilities as part of a broader move toward continuous, automated security posture enforcement. Organizations using Cloudflare One should consider mandatory authentication for managed endpoints and independent, risk-based MFA for sensitive applications.

network-securitycloudflarezero-trustmulti-factor-authentication+3

cloudflareMar 2, 2026

Beyond the blank slate: how Cloudflare accelerates your Zero Trust journey (opens in new tab)

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.

network-securitycloudflarecloudflare-workerszero-trust+4

cloudflareMar 2, 2026

The truly programmable SASE platform (opens in new tab)

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.

network-securitycloudflare-workerszero-trustinfrastructure-as-code+4

cloudflareMar 2, 2026

Modernizing with agile SASE: a Cloudflare One blog takeover (opens in new tab)

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.

network-securitycloudflare-workerszero-trustai-security+4

cloudflareFeb 27, 2026

Bringing more transparency to post-quantum usage, encrypted messaging, and routing security (opens in new tab)

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.

network-securitypost-quantum-cryptographyend-to-end-encryptioncryptography+4

cloudflareFeb 27, 2026

ASPA: making Internet routing more secure (opens in new tab)

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.

network-securitybgpaspainternet-routing+3

cloudflareFeb 23, 2026

Cloudflare One is the first SASE offering modern post-quantum encryption across the full platform (opens in new tab)

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.

network-securityzero-trustpost-quantum-cryptographysase+4

cloudflareFeb 5, 2026

2025 Q4 DDoS threat report: A record-setting 31.4 Tbps attack caps a year of massive DDoS assaults (opens in new tab)

Cloudflare’s 2025 DDoS report describes a dramatic escalation in both attack frequency and scale. DDoS attacks more than doubled to 47.1 million, while botnets such as Aisuru-Kimwolf launched unprecedented HTTP floods, including a record 31.4 Tbps attack. Cloudflare concludes that autonomous, adaptive mitigation is increasingly essential as attacks grow more frequent, larger, and more sophisticated. ## Record Growth in DDoS Attacks - Cloudflare mitigated 47.1 million DDoS attacks in 2025, a 121% increase from 2024 and a 236% increase since 2023. - The network automatically mitigated an average of 5,376 attacks per hour: - 3,925 network-layer attacks - 1,451 HTTP attacks - In Q4 2025, attacks increased 31% from the previous quarter and 58% year over year. - Network-layer attacks accounted for 78% of Q4 activity. ## Network-Layer Attacks More Than Triple - Network-layer attacks rose from 11.4 million in 2024 to 34.4 million in 2025. - An 18-day campaign in Q1 generated approximately 13.5 million attacks against Cloudflare infrastructure and Magic Transit customers. - The campaign used multiple vectors, including: - SYN floods - Mirai-generated attacks - SSDP amplification - Cloudflare’s systems detected and mitigated the campaign automatically. ## The Aisuru-Kimwolf “Night Before Christmas” Campaign - Beginning December 19, 2025, the Aisuru-Kimwolf botnet attacked Cloudflare and its customers with HTTP floods exceeding 20 million requests per second. - The botnet is estimated to contain 1–4 million malware-infected devices, primarily Android TVs. - During the campaign, Cloudflare mitigated 902 hyper-volumetric attacks: - 384 packet-intensive attacks - 329 bit-intensive attacks - 189 request-intensive attacks - Average attack rates reached 3 billion packets per second, 4 Tbps, and 54 million requests per second. - Maximum observed rates reached 9 Bpps, 24 Tbps, and 205 million requests per second. ## Hyper-Volumetric Attacks Reach New Records - Hyper-volumetric attacks increased 40% in Q4 compared with Q3. - Attack sizes grew more than 700% compared with large attacks in late 2024. - One attack reached 31.4 Tbps and lasted only 35 seconds. - Other record-scale attacks reached 205 million requests per second. - Telecommunications, service providers, and carriers were the primary targets, followed by gaming and generative AI services. - Cloudflare infrastructure itself faced HTTP floods, DNS attacks, and UDP floods. ## Most-Targeted Industries and Locations - Telecommunications, service providers, and carriers became the most-attacked industry, replacing Information Technology & Services. - Gambling and casinos ranked third, while gaming ranked fourth. - Computer software and business services climbed significantly in the top-ten rankings. - China, Germany, Brazil, and the United States remained among the most-attacked locations. - Hong Kong rose 12 places to become the second most-attacked location. - The United Kingdom climbed 36 places to rank sixth. Cloudflare’s data shows that organizations should prepare for attacks that combine enormous volume with rapidly changing techniques. Automated, network-scale defenses capable of identifying and adapting to large botnets are becoming a necessity rather than an optional protection.

network-securitythreat-intelligenceddos-mitigationiot-security+3