cloudflare·Mar 9, 2026·3 min readCurated summary

Fixing request smuggling vulnerabilities in Pingora OSS deployments

Pingora 0.8.0 fixes three HTTP/1.x request-smuggling vulnerabilities affecting standalone deployments used as Internet-facing ingress proxies. The flaws could let attackers bypass proxy security controls, desynchronize connections with backends, hijack other users’ sessions, or poison shared caches. Cloudflare’s own CDN was not affected, but Pingora users are urged to upgrade immediately. ## Scope and Impact - Vulnerabilities: - CVE-2026-2833 - CVE-2026-2835 - CVE-2026-2836 - Reported through Cloudflare’s bug bounty program in December 2025. - Affected deployments are standalone Pingora proxies exposed directly to the Internet. - Potential consequences included: - Bypassing ACL and WAF checks at the proxy layer. - Desynchronizing Pingora and backend HTTP connections. - Cross-user session or credential theft. - Cache poisoning when shared backends are used. - Cloudflare’s CDN was not vulnerable because Pingora is not used as its ingress proxy, and internal clients did not send pipelineable HTTP/1 requests to affected services. ## Premature Upgrade Without a `101` Response - Pingora treated a request containing an `Upgrade` header as an upgraded, pass-through connection immediately. - Under RFC 9110, the connection should switch protocols only after the backend returns `101 Switching Protocols`. - If the backend instead returned `200 OK`, Pingora could still forward subsequent bytes directly to the backend. - An attacker could pipeline a second, partial request—such as `/admin`—after the initial upgrade request. - This bypassed Pingora’s normal ACL or WAF processing and left Pingora and the backend disagreeing about request boundaries. - A later request from another user could complete the attacker’s partial request, causing the backend to return the attacker’s response to the wrong user. - Pingora 0.8.0 now enables pass-through mode only after receiving a valid `101` response. ## HTTP/1.0, Close-Delimited Bodies, and Transfer-Encoding - Another attack resembled a classic CL.TE desynchronization: - Pingora used `Content-Length` to determine the request body length. - The backend interpreted `Transfer-Encoding: chunked` and ended the body at the zero-length chunk. - The example combined: - HTTP/1.0 - `Connection: keep-alive` - Multiple transfer encodings - Both `Transfer-Encoding` and `Content-Length` - Pingora’s earlier transfer-encoding detection was too simplistic: - It only checked whether `Transfer-Encoding` contained “chunked.” - It assumed a single encoding or header. - HTTP specifications require the final transfer encoding to determine whether chunked framing applies, creating disagreement between Pingora and backend servers such as Node.js. - These differing interpretations of body boundaries enabled attackers to smuggle a second request through the proxy. ## Hardening and Recommendation Pingora 0.8.0 corrects the HTTP/1 framing and upgrade handling issues and adds defensive hardening. Operators running Pingora as an ingress proxy should upgrade as soon as possible and review whether their deployments expose HTTP/1 connections directly to untrusted clients.

Read original(opens in new tab)

Database DesignCloudflareNode.JsBug Bounty+3

cloudflare·Mar 9, 2026·3 min readCurated summary

Active defense: introducing a stateful vulnerability scanner for APIs

Cloudflare is launching a beta Web and API Vulnerability Scanner to actively detect API logic flaws that defensive tools often miss. Its first target is Broken Object Level Authorization (BOLA), where authenticated users can access or modify another user’s resources through valid requests. The scanner combines Cloudflare’s existing API visibility with stateful DAST to test authorization across sequences of API calls. ## Why Defensive Security Misses API Logic Flaws - Traditional WAFs are effective against recognizable attacks such as SQL injection, XSS, malformed requests, and suspicious payloads. - API vulnerabilities often involve valid requests that violate business rules rather than protocol or schema requirements. - In the food delivery example: - User A sends a valid `PATCH` request for User B’s order. - User A’s token, headers, and request schema are all legitimate. - The vulnerability exists because the API fails to verify that User A owns the order. - A basic authorization check could prevent the issue: ```js if (order.userID != user.ID) throw Unauthorized; ``` ## Passive Detection and the Limits of Traditional DAST - Cloudflare’s existing API Shield BOLA detection passively analyzes customer traffic for abnormal usage patterns. - Effective passive detection requires context about: - Valid API calls - Variable parameters - Normal user behavior - API responses when parameters are manipulated - Passive analysis may be insufficient in development environments with little traffic or production systems without observed attacks. - DAST creates new traffic specifically for security testing and can operate in environments without relevant user activity. - Traditional DAST tools often: - Require extensive configuration - Depend on manually maintained Swagger/OpenAPI files - Struggle with modern authentication flows - Lack API-specific tests such as BOLA detection ## Cloudflare’s API Scanning Advantage - Scan results will appear in Security Insights alongside other Cloudflare security findings. - API Shield customers already benefit from Cloudflare’s API Discovery and Schema Learning, which catalog endpoints and learn traffic patterns. - The initial release requires an uploaded OpenAPI specification, though future versions are expected to work without one. - Cloudflare can use passive traffic inspection to identify possible BOLA issues and actively verify them with new HTTP requests. - Customers provide API credentials, while Cloudflare uses API schemas to construct a scan plan automatically. ## Stateful API Scanning - Conventional scanners often evaluate requests independently, making it difficult to test vulnerabilities that require a sequence of related actions. - BOLA testing may require: - Creating a resource as one user - Attempting to access or modify it as another user - Comparing the resulting behavior - Cloudflare’s scanner builds an API call graph from the OpenAPI document. - It walks that graph using separate owner and attacker contexts: - Owners create resources. - Attackers use their own valid credentials to attempt access. - This stateful approach is designed to test authorization across realistic API workflows rather than isolated requests. Cloudflare’s scanner is intended to complement—not replace—passive monitoring and edge defenses. Organizations should use the beta to actively test APIs, especially authorization controls, in environments where normal traffic provides insufficient security context.

