cloudflareJul 17, 2026

Cloudflare WAF protects WordPress applications from two high-severity vulnerabilities (opens in new tab)

Cloudflare has deployed WAF protections for two serious WordPress vulnerabilities: a high-severity SQL injection and a critical unauthenticated remote code execution flaw. The rules protect proxied WordPress sites on both free and paid Cloudflare plans, but they only reduce exposure while sites are patched. WordPress updates remain essential, with fixes available in versions 6.8.6, 6.9.5, 7.0.2, and 7.1 Beta 2. ## Vulnerabilities and Affected Versions - **CVE-2026-60137 — SQL injection** - Affects WordPress 6.8 and later. - Crafted input can alter database queries. - Rated High. - **CVE-2026-63030 — Unauthenticated RCE** - Affects WordPress 6.9 and later. - Exploits the REST API batch endpoint when persistent object caching is not enabled. - Requires no authentication or user interaction. - Rated Critical. - Versions earlier than 6.8 are not affected. - WordPress 6.8.6 fixes the SQL injection; later listed releases fix both vulnerabilities. ## Cloudflare WAF Protections - Cloudflare deployed the protections at **17:03 UTC on July 17, 2026**. - Both rules are enabled with a default **Block** action: - SQL injection rule: `1c060d3a371549219ee290d7ed933fcc` for Managed Rules and `db003b39b7774859a8d588ce33697a1a` for the Free Ruleset. - RCE rule: `7dfb2bd4708d4b88b9911dc0550664b6` for Managed Rules and `ebd3f2df15c74ddcbf6220c9b5ec246a` for the Free Ruleset. - The SQL injection rule blocks malicious parameter values before they reach WordPress. - The RCE rule targets requests attempting to access the vulnerable REST API path. ## Customer Actions - Pro, Business, and Enterprise customers should ensure Cloudflare Managed Rules are enabled. - Free-plan customers receive protection automatically through the Free Ruleset. - Review ruleset overrides, especially configurations that change blocking to logging. - Monitor Cloudflare Security Events for requests matching either rule. - Confirm that WordPress automatic updates succeeded and that the site runs a patched release. ## Ongoing Protection Cloudflare will monitor matching traffic and refine detections as attackers develop new variations. The WAF rules provide defense in depth, but they cannot repair vulnerable WordPress code. Administrators should patch WordPress immediately, verify that both WAF rules remain active with the **Block** action, and investigate suspicious requests if updating is temporarily impossible.

web-application-firewallcloudflarevulnerability-managementrest-api+3

cloudflareJun 10, 2026

Route public traffic to private applications with Cloudflare (opens in new tab)

Cloudflare is extending its application security, performance, and programmability services to applications hosted on private networks. Its new Application Services for Private Origins allows public traffic to reach private origins through existing connectivity such as IPsec, GRE, Cloudflare Tunnel, CNI, or Cloudflare Mesh—without public IP exposure, inbound firewall rules, or `cloudflared` on the origin. The feature is entering closed beta for eligible Enterprise customers. ## Unifying Public and Private Application Traffic - Private applications—including internal APIs, AI backends, MCP servers, and operational tools—can now use: - WAF - Bot management - Rate limiting - Caching - Traffic acceleration - Rewrites - Workers - Cloudflare treats private IPs as valid origin targets for public hostnames. - The model supports four traffic combinations: - Public users to public applications - Private users to public applications - Public users to private applications, which is shipping now - Private users to private applications, planned for the future ## Reusing Existing Private Connectivity - The feature builds on Cloudflare’s existing private networking layer. - Supported connectivity models include: - Cloudflare Tunnel - Cloudflare One Client - IPsec and GRE tunnels - CNI links - Cloudflare Mesh - Customers can manage routing through Cloudflare’s dashboard and APIs rather than maintaining separate networking stacks. - Workers VPC bindings and Spectrum private-origin routing also use this shared connectivity layer. ## Application Services for Private Origins - Customers can enable **Use private network routing** on a proxied A or AAAA DNS record. - Cloudflare continues applying WAF, rate limiting, caching, bot management, and transform rules at its edge. - Only the final connection differs: Cloudflare sends traffic through the customer’s private network instead of over the public Internet. - Private routing is automatically enabled for: - RFC 1918 IPv4 ranges such as `10.0.0.0/8` - RFC 6598 CGNAT ranges such as `100.64.0.0/10` - RFC 4193 IPv6 unique-local addresses such as `FC00::/7` - Public IPs reachable only through a private network can be configured manually. ## API Configuration - Private routing is represented as an additional DNS record attribute: ```json { "type": "A", "name": "app.example.com", "content": "10.0.0.50", "ttl": 300, "proxied": true, "use_private_routing": true } ``` - Cloudflare’s Origin API returns the `use_private_routing` flag. - When the proxy sees that flag, it passes the request to Cloudflare’s private networking layer, which selects the appropriate private path. ## Beyond HTTP - The same routing approach supports non-HTTP services. - Potential origins include: - TCP databases - UDP logging endpoints - Private APIs accessed by Workers - Spectrum can extend the model to TCP and UDP services, while Workers VPC enables direct access from serverless code. Cloudflare’s recommendation is effectively to use existing private connectivity as the transport layer while centralizing application security, performance, and routing at Cloudflare’s edge. The feature is currently limited to eligible Enterprise customers in closed beta.

