techlist.io
KREN

Cloudflare

78 posts

cloudflare3 min readCurated summary

Translating risk insights into actionable protection: leveling up security posture with Cloudflare and Mastercard

Organizations are expanding their Internet-facing assets faster than they can inventory and secure them, leaving shadow domains, forgotten hosts, and vulnerable services exposed. Cloudflare and Mastercard plan to integrate RiskRecon attack surface intelligence into Cloudflare Security Insights to continuously discover these risks and recommend remediation. The integration is intended to shift security from periodic audits toward ongoing visibility and protection. ## Attack Surface Intelligence - Mastercard RiskRecon maps an organization’s public Internet footprint using outside-in, publicly available data. - It can identify shadow IT, forgotten subdomains, unauthorized cloud servers, exposed services, weak authentication, outdated software, and encryption problems. - A 2025 study of 15,896 breached organizations found that major posture gaps made companies: - 5.3 times more likely to experience ransomware. - 3.6 times more likely to suffer a data breach. ## Combining Discovery with Cloudflare Protection - RiskRecon identifies security gaps, while Cloudflare provides controls to address them. - Discovered assets can be routed through Cloudflare’s proxy without changing the underlying application or website. - In a sample covering approximately 388,000 organizations and 18 million systems, Cloudflare-proxied systems showed: - 53% fewer software vulnerabilities. - 58% fewer SSL/TLS issues. - 98% fewer instances of malicious behavior. ## Finding Shadow Domains and Unprotected Hosts - Cloudflare Security Insights already detects issues for domains that are proxied through Cloudflare, including DNS errors, weak encryption, and inactive WAF rules. - The Mastercard integration will extend visibility to domains and hosts that Cloudflare does not yet know about or protect. - RiskRecon continuously profiles organizations’ Internet footprints and identifies associated domains, hosts, and software stacks. - Assets will receive criticality ratings: - **High:** Sensitive-data systems, authenticated applications, databases, or remote-access services. - **Medium:** Brochure sites adjacent to high-criticality systems. - **Low:** Brochure sites with no proximity to critical systems. ## Turning Findings into Remediation - Security Insights is designed to recommend concrete fixes rather than only report vulnerabilities. - Suggested actions may include: - Enabling the Cloudflare proxy for discovered zones and hosts. - Activating WAF, DDoS, and bot protection. - Enforcing stronger TLS settings. - Applying controls such as API Shield or specific WAF rules. - Future plans include risk scoring and AI-assisted diagnosis that correlates findings with traffic and recommends targeted configurations. ## Availability - The planned integration is expected to enter preview in the third quarter of 2026 for Information Security practitioners on pay-as-you-go and Enterprise accounts. The partnership’s practical goal is to help organizations discover assets they did not know existed, prioritize the most dangerous exposures, and protect them through Cloudflare before attackers exploit them.

Read original(opens in new tab)
CloudflareWeb Application FirewallMastercardRemote Access+4
cloudflare3 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)
CloudflareDatabase DesignNode.JsBug Bounty+3
cloudflare3 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
cloudflare3 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)
CloudflareDatabase DesignPostgreSQLZero Trust+4
cloudflare2 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
cloudflare2 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
cloudflare2 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
cloudflare3 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)
CloudflareAIZero TrustData Loss Prevention+4
cloudflare2 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
cloudflare3 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)
CloudflareLarge Language ModelsMachine LearningCloudflare Workers+4
cloudflare3 min readCurated summary

See risk, fix risk: introducing Remediation in Cloudflare CASB

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

Read original(opens in new tab)
CloudflareDatabase DesignAPISaas+4
cloudflare3 min readCurated summary

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

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

Read original(opens in new tab)
CloudflareCloudflare WorkersZero TrustNetwork Security+4
cloudflare3 min readCurated summary

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

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

Read original(opens in new tab)
CloudflareVulnerability ManagementApplication SecurityWeb Application Firewall+3
cloudflare2 min readCurated summary

Introducing Markdown for Agents