Read original(opens in new tab)

CloudflareApi SecurityOpenapiVulnerability Scanning+3

cloudflare·Mar 9, 2026·3 min readCurated summary

Complexity is a choice. SASE migrations shouldn’t take years.

Cloudflare argues that SASE and zero trust migrations do not need to take years. Its partners, TachTech and Adapture, reportedly reduced deployments from around 18 months to four–six weeks by using Cloudflare One’s unified, cloud-native architecture. The post concludes that programmable security infrastructure can accelerate zero trust adoption while also enabling safer use of AI. ## Faster Zero Trust Deployments - Traditional Secure Web Gateway (SWG) and Zero Trust Network Access (ZTNA) migrations can take up to 18 months for large organizations. - TachTech reduced comparable Cloudflare One deployments to four–six weeks. - Cloudflare Access is presented as lightweight and largely “no-touch” after deployment, reducing ongoing operational effort. ## Why Legacy Migrations Stall - Legacy architectures often treat migration as hardware replacement rather than software transformation. - Complex service chaining creates a “trombone effect,” increasing latency and making troubleshooting difficult. - Cloudflare’s partners accelerate migrations through: - **Identity-first on-ramps:** Existing identity-provider groups define access policies instead of rebuilding network segments. - **Consolidated policy engines:** SWG and ZTNA policies are handled together, avoiding synchronization between separate products. - **Cloud-native connectors:** Tools such as `cloudflared` provide connectivity without opening inbound firewall ports. ## Scaling Quickly - Adapture expanded one Cloudflare Access deployment from 600 contractors to 5,000 users. - The company describes the expansion as seamless compared with the lengthy implementation cycles associated with legacy SASE platforms. - Cloudflare positions rapid elasticity as important for organizations whose workforce and security needs change quickly. ## A Programmable, Extensible Edge - Cloudflare One is described as software-defined and composable, allowing partners to adapt it to specialized environments. - TachTech supported Arch Linux developer workstations by extracting binaries from an Ubuntu `.deb` package and creating a custom `PKGBUILD`. - This approach preserved device-posture checks, including disk-encryption and firewall-status verification, without creating a security exception. ## Supporting Safe AI Adoption - Cloudflare says the Secure Web Gateway is evolving from simple URL filtering toward controlling data flows to large language models. - Its AI security capabilities include: - **Shadow AI visibility:** Identifying unauthorized AI tools in use across the organization. - **AI confidence scores:** Evaluating models based on standards such as SOC 2 and ISO 42001, as well as data-handling practices. - **DLP prompt protection:** Blocking sensitive source code, personally identifiable information, and financial data from being submitted to public AI services. - **LLM discovery:** Finding and labeling internet-exposed LLM endpoints to reveal the organization’s AI attack surface. - **Request validation:** Intended to defend AI applications against prompt injection and related attacks. Cloudflare’s central recommendation is to replace fragmented, hardware-oriented security deployments with a unified, programmable platform. Doing so can shorten zero trust migrations, simplify operations, preserve consistent security controls across unusual environments, and establish a faster foundation for responsible AI adoption.

Read original(opens in new tab)

Database DesignCloudflarePostgreSQLZero Trust+4

cloudflare·Mar 6, 2026·2 min readCurated summary

From the endpoint to the prompt: a unified data security vision in Cloudflare One