web-application-firewallcloudflarecloudflare-workerszero-trust+3

cloudflareJun 9, 2026

Defend against frontier cyber models: Cloudflare's architecture as customer zero (opens in new tab)

Frontier cyber models primarily change the speed and scale of attacks, not the fundamental stages of intrusion. They can rapidly discover vulnerabilities, generate exploit variations, and adapt around defenses, making architectural resilience more important than patch speed alone. Cloudflare’s approach is to use layered controls, limit the reach of compromised identities, and turn broad network visibility into faster defensive action. ## What Frontier Cyber Models Change - Models such as Mythos can accelerate: - Vulnerability discovery across large codebases and open-source dependencies - Exploit-chain reasoning - Proof-of-concept generation - Reconnaissance and attack variation - Traditional intrusion stages—reconnaissance, initial access, lateral movement, persistence, and exfiltration—remain, but attackers can execute them faster and at greater scale. - Attackers need only one exploitable opening, while defenders must identify and secure all of them. - AI-generated fixes can introduce regressions, meaning faster patch creation does not eliminate testing and review constraints. ## Three Threats Driving the Architecture ### Faster Vulnerability Discovery - Frontier models can search widely used open-source libraries and frameworks at scale. - A library flaw is only exploitable when attacker-controlled input can reach the vulnerable code and surrounding protections are insufficient. - The most concerning risk is the gap between attacker discovery and defender awareness. - Organizations should assume attackers are already using these models against their code if they are not doing so themselves. ### Higher Exploit Volume and Adaptation - Models can generate thousands of exploit variants and conduct reconnaissance at comparable scale. - Signature-based defenses may still block many variants sharing the same underlying pattern. - The greater danger is adaptive behavior: a model can probe a WAF, learn which payloads are blocked, and rewrite attacks until they evade the rule. ### Limiting Impact After Exploitation - No security architecture prevents every compromise. - The critical question is how far an attacker can move using a single identity, route, or credential. - If one compromise provides unrestricted access, the surrounding architecture—not just the original vulnerability—is the fundamental weakness. ## Visibility as a Defensive Advantage - Cloudflare observes roughly one-fifth of global web traffic, providing real-time insight into: - Mutating attack payloads - Emerging patterns - New attacker tooling and campaigns - Cloudforce One converts this network visibility into threat intelligence, tracked adversaries, campaigns, and indicators of compromise. - The key challenge is reducing the delay between discovering a threat and applying an effective mitigation across defensive systems. ## Practical Recommendation Organizations should run frontier models against their own code, strengthen layered detection, and design systems so that a single compromised identity or credential cannot provide unrestricted access. Architecture, containment, and rapid use of threat intelligence are essential complements to patching.

web-application-firewallcloudflarevulnerability-managementai-security+2

cloudflareApr 6, 2026

How we built Organizations to help enterprises manage Cloudflare at scale (opens in new tab)