AI agents increasingly need structured, efficient access to web content, making traditional HTML a costly format for machine consumption. Cloudflare’s Markdown for Agents lets enabled websites serve HTML pages as Markdown when clients request `text/markdown`, reducing token usage and parsing overhead. The post argues that websites should treat AI agents as first-class visitors alongside humans and search engines. ## Why Markdown Matters for AI - Markdown conveys document structure with far less surrounding markup than HTML. - A Markdown heading such as `## About Us` uses roughly 3 tokens, compared with 12–15 tokens for an equivalent HTML heading. - The post’s HTML uses about 16,180 tokens, while its Markdown version uses approximately 3,150—a reduction of about 80%. - Converting HTML to Markdown inside an AI pipeline adds computation, cost, and complexity, and may not preserve the publisher’s intended structure. ## How Markdown for Agents Works - Cloudflare-enabled zones can respond to content negotiation requests containing: ```http Accept: text/markdown ``` - Cloudflare fetches the original HTML from the origin, converts it to Markdown at the network edge, and returns the converted response. - Clients can request Markdown with `curl`, while Workers-based agents can use a `fetch()` request with `Accept: "text/markdown, text/html"`. - Responses use `Content-Type: text/markdown` and include `Vary: accept`. - Existing coding agents, including Claude Code and OpenCode, already send compatible `Accept` headers. ## Token Estimates and Agent Workflows - Converted responses include an `x-markdown-tokens` header. - Agents can use this estimate to: - Determine whether content fits within a context window - Plan chunking strategies - Manage processing costs and limits ## Content Signals - Markdown responses include: ```http Content-Signal: ai-train=yes, search=yes, ai-input=yes ``` - These signals indicate that the content may be used for AI training, search results, and AI input, including agentic applications. - Cloudflare says future versions will support custom Content Signal policies. ## Availability - Cloudflare enabled Markdown for Agents on its Developer Documentation and Blog. - AI crawlers and agents can test the feature by requesting those pages with `Accept: text/markdown`. Web publishers can make their content more accessible to AI systems by supporting Markdown negotiation, while agents should request `text/markdown` whenever available to reduce tokens, parsing work, and processing cost.

Read original(opens in new tab)
CloudflareAI AgentsCloudflare WorkersMarkdown+4
cloudflare2 min readCurated summary

How we mitigated a vulnerability in Cloudflare’s ACME validation logic

Cloudflare disclosed and patched a vulnerability in its ACME HTTP-01 validation logic. Certain challenge requests could disable Web Application Firewall (WAF) protections even when Cloudflare was not serving the requested validation token, allowing the request to reach the customer’s origin without normal WAF processing. The issue was reported through Cloudflare’s bug bounty program, and Cloudflare found no evidence of exploitation; customers do not need to take action. ## ACME HTTP-01 Validation - ACME automates the issuance, renewal, and revocation of TLS certificates. - For HTTP-01 validation, a certificate authority checks for a token at: - `/.well-known/acme-challenge/{token}` - When Cloudflare manages the certificate order, it serves the expected token directly. - If the token is not associated with a Cloudflare-managed order, the request may be forwarded to the customer’s origin for validation by another system. ## The Logic Flaw - Cloudflare temporarily disabled certain WAF features for matching ACME challenge requests. - This was necessary because WAF processing could interfere with certificate authorities retrieving valid challenge tokens. - The flaw occurred when a request matched an active token associated with a different zone rather than the requesting hostname. - In that case, Cloudflare disabled WAF protections but forwarded the request to the origin instead of serving an ACME response. - This created a path where requests could bypass applicable WAF rulesets. ## Mitigation - Cloudflare released a code change restricting security-feature bypasses. - WAF features are now disabled only when: - The request matches a valid ACME HTTP-01 token for the requested hostname, and - Cloudflare has the corresponding challenge response to serve. - Requests that do not meet these conditions continue through normal security processing. ## Disclosure and Customer Impact - FearsOff researchers reported the vulnerability on October 13, 2025, through Cloudflare’s bug bounty program. - Cloudflare patched the issue and reported no evidence of malicious exploitation. - Customers require no configuration changes or other action. Cloudflare’s recommended outcome is continued use of the platform without customer intervention, while its security team emphasizes responsible disclosure and rapid, transparent remediation.

Read original(opens in new tab)
CloudflareNetwork SecurityWeb Application FirewallSsl Tls+3