Cloudflare One presents data security as a unified problem spanning networks, SaaS applications, endpoints, and AI prompts. Its strategy is to follow data wherever it moves, combining visibility, policy controls, and enforcement rather than relying on siloed products. The latest updates extend this model from browser-based RDP clipboard controls to SaaS operation logging, endpoint DLP, and Microsoft 365 Copilot scanning. ### Browser-Based RDP Clipboard Controls - Administrators can control whether users copy or paste data between local devices and browser-based RDP sessions. - Policies can be directional and context-specific: - Allow copying into a remote session for productivity. - Block copying sensitive information out to unmanaged endpoints. - The feature is configured through Access Application Policies for browser-based RDP applications. - Granular controls aim to reduce risky workarounds such as screenshots, manual retyping, or use of unsanctioned tools. ### Operation-Level Visibility in SaaS Logs - Cloudflare’s operation-mapping process interprets HTTP request details as recognizable actions, such as `SendPrompt` in ChatGPT. - Related operations are grouped into higher-level Application Controls such as “Share” or “Upload.” - These mapped operations now appear automatically in log events for matching SaaS traffic. - Log details include both the application control and the specific operation, helping teams investigate activity and refine policies more quickly. ### Endpoint DLP for Data in Use - The Cloudflare One Client now provides Endpoint DLP enforcement, beginning with clipboard-based data movement. - This protects sensitive content after it leaves a browser or managed SaaS application and enters the operating system clipboard. - The feature addresses risks such as copying customer records or proprietary code into personal tools or unauthorized AI assistants. - Organizations can extend existing Gateway, DLP, CASB, and API-based controls without deploying a separate endpoint agent. ### Microsoft 365 Copilot Scanning - API CASB can now analyze Microsoft 365 Copilot activity for data-security risks. - Scanning covers Copilot chats and uploads that match configured DLP detection profiles. - Findings include contextual information such as referenced files, matching DLP profiles, and interaction metadata. - This extends Cloudflare’s existing API integrations for OpenAI ChatGPT, Anthropic Claude, and Google Gemini. Cloudflare’s recommendation is effectively to treat data movement as one continuous security problem: control access in transit, monitor activity in SaaS, enforce protections on endpoints, and inspect how data is used in AI prompts. Together, these capabilities are intended to keep policy attached to the data rather than limited to a particular application or product boundary.

Read original(opens in new tab)

Database DesignAi SecurityCloudflare OneSaas Security+4

cloudflare·Mar 5, 2026·2 min readCurated summary

Ending the "silent drop": how Dynamic Path MTU Discovery makes the Cloudflare One Client more resilient

Cloudflare’s Dynamic Path MTU Discovery (PMTUD) helps prevent connections from silently failing when network paths cannot carry large encrypted packets. Using active probing through MASQUE and QUIC, the Cloudflare One Client determines the largest reliable packet size and adjusts its virtual interface accordingly. This makes applications more resilient across restrictive, changing networks without relying on ICMP error messages. ## The PMTUD Black Hole Problem - Networks have a maximum transmission unit (MTU), typically 1500 bytes on Ethernet. - Encryption and security metadata reduce the space available for application data. - LTE/5G, satellite, public safety, and other specialized networks may support smaller MTUs, such as 1300 bytes. - Routers should send ICMP messages when packets are too large, but firewalls and middleboxes often drop those messages. - The sender continues transmitting oversized packets, leaving uploads, video calls, SSH sessions, or other applications stuck until they time out. ## Active Path Discovery with MASQUE - Cloudflare implements RFC 8899 Datagram Packetization Layer PMTUD. - The Cloudflare One Client sends encrypted probes of different sizes to the Cloudflare edge. - By observing which probes arrive, it identifies the usable MTU without depending on blocked ICMP feedback. - Probing narrows the range from the supported maximum toward the precise path capacity. - The process runs in the background and is designed not to disrupt active connections. ## Adapting to Changing Networks - The client dynamically changes its virtual interface MTU based on the discovered path. - It periodically revalidates the path, allowing it to respond when users move between networks. - For example, a connection can transition from 1500-byte Wi-Fi to 1300-byte cellular connectivity without interrupting application sessions. ## Benefits for Critical and Everyday Connectivity - First responders can maintain stable CAD and other mission-critical connections across NAT layers, tower handoffs, and fluctuating signal conditions. - Hybrid workers benefit from fewer stalled transfers and more reliable video calls on hotel, cellular, and double-NAT networks. - The client hides much of the underlying network instability from applications. Cloudflare One Client users running the MASQUE protocol can use PMTUD on Windows, macOS, and Linux at no additional cost.

Read original(opens in new tab)

CloudflareNetworkingQuicEncryption+4

cloudflare·Mar 5, 2026·2 min readCurated summary

A QUICker SASE client: re-building Proxy Mode