Cloudflare’s new Organizations feature helps enterprises centrally manage users, policies, accounts, and analytics across multiple Cloudflare Accounts. It preserves least-privilege access by allowing teams to remain separated while giving designated organization administrators broader oversight. Initially available in public beta for enterprise customers, Organizations is designed to reduce administrative complexity without granting unauthorized access. ## Why Enterprises Use Multiple Accounts - Separate accounts help teams manage their own resources and limit permissions. - Fine-grained RBAC can still be cumbersome when administrators must enumerate individual resources. - Central administrators currently need access to every account for reporting and policy management. - This setup is fragile because account-level administrators can remove those central administrators. ## Organization Structure and Account Management - Organizations add a management layer above individual Cloudflare Accounts. - The core feature is a flat list of accounts onboarded into the organization. - An account can be added only by someone who is a Super Administrator for that account. - Organizations are built on Cloudflare’s existing Tenant system, originally developed for partners. ## Organization Super Administrators - Org Super Administrators have Super Administrator permissions across every account in the organization. - They do not need memberships in child accounts and do not appear in account-level user interfaces. - The new role is the first of several planned organization-level roles. - Cloudflare consolidated legacy authorization paths into domain-scoped roles. - The permissions overhaul added approximately 133,000 lines of code and removed 32,000. - Permission checks for enumeration endpoints such as `/accounts` and `/zones` became 27% faster, especially for users with access to thousands of accounts. ## Organization-Wide Analytics - Org Super Administrators can view aggregated HTTP traffic analytics. - The dashboard combines data across all accounts and zones in the organization. - Cloudflare plans to add analytics for additional products over time. ## Shared Configurations - Organizations allow centrally managed policy sets to be shared across accounts. - Initial examples include WAF and Gateway policies. - Authorized users in the source account can update shared policies for the broader enterprise. - Security analysts can therefore manage enterprise-wide WAF rules without becoming organization or account administrators everywhere. ## Roadmap and Availability - The beta initially targets enterprise customers. - Cloudflare plans to expand access to pay-as-you-go and other customers, followed by the partner ecosystem. - Planned capabilities include: - Organization-level audit logs - Billing reports - More analytics dashboards - Additional organization user roles - Self-service account creation ## Security-First Rollout - Cloudflare will not automatically create organizations through account backfilling. - A self-service invitation process ensures that no user gains access without approval from a relevant Super Administrator. - The first eligible Super Administrator to claim the company’s organization can add other accounts where they also hold Super Administrator access. - If another employee has already claimed the organization, administrators must coordinate invitations or account-level approval. - Cloudflare Support will not configure organizations on customers’ behalf. Enterprise customers can claim an organization from the Cloudflare Dashboard’s Organizations tab at no additional cost. Companies should coordinate internally with their Super Administrators to ensure all relevant accounts are added securely.

web-application-firewalldatabase-designcloudflareanalytics+4

cloudflareMar 18, 2026

Introducing Custom Regions for precision data control (opens in new tab)

Cloudflare is expanding Regional Services with three new managed regions—Turkey, the UAE, and IRAP—and introducing Custom Regions. The feature lets customers define exactly where TLS termination and Layer 7 processing occur while still using Cloudflare’s global network for traffic ingestion and DDoS protection. This combines local data-sovereignty control with globally distributed security and performance. ## Global Security with Local Compliance - Traffic enters through the nearest Cloudflare data center, where Cloudflare applies global-scale Layer 3 and Layer 4 DDoS protection. - Before decryption, request metadata is inspected and traffic is routed over Cloudflare’s private backbone to a data center inside the customer’s designated region. - TLS termination and Layer 7 services—including WAF, Bot Management, and Workers—run only within that region. - After processing, traffic is re-encrypted and sent securely to the origin. - This design localizes data inspection without forcing customers to sacrifice Cloudflare’s global attack-mitigation capacity. ## Expanded Cloudflare Managed Regions - Regional Services originally supported the EU, UK, and U.S. - Cloudflare now offers 35 predefined regions. - Newly added options include: - Turkey - United Arab Emirates - IRAP, supporting Australian compliance - ISMAP, supporting Japanese compliance ## Custom Regions - Customers can define their own geographical boundaries instead of selecting only Cloudflare-managed regions. - Custom Regions support: - Individual countries - Arbitrary combinations of countries - Regions that exclude specified countries - Early-access use cases include: - Keeping AI prompts and responses within selected countries - Running country-specific promotions - Meeting government contractual requirements - Aligning regions with corporate structures such as EMEA, MENA, or APAC - Example definitions include North America, everywhere except North America, or countries where Fahrenheit is commonly used. ## How Region Enforcement Works - A region represents a set of Cloudflare data centers. - Managed regions use Cloudflare-defined membership. - Custom Regions use expressions, commonly based on the data center’s ISO country code: - `country_code == "TR"` selects Turkey. - `country_code in ["DE", "FR", "NL"]` selects Germany, France, and the Netherlands. - Negated expressions can exclude specific countries. - The same Regional Services architecture applies regardless of who defines the boundary; Custom Regions simply give the customer control over the membership rules. Custom Regions are best suited to organizations with precise sovereignty, compliance, performance, or organizational requirements. They provide fine-grained control over where sensitive traffic is decrypted and processed while preserving Cloudflare’s global network protections.