Cloudflare rebuilt the Cloudflare One Client’s proxy mode to address performance problems caused by translating TCP traffic into IP packets through WireGuard. The new design uses HTTP/3 and QUIC streams for direct Layer 4 proxying, eliminating the smoltcp translation layer. Internal tests showed download and upload speeds doubling while latency decreased significantly. ## Limitations of the Original Proxy Architecture - Proxy mode exposed a local SOCKS5 or HTTP proxy for broad application compatibility. - WireGuard operates at Layer 3, while proxy traffic arrives as Layer 4 TCP streams. - The Client used the Rust-based `smoltcp` stack to convert TCP streams into IP packets. - Cloudflare’s edge then converted those packets back into TCP streams. - This added overhead, limited access to modern TCP features, and caused sluggish performance for media-heavy websites, large transfers, and video calls. ## Direct Layer 4 Proxying with QUIC - Cloudflare deprecated WireGuard for proxy mode and adopted QUIC-based transport. - HTTP/3’s `CONNECT` method encapsulates proxy traffic directly in QUIC streams rather than breaking it into Layer 3 packets. - The new architecture: - Removes the smoltcp translation layer. - Uses QUIC’s built-in congestion and flow control. - Allows the Client and Cloudflare edge to tune transport parameters for performance. - Testing showed approximately doubled upload and download speeds and substantially reduced latency. ## Use Cases That Benefit - **Third-party VPN coexistence:** Users can combine legacy VPNs for on-premises resources with zero trust web security without imposing as much performance loss. - **Application partitioning:** Specific browser traffic can be routed through Cloudflare Gateway while other operating-system traffic remains on the local network. - **High-bandwidth workloads:** Streaming, large dataset transfers, and other data-intensive applications receive faster proxy connections. - **Developer and CLI workflows:** Tools using the SOCKS5 listener benefit from lower-latency API calls and data transfers. ## Availability and Configuration - The improvement requires Cloudflare One Client version `2025.8.779.0` or later on Windows, macOS, or Linux. - In the Cloudflare One dashboard: - Go to **Teams & Resources > Devices > Device profiles > General profiles**. - Set **Service mode** to **Local proxy mode**. - Set **Device tunnel protocol** to **MASQUE**. - Verify the active protocol with: ```bash warp-cli settings | grep protocol ``` Organizations using proxy mode should upgrade the client and switch to MASQUE to gain the new QUIC-based performance improvements.

Read original(opens in new tab)

CloudflareSaseQuicHttp3+4

cloudflare·Mar 5, 2026·2 min readCurated summary

How Automatic Return Routing solves IP overlap

Cloudflare’s Automatic Return Routing (ARR) addresses overlapping private IP ranges by routing return traffic based on the tunnel that initiated a connection, rather than relying solely on destination IPs. This allows identical networks to coexist without NAT, VRFs, or manually maintained route mappings. ARR is being introduced as an optional Closed Beta capability for Cloudflare One customers. ## The Ambiguity of Overlapping Private Networks - Public Internet routing assumes each IP address identifies one logically unique destination. - Private networks often reuse the same ranges, such as `10.0.1.0/24`, creating ambiguity when connected through Cloudflare. - Common causes include: - Mergers and acquisitions involving duplicate internal addressing. - Extranets connecting partners or vendors with conflicting IP schemes. - Repeated “cookie-cutter” architectures across branches or customer deployments. - If two sites use the same source IP, return traffic cannot be distinguished by a conventional routing table and may be sent to the wrong site. ## Limitations of Traditional Solutions - **Virtual Routing and Forwarding (VRF):** - Separates overlapping networks with independent routing tables. - Adds operational overhead. - Route leaking between VRFs becomes complex and brittle at scale. - **Network Address Translation (NAT):** - Maps overlapping ranges to unique managed addresses. - Works reliably but requires administrative mappings for every site or partner. - Cloudflare designed ARR to eliminate this per-site configuration for common use cases such as Internet and private data center access. ## How Automatic Return Routing Works - ARR replaces ambiguous route-based decisions with stateful flow tracking. - When a packet begins a flow, Cloudflare records the specific connection or tunnel that delivered it. - Supported originating connections include: - IPsec tunnels - GRE tunnels - Network Interconnects - For subsequent packets, Cloudflare checks whether they match an existing flow. - Existing flows reuse their stored forwarding decisions instead of being evaluated from scratch. - New flows are processed through the relevant Cloudflare One components—such as Gateway, DLP, and Firewall—and ARR records the initiating tunnel. - Return traffic is then sent back through that same tunnel, answering “where did this conversation originate?” rather than “which network owns this IP?” ## Practical Implication ARR enables overlapping private networks to communicate through Cloudflare One without NAT or complex VRF designs. It is intended as a zero-touch approach to reducing routing administration, and is available initially in Closed Beta.

Read original(opens in new tab)

Cloudflare OneAutomatic Return RoutingStateful TrackingNetwork Address Translation+4

cloudflare·Mar 4, 2026·3 min readCurated summary

Always-on detections: eliminating the WAF “log versus block” trade-off

Traditional WAFs force teams to choose between broad visibility in logging mode and active protection in blocking mode. Cloudflare’s new always-on detection model separates attack detection from mitigation, allowing every signature to inspect traffic and provide metadata without immediately blocking requests. Attack Signature Detection is available in Early Access, while Full-Transaction Detection is planned to improve accuracy by analyzing both requests and responses. ## The Always-On Framework - Detection signatures run on every proxied request for opted-in customers. - Results appear in Security Analytics and are added to request metadata usable by custom security rules. - Detection is separated from mitigation: - Signatures identify suspicious traffic. - Security rules decide whether to block, challenge, or otherwise handle it. - This preserves visibility into all matching signatures, even when one detection leads to a mitigation action. - Initially, detections can run after the request is sent to the origin, avoiding added latency. - Once a blocking rule depends on a detection, that detection runs inline and may add latency based on the application’s traffic profile. - Bot Score and Attack Score already use this detection model. ## Attack Signature Detection - The system uses the same analytical heuristics as Cloudflare Managed Rules but does not directly apply traffic actions. - It covers attack types such as: - SQL injection - Cross-site scripting - Remote code execution - Specific CVEs - Cloudflare’s Managed Ruleset contains more than 700 active rules, with new rules generally released weekly and emergency rules released for major vulnerabilities. - Each signature has: - A unique Ref ID - One confidence level - One or more attack categories - Confidence levels indicate expected false-positive risk: - **High:** Designed for high true-positive rates and low false positives; comparable to default Managed Rules behavior. - **Medium:** More likely to cause application-specific false positives and should be assessed before blocking. ## Detection Metadata Attack Signature Detection exposes three fields in Security Analytics and the Edge Rules Engine: - `cf.waf.signature.request.confidence` - An array of confidence values for matching signatures. - `cf.waf.signature.request.categories` - An array of matched attack categories, such as SQLi or XSS. - `cf.waf.signature.request.ref` - An array of up to 10 matching signature Ref IDs. These fields let teams create precise policies based on observed traffic rather than relying on broad, manually tuned rules. ## Using Security Analytics for Onboarding - Detection begins collecting data as soon as an application is proxied through Cloudflare. - Teams can review aggregate matches by signature and attack category. - Analysts can compare matches against request outcomes, including: - Blocked requests - Cached responses - Requests delivered to the origin - If malicious traffic reaches the origin, teams can quickly create appropriate security rules. - Analytics also helps identify false positives and determine where exceptions are needed. ## Full-Transaction Detection - The planned system will analyze the complete HTTP transaction, including both request and response. - Correlating both sides should reduce false positives compared with request-only engines. - It may detect threats that request analysis misses, including: - Reflective SQL injection - Subtle data-exfiltration behavior - Dangerous misconfigurations visible only in responses The practical recommendation is to enable Attack Signature Detection during application onboarding, use its metadata and analytics to understand real traffic, and then create targeted mitigation rules. This preserves continuous visibility while allowing teams to deploy blocking protections with greater confidence.

Read original(opens in new tab)

Web Application FirewallCross Site ScriptingSql InjectionSecurity Analytics+4

cloudflare·Mar 4, 2026·2 min readCurated summary

Mind the gap: new tools for continuous enforcement from boot to login

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.

Read original(opens in new tab)

CloudflareZero TrustNetwork SecurityMulti Factor Authentication+3

cloudflare·Mar 4, 2026·3 min readCurated summary

Defeating the deepfake: stopping laptop farms and insider threats

Trust is becoming a critical security weakness as attackers use stolen identities, AI-generated deepfakes, and laptop farms to impersonate remote workers. Traditional zero trust controls verify devices and credentials but often fail to verify the actual person behind them. Cloudflare’s partnership with Nametag adds identity verification during onboarding and risk-based controls afterward, aiming to prevent fraudulent workers from accessing corporate systems. ## The Rise of Remote Worker Fraud - Organized groups, including North Korean operations, use “laptop farms” to infiltrate companies. - Devices are shipped to domestic addresses, physically connected to KVM switches, and remotely operated by fraudulent workers. - Attackers use stolen identities, generative AI for interviews, and deepfake tools to create convincing government IDs and selfies. - Valid credentials and corporate-issued devices can make these users appear legitimate to standard zero trust systems. ## Why Traditional Insider Threat Defenses Fall Short - DLP and UEBA tools typically detect suspicious behavior only after an attacker has gained access. - Conventional onboarding often trusts: - The identity provided by a new hire - The shipping address receiving the laptop - Credentials sent to a personal email address - Zero trust policies commonly verify device posture, location, and account permissions—but not whether the person is genuinely the employee. ## Identity-Verified Zero Trust - Cloudflare Access is adding Nametag’s workforce identity verification to its existing policy checks. - Nametag verifies that the person receiving, configuring, and using a device is: - A real person - The legitimate person named in the identity documents - The authorized employee - Verification occurs before access to email, code repositories, or other internal resources is granted. ## How the Nametag Integration Works - Nametag integrates with Cloudflare Access through OpenID Connect (OIDC). - It can operate as the primary identity provider or as an additional evaluation factor alongside Okta or Microsoft Entra ID. - A typical onboarding flow includes: - The user attempts to access an onboarding portal. - Cloudflare redirects them to Nametag. - The user provides a work email, takes a selfie, and scans a government-issued ID. - Nametag’s Deepfake Defense technology uses cryptography, biometrics, and AI to detect fake identities, injection attacks, and presentation attacks such as printed photos. - A successful verification returns an ID token to Cloudflare, which applies its Access policies. - The process reportedly takes less than 30 seconds, and biometrics are not retained afterward. ## Layered Insider Threat Protection - Identity verification complements Cloudflare’s existing controls: - API-driven DLP for detecting data exfiltration - Remote Browser Isolation for reducing browsing risks - Shadow IT reporting and CASB capabilities for identifying unmanaged services and misconfigurations - Together, these controls distinguish between knowing which account is connecting and knowing who is actually behind the keyboard. ## Continuous Verification - Initial identity checks are not sufficient because legitimate credentials can later be sold or compromised. - Cloudflare Access uses user risk scores to support context-aware policies. - A sudden increase in risk can trigger access revocation for one or multiple applications. Organizations facing remote hiring and insider-threat risks should supplement device and credential verification with strong identity assurance at onboarding, followed by continuous, risk-based monitoring.