web-application-firewallcloudflareai-inferenceddos-mitigation+4

cloudflareMar 10, 2026

Translating risk insights into actionable protection: leveling up security posture with Cloudflare and Mastercard (opens in new tab)

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.

web-application-firewallcloudflaremastercardremote-access+4

cloudflareMar 4, 2026

Always-on detections: eliminating the WAF “log versus block” trade-off (opens in new tab)

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.

web-application-firewallcross-site-scriptingsql-injectionsecurity-analytics+4

cloudflareFeb 27, 2026

Toxic combinations: when small signals add up to a security incident (opens in new tab)

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.

web-application-firewallcloudflarevulnerability-managementapplication-security+3

cloudflareJan 30, 2026

Google’s AI advantage: why crawler separation is the only path to a fair Internet (opens in new tab)

Google’s dominance in search gives it a structural advantage in generative AI: publishers must allow Googlebot to preserve search visibility, while Google can also reuse that access for AI products. The authors argue that this blurs search indexing and AI data collection, deprives publishers of traffic and compensation, and disadvantages competing AI companies. They support the CMA’s proposed UK conduct rules but say the only fair solution is to separate crawling for search from crawling for generative and agentic AI. ## CMA’s Strategic Market Status designation - The UK’s Digital Markets, Competition and Consumers Act 2024 allows the CMA to designate firms with substantial, entrenched market power as having Strategic Market Status. - In October 2025, Google received this designation for general search and search advertising, where it holds roughly 90% of the UK market. - The designation covers AI Overviews and AI Mode, allowing the CMA to impose legally enforceable conduct requirements on Google’s search ecosystem. - The authors view the CMA’s consultation as an important first step toward clearer rules for AI crawling and publisher control. ## Problems with Google’s dual-purpose crawler - Publishers cannot realistically block Googlebot because doing so could reduce their visibility in Google Search and damage advertising revenue. - Google uses the same search access not only for indexing and referrals, but also to ground AI Overviews, AI Mode, and broader generative AI services. - These AI features may reproduce publisher content while sending little or no traffic back to the original sites. - This threatens ad-supported publishing models and can put Google in direct competition with the publishers whose content it uses. - Unlike other AI companies, Google can obtain large amounts of content without negotiating payment, because publishers are effectively unable to refuse its search crawler. ## Google’s crawling advantage Cloudflare’s data indicates that Googlebot accesses substantially more unique pages than other major AI crawlers: - About 1.7 times more than ClaudeBot and GPTBot. - About 3 times more than Meta-ExternalAgent. - About 3.3 times more than Bingbot. - About 5.1 times more than Amazonbot. - Nearly 15 times more than Applebot. - Nearly 167 times more than PerplexityBot. - More than 700 times more than CCBot. - More than 1,800 times more than archive.org_bot. - Googlebot crawled roughly 8% of the sampled unique URLs during the two-month observation period. ## Limits of robots.txt and the need for separate controls - Publishers are much less likely to block Googlebot in `robots.txt` because of its importance for search referrals. - `robots.txt` expresses preferences but does not technically enforce crawler behavior; publishers must rely on bots to comply. - Web Application Firewalls can technically block unwanted crawlers, but this does not solve the core problem when search and AI access are tied to the same Googlebot identity. - The authors therefore argue that publishers need a meaningful, independent way to permit Google Search indexing while refusing the use of their content for generative AI. The proposed CMA rules should go further by requiring effective separation between search crawling and AI crawling. Publishers should be able to opt out of generative AI use without sacrificing search visibility, creating fairer conditions for content creators and competing AI developers.

web-application-firewallgen-aiagentic-aiweb-crawling+3

cloudflareJan 19, 2026

How we mitigated a vulnerability in Cloudflare’s ACME validation logic (opens in new tab)

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.

web-application-firewallcloudflarenetwork-securityssl-tls+3