Read original(opens in new tab)

AICloudflareZero TrustData Loss Prevention+4

cloudflare·Mar 4, 2026·2 min readCurated summary

Stop reacting to breaches and start preventing them with User Risk Scoring

Cloudflare is adding User Risk Scores to Cloudflare One so access decisions can reflect a user’s recent behavior, not just identity and device posture. The system continuously combines security signals, assigns a deterministic risk level, and applies adaptive access policies in real time. This is intended to replace slow, manual incident response with continuous, automated protection. ## Continuous User Risk Scoring - Risk scores identify behaviors associated with compromised accounts or insider threats, including: - Impossible travel - Failed login attempts - Malware detections - Risky browsing - Data loss prevention (DLP) violations - Outdated or insecure devices - Cloudflare Access and Gateway provide internal telemetry such as login activity, location, malware events, and sensitive-data triggers. - Integrations with CrowdStrike and SentinelOne add third-party device and security signals. - Administrators choose which behaviors to monitor and assign each a low, medium, or high risk level. - A user’s score is based on the highest-risk enabled behavior detected during the relevant period. - Investigators can manually reset a score after reviewing an incident while retaining its historical record. ## Adaptive Access Policies - User Risk Score is now available as a condition in Cloudflare Access policies. - Organizations can create global or application-specific controls, such as: - Blocking high-risk users from financial applications - Requiring medium-risk users to authenticate with a physical security key - Automated enforcement reduces the delay involved in revoking sessions or changing identity-provider groups manually. - Policies can limit damage while allowing lower-risk users to continue working. ## Dynamic Enforcement and Integrations - Access can be revoked during an active session when a user’s risk increases. - Access is automatically restored when the score falls after investigation and clearance. - Cloudflare plans to explore enforcing step-up MFA during active sessions when risk changes. - Through the Shared Signals Framework, Cloudflare can send risk information to Okta so users restricted on the network are also restricted at the SSO entry point. Cloudflare recommends using User Risk Scores to make zero trust access continuously adaptive rather than evaluating users only at login. Existing customers can configure the feature in the Cloudflare One dashboard, while larger organizations can integrate partner telemetry through a ZTNA pilot.

Read original(opens in new tab)

Zero TrustSaseCloudflare OneIdentity Provider+4

cloudflare·Mar 4, 2026·2 min readCurated summary

Moving from license plates to badges: the Gateway Authorization Proxy

Cloudflare’s Gateway Authorization Proxy extends identity-based traffic protection to devices where the Cloudflare One Client cannot be installed. It replaces IP-based identification with browser-based authentication, allowing organizations to apply user-specific policies and maintain visibility across unmanaged endpoints. The solution is especially suited to VDI, acquisitions, and regulated environments, while the One Client remains preferable for fully managed devices. ## Limitations of IP-Based Proxy Access - Earlier proxy endpoints identified users through static IP addresses. - This resulted in: - Logs that showed locations rather than individual users. - Policies breaking when users changed networks. - Manual maintenance of self-hosted Proxy Auto-Configuration (PAC) files. ## Gateway Authorization Proxy - The proxy authenticates users through a Cloudflare Access-style login before applying Gateway filtering. - Organizations can: - Attribute proxy traffic and logs to specific users. - Create granular rules, such as restricting accounting tools to the Finance team. - Offer one or multiple identity providers, including Okta and Azure AD. - Use a familiar per-user seat-based billing model. ## Cookie-Based Identity Tracking - The proxy uses signed JWT cookies to associate a user with requests. - On the first visit to a domain: - The proxy checks for a domain-specific identity cookie. - If none exists, it redirects the user to Cloudflare Access. - Existing Access sessions can issue a domain-specific token immediately. - Otherwise, the user authenticates through the configured identity provider. - Once established, the cookie authorizes later requests to that domain and its subdomains without further redirects. - Cloudflare’s edge network makes the authentication flow effectively invisible to users. - Access can be revoked quickly without installing software on the endpoint. ## Cloud-Hosted PAC Files - Cloudflare now hosts PAC files, removing the need for customers to operate their own hosting. - Starter templates simplify initial configuration. - Cloudflare’s AI assistant, Cloudy, can summarize PAC file behavior so administrators do not need to inspect the code manually. ## Best-Fit Use Cases - **Virtual desktop infrastructure:** Browser traffic from managed or shared virtual machines. - **Mergers and acquisitions:** Rapidly bringing users from different organizations under common security policies. - **Compliance-constrained environments:** Devices where endpoint software installation is prohibited. - The Cloudflare One Client is still recommended when deeper device control and the best user experience are possible. The Gateway Authorization Proxy is a practical alternative for securing unmanaged devices: use the One Client for fully managed endpoints, and browser-based authorization when identity and policy enforcement must happen without endpoint installation.

Read original(opens in new tab)

CloudflareJwtIdentity ManagementProxy Configuration+3

cloudflare·Mar 3, 2026·3 min readCurated summary

Introducing the 2026 Cloudflare Threat Report

Cloudflare’s 2026 Threat Report argues that cyberattacks are shifting from brute-force intrusion toward high-trust exploitation. Attackers increasingly prioritize “Measure of Effectiveness” (MOE)—the greatest operational result for the least effort—using stolen tokens, AI, trusted cloud services, and social engineering rather than costly custom exploits. The report concludes that defenders must focus on identity, integrations, infrastructure resilience, and continuous monitoring of legitimate tools. ## Measure of Effectiveness (MOE) - MOE measures the ratio between an attacker’s effort and the operational outcome. - Threat actors favor: - Stolen session tokens over expensive zero-day exploits. - Reputation-based infrastructure such as LotX over custom servers. - AI-assisted automation over manually written tooling. - The most dangerous actors are those able to combine intelligence and technology into continuous, high-speed operations. ## Eight trends shaping the 2026 threat landscape - **AI-driven attacker operations** - Generative AI supports real-time network mapping, exploit development, and deepfake creation. - Lower-skilled attackers can now conduct more sophisticated, high-impact campaigns. - **State-sponsored infrastructure pre-positioning** - Groups such as Salt Typhoon and Linen Typhoon are targeting North American telecommunications, government, commercial, and IT services. - Their goal is to maintain access that can provide long-term geopolitical leverage. - **Over-privileged SaaS integrations** - Third-party APIs can expand a single compromise across hundreds of organizations. - The GRUB1 breach of Salesloft demonstrates the risks created by excessive integration privileges. - **Weaponized trusted cloud tools** - Attackers use services such as Google Calendar, Dropbox, GitHub, Google Drive, Microsoft Teams, and Amazon S3 to conceal malicious activity. - Legitimate enterprise traffic makes command-and-control communications harder to distinguish from normal use. - **Deepfake-based insider placement** - North Korean operators are using fraudulent identities and deepfakes to place remote IT workers inside Western companies. - These operatives support espionage and illicit revenue generation. - **Session-token theft** - Infostealers such as LummaC2 harvest active authentication tokens. - Attackers can then bypass multi-factor authentication and begin post-authentication activity. - **Internal brand spoofing** - Phishing-as-a-service tools exploit mail-relay blind spots where sender identity is not re-verified. - This enables convincing impersonation messages to arrive directly in trusted user inboxes. - **Hyper-volumetric DDoS attacks** - Botnets such as Aisuru are generating increasingly large distributed denial-of-service attacks. - The speed and scale of these attacks can overwhelm infrastructure before human responders can react. ## Living off legitimate cloud infrastructure - Attackers increasingly avoid known malicious servers and instead use legitimate SaaS, IaaS, and PaaS platforms. - Cloud services can be used to host payloads, redirect victims, deliver malware, or scale campaigns. - Amazon SES and SendGrid, for example, can be abused for phishing and malware distribution. - This “living off the land” approach—or “living off anything-as-a-service”—allows attackers to hide behind the reputation and normal traffic patterns of trusted providers. - Cloud-resource abuse is evolving from opportunistic infrastructure misuse into a deliberate nation-state strategy. Defenders should treat identity tokens, SaaS permissions, cloud activity, and trusted integrations as critical security boundaries. Organizations need least-privilege access, stronger token protection, continuous monitoring, automated DDoS mitigation, and detection that evaluates behavior—not just whether a service is legitimate.

Read original(opens in new tab)

AIDatabase DesignSaasDdos+3

cloudflare·Mar 3, 2026·3 min readCurated summary

Evolving Cloudflare’s Threat Intelligence Platform: actionable, scalable, and ETL-less

Cloudflare’s Threat Intelligence Platform (TIP) is designed to turn massive volumes of security telemetry into actionable intelligence without relying on traditional ETL pipelines. Its sharded, SQLite-backed architecture uses Durable Objects and edge-based GraphQL to provide near-real-time analysis across millions of events. By combining automated telemetry with analyst investigations, the platform aims to help security teams understand threats and block them proactively. ## Motivation for Building the Platform - Cloudflare began developing the TIP after launching Cloudforce One in 2022 and discovering that existing tools could not adequately track adversary infrastructure. - The platform models the full threat lifecycle, connecting: - Threat actors to malware - Cases to indicators - Events to broader campaigns - It is designed for: - Multiple datasets and tenants - Group-based and tenant-to-tenant sharing - Extensibility and edge-scale performance - Visual analysis and automated response - Cloudflare Workers allow the platform to evolve with the runtime and support features such as Smart Placement, higher CPU limits, and Hyperdrive. ## Beyond the SIEM - The TIP complements rather than replaces a SIEM: - SIEMs focus on real-time log aggregation and alerting. - The TIP provides long-term retention, specialized threat schemas, and historical context. - Analysts can enrich alerts with: - Indicator history - Known threat-actor associations - Campaign relationships - Risk scores and intelligence context - Findings from analysts feed new indicators of compromise back into the platform. - This feedback loop keeps intelligence current and helps organizations move from reactive investigation to proactive defense. ## Sharded Storage Without ETL Bottlenecks - Cloudflare distributes Threat Events across many logical shards instead of using one centralized database. - Each shard is a Durable Object with a private SQLite database, providing transactional consistency and avoiding a single database bottleneck. - Cloudflare Queues handle asynchronous ingestion, helping absorb high-volume attack spikes. - R2 stores data for long-term retention, while SQLite maintains a hot index for fast access. - Because data is available directly in the platform’s operational store, complex ETL pipelines and synchronization delays are avoided. ## Parallel Queries at the Edge - GraphQL runs in the same Worker-based system that powers the Threat Events platform, keeping data live from ingestion through querying. - Queries are fanned out to relevant Durable Objects in parallel rather than executed against one large table. - The platform first verifies permissions and excludes shards that cannot contain matching events, such as shards outside the requested date range. - Results from multiple shards are aggregated with `Promise.all`, enabling low-latency searches across global datasets. - Smart Placement positions query Workers near the Durable Objects they access, reducing tail latency. Cloudflare’s approach combines edge-native storage, parallel execution, and analyst-driven enrichment to make threat intelligence both scalable and actionable. The practical goal is a unified system that explains not only what is malicious, but also why it matters and how to automatically prevent it.

Read original(opens in new tab)

Database DesignCloudflare WorkersGraphQLSqlite+4

cloudflare·Mar 3, 2026·3 min readCurated summary

How Cloudy translates complex security into human action

Cloudy is Cloudflare’s LLM-powered explanation layer for Cloudflare One, translating complex security detections into clear, actionable guidance. It helps security teams understand why emails or SaaS findings were flagged and helps end users make better decisions in real time. Its integration with Phishnet aims to reduce unnecessary SOC submissions while preserving strong protection against genuine threats. ## Turning Complex Detections into Human Guidance - Email and CASB systems analyze numerous signals, including sender reputation, authentication, links, infrastructure, behavior, misconfigurations, and exposed data. - Traditional detections may correctly identify risk without clearly explaining the reasoning. - Cloudy converts machine-learning outputs into concise explanations for both administrators and nontechnical users. - For Email Security, it explains why messages are classified as Malicious, Suspicious, Spam, Bulk, or Spoof. - For CASB, it is intended to clarify the risk and remediation path for SaaS findings. ## The Challenge for Email Users and SOC Teams - Users increasingly serve as an additional defense layer against social engineering and impersonation attacks. - Periodic security training and phishing simulations do not provide enough context when users encounter real messages. - This creates two problems: - Some users report nearly every questionable email, overwhelming SOC queues. - Others interact with risky messages because no clear warning appears at the moment of decision. - Excessive reporting creates backlogs and slows investigations of genuinely dangerous emails. ## Cloudy in Phishnet - Cloudy will be integrated into the Phishnet reporting workflow for Microsoft. - When users report a message, they will receive a simplified, plain-language explanation of the relevant security signals. - The goal is to help users decide whether a message is truly suspicious and reduce unnecessary escalations. - This allows SOC teams to focus on messages requiring investigation while making users more effective participants in security operations. ## How the Explanation Pipeline Works - A Phishnet report triggers a Cloudflare Workers-based workflow. - The workflow aggregates outputs from multiple detection models, including: - Sender reputation - Domain and infrastructure characteristics - SPF, DKIM, and DMARC authentication results - Link and content analysis - Behavioral indicators - Workers AI processes these structured signals using purpose-built prompts. - The prompts generate a natural-language explanation rather than changing the original message classification. - The experience is optimized for end users, avoiding overly technical terms such as ASNs, IP reputation, and raw authentication failures. ## Translating Technical Signals - An SPF failure becomes: “This email failed a sender verification check.” - A DKIM failure is explained as a failed message-integrity check that may indicate tampering. - A DMARC failure indicates that the sender’s domain could not confirm the email’s legitimacy. - These translations preserve the meaning of the underlying detections while making them understandable to nontechnical recipients. Cloudy’s practical value is its ability to connect sophisticated security analysis with immediate human decision-making. Embedding understandable explanations directly into Phishnet should improve user judgment, reduce SOC noise, and make complex detections more actionable without altering the underlying security verdict.

Read original(opens in new tab)

Large Language ModelsMachine LearningCloudflareCloudflare Workers+4