cloudflare·Jul 17, 2026·2 min readCurated summary

Cloudflare WAF protects WordPress applications from two high-severity vulnerabilities

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.

Read original(opens in new tab)

CloudflareVulnerability ManagementRest ApiWeb Application Firewall+3

cloudflare·Jul 14, 2026·3 min readCurated summary

A broken DNSSEC rollover took down .AL. Now 1.1.1.1 tells you when validation is bypassed

A failed DNSSEC key rollover at Albania’s `.AL` registry caused validating resolvers to return errors for every `.AL` domain. Cloudflare temporarily installed a Negative Trust Anchor (NTA) to restore access, suspending DNSSEC validation while the registry fixed the issue. To make this bypass visible, 1.1.1.1 began returning a new Extended DNS Error (EDE) code alongside affected responses. ## What Happened to `.AL` - Around 14:15 UTC on July 3, the registry published a new DNSKEY and stopped serving the old key. - The root zone’s DS record still referenced the old key (`id=26319`), breaking the DNSSEC chain of trust. - Around 17:00 UTC, the new DNSKEY was also removed, leaving `.AL` with no DNSKEY records. - At approximately 19:15 UTC, the DS record was removed from the root zone, restoring normal resolution but leaving the entire TLD unsigned. - The outage affected government services, banks, media, and any other `.AL` domain accessed through DNSSEC-validating resolvers. ## Why Negative Trust Anchors Were Used - An NTA, defined by RFC 7646, tells recursive resolvers to treat a zone as unsigned and skip DNSSEC validation. - Cloudflare applied an NTA to `.AL` at 17:15 UTC, restoring resolution for 1.1.1.1 users. - The measure was considered acceptable because the failure was public, confirmed, and affected validating resolvers broadly. - Communication with the registry was difficult because its contact addresses were themselves hosted under `.AL`. - The NTA was removed the following day after the DS record had been removed from the root zone. ## The Security Tradeoff - NTAs prevent widespread `SERVFAIL` responses but remove cryptographic protection against DNS spoofing. - Previously, clients could not distinguish an NTA-served response from a fully DNSSEC-validated response. - Public status pages provide disclosure, but applications, monitoring systems, and users cannot reliably discover the bypass from DNS responses alone. ## EDE-Based Transparency - Extended DNS Errors, defined in RFC 8914, let resolvers attach explanatory information to DNS responses. - Cloudflare implemented a proposed EDE code, “Negative Trust Anchor,” developed with Quad9 contributors. - During the incident, `.AL` responses included: - EDE 9: `DNSKEY Missing`, explaining the broken DNSSEC chain. - EDE 33: `Negative Trust Anchor`, explicitly stating that validation had been bypassed. - A query such as `google.al` could therefore return a successful answer while clearly indicating that it was not DNSSEC-validated. Resolvers and applications should use EDE information where possible, while DNS operators should disclose NTAs and remove them promptly once the underlying DNSSEC problem is resolved.

Read original(opens in new tab)

CloudflareDnsDnssecNegative Trust Anchor+2

cloudflare·Jul 13, 2026·3 min readCurated summary

Introducing Precursor: detecting agentic behavior with continuous client-side signals

Precursor is Cloudflare’s new client-side, session-based system for detecting bots and agentic automation through continuous behavioral signals. Unlike one-time challenges, it evaluates interactions across an entire user journey, making automation harder to imitate while reducing friction for legitimate users. It complements Turnstile by extending behavioral detection beyond sensitive checkpoints such as login, signup, and checkout. ## The Visibility Gap in Bot Detection - Cloudflare analyzes more than 1 trillion requests daily across over 20% of the web. - Turnstile runs nearly 3 billion times per day and provides risk-based verification at important application endpoints. - However, point-in-time challenges offer limited insight into how users and bots behave throughout the rest of a session. - Precursor addresses this gap by continuously observing interactions across an application. ## Why Session Behavior Matters - Modern bots can execute JavaScript, operate real browsers, and pass individual CAPTCHAs. - Sustaining believable behavior over a complete session is substantially more difficult. - Precursor uses accumulated behavioral signals to improve detection precision. - This can reduce unnecessary challenges for legitimate users while increasing the cost and complexity of bot operations. ## Human and Automated Interaction Patterns - Human mouse movement reflects physical and cognitive constraints: - Wrist and forearm movement produce curved paths. - Clicking involves a delay after seeing an interface element. - Hand tremors create subtle physiological oscillations. - Automated interactions often reveal: - Straight-line movement or mathematically ideal curves. - Unusually precise clicks. - Repeated velocities, origins, timing, and movement rhythms. - Individual actions may appear plausible, but patterns across a full session can expose automation. ## How Precursor Works ### Injection and Data Collection - Cloudflare dynamically injects a compact, obfuscated JavaScript bundle into HTML responses passing through its network. - No additional configuration, third-party embedding, or network connection is required. - The script observes signals such as: - Pointer movement - Keyboard timing and activity - Focus changes - Page visibility - Events are serialized, buffered in memory, and periodically sent for analysis. ### Edge-Side Evaluation - Cloudflare deserializes the incoming data and runs multiple evaluators against the behavioral streams. - Evaluators cross-reference signals to identify inconsistencies. - Examples include checking whether: - Pointer activity matches page visibility duration. - Keyboard events occur while a text field is focused. - The results are consolidated into detection signals that influence bot scoring. ### Session Integration - Signals accumulate across the session rather than resetting with a page refresh or new challenge. - Session metadata also supports: - Shadow-mode heuristics - Session analysis - Predicted-versus-actual completion comparisons - Session delinquency heuristics - These observations help improve detection and adjust a session’s bot score. ## Privacy by Design - Precursor collects only information considered necessary for detecting automation and abuse. - Keyboard behavior is recorded as timing and rhythm, not the actual keys pressed. - Signals are evaluated as aggregate behavioral patterns. - Data is used internally by Cloudflare’s detection systems and is not exposed in customer dashboards or linked to accounts, identities, or persistent profiles. ## Session-Based Analytics - Cloudflare is introducing session-oriented views in Security Analytics alongside Precursor. - These views shift analysis from isolated requests to complete visitor journeys. - The provided article excerpt ends while beginning to describe these dashboards. Precursor is best understood as a complement to Turnstile: continuous, privacy-conscious session analysis can detect automation that passes individual challenges while reducing reliance on aggressive interruptions for genuine users.

Read original(opens in new tab)

JavaScriptBot ManagementBot DetectionBehavioral Analysis+3

cloudflare·Jul 10, 2026·3 min readCurated summary

Improving Smart Tiered Cache for public cloud regions

Cloudflare’s Smart Tiered Cache efficiently routes cache misses through one optimal upper-tier data center, but anycast and regional cloud origins make latency-based selection unreliable. Smart Tiered Cache for Public Cloud Regions addresses this by using a customer-provided cloud region hint to choose geographically appropriate primary and fallback tiers. The result is better cache efficiency, fewer origin requests, and reduced cross-continent “hairpin” traffic. ## Smarter Tiered Cache Topology - Smart Tiered Cache is available on all Cloudflare plans at no additional cost. - It selects a single upper tier based on real-time latency when an origin has a fixed, unicast IP. - Previous enhancements added support for: - **R2**, selecting an upper tier near the bucket’s actual location. - **Load Balancing**, selecting one tier for an entire pool so origins share cache content. - The new feature extends this approach to public cloud origins hosted on AWS, GCP, Azure, and Oracle Cloud. ## Why Anycast Origins Cause Problems - Anycast and regional unicast IPs represent cloud provider front ends rather than one physical origin location. - Multiple Cloudflare data centers may appear equally close to the same IP, preventing reliable selection of one upper tier. - The wrong selection can cause hairpin traffic. For example, an origin in Singapore might be assigned to an upper tier in Chicago, forcing Asian users’ requests across the Pacific and back. - This can add hundreds of milliseconds, increase origin connections, and reduce cache hit ratios. - Cloudflare detects likely anycast origins by comparing probe latencies against the physical limits imposed by the speed of light. - When anycast is detected without additional information, Smart Tiered Cache safely uses multiple upper tiers instead of pinning traffic to one. ## Configuring a Cloud Region Hint - In the dashboard, go to **Caching > Tiered Cache > Origin Configuration**. - Select an origin IP and choose **Set Region Hint**. - Enter a region such as: - `aws:us-east-1` - `gcp:europe-west1` - Hints can be configured individually or applied in bulk. - The same configuration is available through the API and Terraform. - Dashboard hints are currently available only for IPs Cloudflare has identified as anycast. - The initial release supports AWS, GCP, Azure, and Oracle Cloud, with more providers planned. ## How Region-Based Selection Works - Cloudflare periodically downloads each provider’s current IP range files. - These files map cloud regions to their active IP prefixes, allowing Cloudflare to track subnet changes. - Cloudflare matches those prefixes against an upper-tier database updated through latency probing every 15 minutes. - Each matching subnet contributes a weighted vote for its current upper-tier assignment. - The strongest signal determines the region’s primary upper tier. - Primary and fallback tiers are always placed in different Cloudflare points of presence to avoid a single-PoP failure eliminating both options. ## Practical Recommendation For public cloud origins behind anycast or regional unicast IPs, configure the correct cloud region hint through the dashboard, API, or Terraform. This lets Smart Tiered Cache retain a single, nearby primary tier while maintaining a separate fallback, improving cache efficiency and avoiding unnecessary cross-region traffic.

Read original(opens in new tab)

CloudflareTerraformTiered CachingAnycast+3

cloudflare·Jul 9, 2026·4 min readCurated summary

Why we cannot wait for better post-quantum signature algorithms

RSA and elliptic-curve signatures will eventually be vulnerable to sufficiently powerful quantum computers, so organizations cannot delay migration until ideal post-quantum algorithms arrive. ML-KEM already protects much of Cloudflare’s traffic from “harvest now, decrypt later” attacks, while ML-DSA is currently the practical choice for post-quantum signatures despite its larger keys and signatures. Better schemes are being developed, but they will not be standardized and deployable in time for the initial transition. ## The urgency of post-quantum migration - NIST standardized ML-KEM encryption and ML-DSA signatures in 2024 after an eight-year international competition. - Cloudflare reports that most of its traffic already uses ML-KEM. - Post-quantum signatures are still needed to protect authentication systems from quantum-enabled attacks. - Cloudflare aims to be fully post-quantum secure by 2029. - The authors argue that deployment must begin with currently available algorithms: - “You go to war with the algorithms you have, not the ones you wish you had.” - Future signature research remains important because current options have substantial performance, size, and implementation drawbacks. ## Comparing the candidate signature algorithms - The candidates include: - Existing classical algorithms such as RSA and elliptic-curve signatures, which are quantum-vulnerable. - ML-DSA and other already standardized or soon-to-be-standardized post-quantum schemes. - Nine candidates advancing to the third round of NIST’s signatures on-ramp. - Comparisons focus on variants relevant to TLS at the 128-bit security level. - The measurements cover: - Public-key and signature sizes. - Signing and verification speed. - Implementation concerns and side-channel resistance. - Some algorithms have important operational limitations: - FN-DSA and SQIsign are difficult to implement with fast, timing-safe signing. - LMS requires state to be maintained securely between signatures. - Certain SLH-DSA variants are intended for only a limited number of signatures. ## No single post-quantum “all-star” - Ed25519 remains the strongest all-around performer when quantum resistance is ignored. - It offers particularly favorable: - Public-key size. - Signature size. - Signing speed. - Its verification is slower than some alternatives but remains fast enough for most applications. - Post-quantum schemes instead fall into two broad groups: - **Specialists:** Excellent on particular metrics but unsuitable for general use because of other weaknesses. - **Generalists:** More balanced schemes such as ML-DSA, which avoid extreme weaknesses but do not match elliptic curves overall. ## SQIsign: compact signatures with slow signing - SQIsign is attractive for bandwidth-sensitive applications: - 148-byte signatures. - 65-byte public keys. - Smaller than RSA-2048 and close to elliptic-curve sizes. - Its disadvantages include: - High mathematical and implementation complexity. - Slow signing and verification. - Difficulty achieving efficient, timing-side-channel-resistant signing. - Progress since 2024 has significantly simplified SQIsign and improved verification speed. - Secure signing is still unlikely to become fast enough for common online uses such as TLS handshakes. - It may be better suited to offline applications where signing is infrequent and verification matters more, including: - Certificate-authority signatures. - DNSSEC. - SQIsign is based on isogenies, a category that attracted concern after SIKE was catastrophically broken. - The authors distinguish the schemes: - SIKE already had known security concerns and used problematic torsion points. - SQIsign does not use those torsion points. - The best known SQIsign attacks are generic brute-force attacks, resembling attacks against well-chosen elliptic curves. - Isogeny mathematics still has a large attack surface, but the authors consider SQIsign’s security outlook stronger than that of structured multivariate schemes. - The authors see significant promise in SQIsign but caution against standardizing it prematurely. The practical recommendation is to begin the post-quantum transition with ML-DSA rather than waiting for smaller or faster alternatives. New schemes such as SQIsign may eventually serve specialized use cases, but they must undergo further cryptanalysis, standardization, implementation work, and deployment before they can replace today’s available algorithms.

Read original(opens in new tab)

Post Quantum CryptographyQuantum ComputingElliptic Curve CryptographyMl Kem+4

cloudflare·Jul 8, 2026·3 min readCurated summary

Introducing Meerkat- an experiment in global consensus

Cloudflare is building Meerkat, an experimental global consensus service for coordinating control-plane state across more than 330 data centers. It aims to provide linearizable reads and writes while remaining available despite machine failures, network degradation, and data-center outages. Meerkat uses QuePaxa rather than Raft because QuePaxa allows all replicas to write and does not halt progress while waiting for failure timeouts. ## The Challenge of Global Control-Plane State - Cloudflare services need to read and modify shared state from locations around the world. - Examples include: - Placement information for resources such as AI model instances. - Leadership information identifying which machine may write to a database. - The system must combine: - Strong consistency, so readers do not observe conflicting or stale state. - High availability, even when machines, links, queues, or data centers fail. - Wide-area networks are unpredictable, making replica synchronization difficult. ## Why Consensus Is Needed - Consensus algorithms allow machines to agree on a single ordered sequence of operations, such as key-value-store reads and writes. - A typical consensus system can continue safely as long as a majority of replicas remain alive and connected. - This provides a foundation for applications such as: - Transactional key-value stores. - Distributed leases and locks. - Database leadership management. ## Limitations of Raft in Wide-Area Networks - Raft depends on a leader, and only the leader can accept writes. - If the leader crashes or becomes unreachable, the system may become unavailable until a timeout triggers leader election. - Timeout configuration is especially difficult across global networks with unpredictable latency. - A single failed machine or degraded network link can therefore affect availability. - Cloudflare reports having experienced incidents caused by unavailable leaders in consensus-based systems. ## Strong Consistency and Linearizability - Consistency determines how concurrent reads and writes may be ordered or observed. - Weak consistency can allow writes to be reordered. - Stronger models may preserve write ordering while still allowing reads to observe different states. - Linearizability is the strongest model described: - Operations appear to occur in real-time order. - Every read after a completed write observes that write. - Linearizability lets developers reason about distributed state similarly to local memory on a single-threaded machine. - Meerkat’s planned key-value store also provides serializability, which Cloudflare says will be covered separately. ## Fault-Tolerance Requirements Meerkat is intended to remain available and correct under several classes of failure: - The system should support reads and writes from any data center when: - A majority of machines are alive and can communicate. - A client can reach a machine connected to that majority. - In a system of `2f + 1` machines, the design tolerates `f` faults. - Single-machine failures and individual network-link degradations should not interrupt availability. - The system must remain correct during: - Machine crashes and restarts. - Network failures and delays. - Data-center outages. - Up-to-date machines must never disagree about committed state. - Like Raft, Meerkat does not attempt to tolerate Byzantine faults or actively malicious participants. ## Introducing Meerkat and QuePaxa - Meerkat is being developed by Cloudflare Research as an internal, experimental consensus service. - It is powered by QuePaxa, a consensus algorithm published by EPFL researchers in 2023. - Unlike Raft: - Any replica can perform writes. - Progress does not stop because a timeout expires or a leader becomes unavailable. - Applications will be layered on Meerkat’s consensus log, initially focusing on small control-plane data. - The first use cases include database leadership and other coordination state. - Cloudflare describes this as the first planned industrial deployment of QuePaxa at global scale. - Meerkat will remain internal while it is still under development.

Read original(opens in new tab)

Distributed SystemsFault ToleranceKey Value StoreQuepaxa+4

cloudflare·Jul 7, 2026·3 min readCurated summary

Cloudflare proudly joins the UK government's Cyber Resilience Pledge

Cloudflare has joined the UK government’s voluntary Cyber Resilience Pledge, supporting its focus on security governance, board accountability, and supply-chain protection. The company argues that these principles align with its existing approach: make security broadly accessible, use network-scale intelligence, apply protections internally, and be transparent about failures. It presents collective action and stronger baseline controls as essential to addressing rising cyberattacks and AI-enabled threats. ## The Cyber Resilience Pledge - The pledge encourages organizations to adopt foundational cybersecurity governance and make resilience a leadership responsibility. - It promotes comprehensive security coverage across supply chains. - Its central principles include: - Democratizing access to security - Leadership accountability - Radical transparency - Cloudflare sees the pledge as validation of principles it has followed for more than a decade. - The company highlights the need to address common weaknesses such as: - Unpatched systems - Weak access controls - Poor vendor oversight ## Rising Cybersecurity Risk - Cloudflare blocked an average of 234 billion cyber threats per day during the first quarter of 2026. - It recently mitigated a DDoS attack peaking at 31.4 Tbps. - By the end of 2025, the UK was the sixth-most targeted location globally for DDoS attacks. - Threat actors increasingly targeted application-layer services in financial services, aviation, and regional government. - UK survey data found that 43% of businesses and 28% of charities experienced a cyber incident in the previous year. - Frontier AI models are making attacks easier to automate, including vulnerability scanning and convincing phishing campaigns. ## Why Cyber Resilience Matters - Resilience is a business requirement because customers expect services to remain available, responsive, and trustworthy. - It extends beyond recovering from incidents to proactively: - Monitoring threat signals - Absorbing disruptions - Adapting systems after failures - Cloudflare views security controls as the foundation that makes resilience possible. ## Cloudflare’s Resilience Architecture ### Security by Default - Cloudflare aims to make baseline protections available to organizations of all sizes. - Examples include: - SSL certificates for encrypted traffic - Unmetered DDoS protection on its free plan - CDN and DNSSEC access - Post-quantum cryptography deployment - Impact programs such as Project Galileo and the Athenian Project - This model is intended to help small businesses, startups, local authorities, and public services participate in the UK’s resilience efforts. ### The Network as a Sensor - Cloudflare peers directly with more than 13,000 networks worldwide. - Attack intelligence gathered in one location can become a protection rule for customers elsewhere within seconds. - This global visibility improves threat detection, scoring, and response across its services. ### Cloudflare as “Customer Zero” - Cloudflare uses its own security products and infrastructure to protect internal systems. - Employees access internal applications through Cloudflare Access and Gateway. - Internal requests require hardware-based MFA, device posture checks, and cryptographically verified identity tokens. - Testing security controls internally helps Cloudflare identify improvements before delivering them to customers. ### Transparency and Incident Response - Cloudflare publishes technical postmortems for security incidents and zero-day vulnerabilities. - It shares indicators of compromise, telemetry, and architectural lessons with the wider security community. - After a major outage, its “Code Orange” initiative focused on building systems that “fail small,” safer configuration tooling, and automated best practices. ## Cloudflare’s Pledge Commitments - The post begins describing the pledge’s requirements around: - Board responsibility and governance - Supply-chain security - Technical standards related to UK Cyber Essentials - The provided text ends before detailing Cloudflare’s specific implementation of these commitments. Organizations should treat cyber resilience as an ongoing governance and engineering responsibility, not an optional product feature. Raising baseline protections, sharing lessons from incidents, and securing supply chains can make the wider Internet safer and more dependable.

Read original(opens in new tab)

CloudflareZero TrustPost Quantum CryptographyCybersecurity+3

cloudflare·Jul 6, 2026·3 min readCurated summary

Your Worker can now have its own cache in front of it

Workers Cache places a tiered Cloudflare cache directly in front of a Worker, allowing cacheable responses to be served without running the Worker or incurring CPU time. It is enabled with a single Wrangler configuration block and controlled through standard HTTP headers such as `Cache-Control` and `Cache-Tag`. The feature gives server-rendered applications a middle ground between expensive per-request rendering and slow, rebuild-dependent static generation. ## How Workers Cache Works - Enable it in Wrangler with: ```json { "cache": { "enabled": true } } ``` - Cacheable requests are checked against Cloudflare’s cache before the Worker runs. - Cache hits return immediately without invoking the Worker or consuming CPU time. - Cache misses execute the Worker, and cacheable responses are stored for later requests. - Caching follows the Worker across: - Custom domains - `workers.dev` - Service bindings - Preview environments - Workers for Platforms tenants - Responses use familiar HTTP controls: - `Cache-Control` for TTL and behavior - `stale-while-revalidate` for background refreshes - `Vary` for content negotiation - `Cache-Tag` for targeted invalidation ## Purging Cached Content - Workers can purge their own cache programmatically: ```js await ctx.cache.purge({ tags: ["product:123"] }); ``` - Purging can target cache tags or path prefixes. - `ctx.props` supports cache keys that are safe for multi-tenant applications. ## Why Server-Rendered Apps Need This - Originally, Workers were positioned in front of an origin and Cloudflare’s cache. - Modern frameworks such as Astro, Next.js, Remix, SvelteKit, and TanStack Start often make the Worker the application’s origin. - Without a cache in front, every request runs application code, even when the response has not changed. - This creates recurring rendering latency and CPU costs for server-rendered pages. ## A Middle Ground Between Static and Dynamic Rendering - Static-site generation provides fast responses but requires rebuilding and redeploying whenever content changes. - Rendering every request keeps content current but imposes latency and compute costs on every visitor. - Workers Cache enables on-demand rendering: - The first request renders and caches the page. - Subsequent requests are served from cache. - Expiration triggers a fresh render according to the configured TTL. - This delivers static-like speed without framework-specific systems such as Incremental Static Regeneration. ## Stale-While-Revalidate - `stale-while-revalidate` allows Cloudflare to serve an expired response immediately while refreshing it in the background. - Without it, the first request after expiration waits for the Worker to render the page again. - With it: - Users receive the stale response instantly. - The response includes `Cf-Cache-Status: UPDATING`. - The Worker refreshes the cached response asynchronously. - A typical policy is: ```http Cache-Control: public, max-age=300, stale-while-revalidate=3600 ``` This keeps content fresh for five minutes while allowing stale content to be served for up to an additional hour during background refreshes. Workers Cache is available to all Workers on every plan. For server-rendered applications, enabling it and defining appropriate HTTP cache headers provides a simple way to reduce latency and execution costs while retaining controlled content freshness.

Read original(opens in new tab)

Cloudflare WorkersWranglerHttp CachingStale While Revalidate+2

cloudflare·Jul 1, 2026·3 min readCurated summary

Making AI search smarter

Cloudflare argues that AI-powered search has broken the traditional bargain in which publishers exchanged crawl access for traffic and revenue. AI summaries increasingly answer users’ questions without sending them to source sites, leaving publishers to choose between reduced visibility and uncompensated content use. The company proposes rebuilding this relationship through smarter crawling and payments tied to actual content usage. ## Rebuilding the Bargain - Cloudflare’s responsible AI bot principles emphasize: - Transparency about a bot’s identity and purpose - Respect for site owners’ choices - Good-faith behavior - Blocking unwanted crawlers protects publishers but does not create a sustainable business model. - Cloudflare’s broader goal is to make AI search beneficial to users, AI companies, and content creators. ## Making AI Search Smarter - Cloudflare is launching a research program using signals from its global network, which covers more than 20% of the web. - These signals may identify: - Which pages are fresh or have genuinely changed - Which content attracts human and automated traffic - Which sources are high quality and relevant - Answer engines could use this information to surface better content and avoid repeatedly crawling unchanged pages. - More than 50% of traffic from legitimate crawlers reportedly goes toward re-fetching unchanged pages. - Reducing unnecessary crawls would lower: - AI companies’ compute costs - Publishers’ server load and bandwidth expenses - The program is intended to be neutral, limited to search, and will not share content or train foundation models. - Cloudflare plans to publish results and make the capability broadly available later in the year. ## From Pay Per Crawl to Pay Per Use - Cloudflare’s existing Pay Per Crawl model lets publishers charge AI companies for accessing their content. - Cloudflare says crawling is an imperfect measure of value: - A page may be crawled once but cited in thousands of answers. - It may also be crawled repeatedly without ever being used. - The company is therefore experimenting with Pay Per Use, where compensation reflects how often content contributes to search results or answers. - Early partners include Ceramic.ai and You.com. - Ceramic’s pay-per-query model pays publishers when their content appears in Ceramic search results. - Cloudflare’s network is intended to help AI companies scale these payment systems across millions of participating content owners. Cloudflare’s proposed model combines efficient, change-aware crawling with compensation based on actual content use. If adopted broadly, it could give publishers better control, reduce needless infrastructure costs, and create a more sustainable economic relationship between AI search services and the web.

Read original(opens in new tab)

CloudflareBot ManagementAi SearchWeb Crawling+2

cloudflare·Jul 1, 2026·3 min readCurated summary

Announcing the Monetization Gateway: charge for any resource behind Cloudflare via x402

Cloudflare is introducing the Monetization Gateway, which will let customers charge for web pages, datasets, APIs, and MCP tools protected by Cloudflare. It combines payment rules, access control, metering, and payment verification at the edge, initially using stablecoins through the x402 protocol. The goal is to make low-cost, usage-based payments practical for AI agents without requiring sellers to build billing infrastructure or onboard every buyer. ## The Web’s Shift Toward Usage-Based Payments - The traditional web monetized human attention through advertising, subscriptions, and e-commerce. - AI agents consume resources without viewing ads or maintaining subscriptions, creating a need for pricing based on actual usage. - Potential models include: - Charging a few cents per search. - Combining a base fee with usage charges, such as per megabyte uploaded. - Charging only when an outcome succeeds, such as a resolved support escalation. - Agents may generate thousands of requests and micropayments, making per-request, per-token, or outcome-based pricing more appropriate than monthly or per-seat plans. - Existing usage billing has generally required API keys, known customers, extensive accounting systems, and costly payment infrastructure. - Stablecoins such as USDC and Open USD can support sub-cent payments with low fees and settlement times under a second. ## Cloudflare’s Role in Usage-Based Billing - Cloudflare can use its position as a proxy between buyers and sellers to combine payment verification with the request path. - Metering, payment exchange, and settlement can occur away from the customer’s origin. - Customers retain control over: - Pricing. - Access rules. - Revenue. - Sellers will not need to onboard each buyer or build a complete billing system; they can define rules that determine when agents must pay. ## How x402 Payments Work - x402 uses HTTP’s `402 Payment Required` status code to add payments directly to ordinary web requests. - The flow is: - A client requests a protected resource. - The server returns a 402 response containing the price, accepted asset, and payment destination. - The client pays and retries the request with proof of payment. - A facilitator verifies the payment. - The server returns the requested resource. - There are no checkout redirects or separate payment APIs. - Payments settle peer-to-peer directly into the seller’s wallet. - x402 is well suited to machine payments because: - It supports very small transactions. - Buyers do not need an account with the seller. - The payment itself acts as the access credential. - Stablecoins offer fast settlement, low fees, and no chargebacks. ## Monetization Gateway Capabilities - Customers will define payment policies through a dedicated rules API using expressions similar to other Cloudflare rules. - The system will apply to traffic such as tokens, APIs, MCP tool calls, and datasets. - Enforcement will run across Cloudflare’s network in more than 330 cities, allowing payment handshakes to occur near buyers while reducing latency and protecting origins. - Planned functionality includes charging for specific REST methods and routes, such as requiring $0.01 for each `GET` or `POST` request to `/api/premium/*`. - The gateway is also intended to support variable pricing for tasks with different costs. Cloudflare’s approach is to make micropayments a native part of HTTP access, enabling businesses to charge agents directly for the resources they consume without constructing their own payment and accounting systems.

Read original(opens in new tab)

AI AgentsModel Context ProtocolCloudflareAPI+4

cloudflare·Jul 1, 2026·4 min readCurated summary

Content Independence Day, one year on- building the business model for the agentic Internet

Cloudflare argues that generative AI has rapidly replaced the traditional web model in which publishers traded content access for search referrals. With AI now driving much of online discovery and crawler activity, content is increasingly consumed without users visiting its source. The company says a new market is emerging in which transparency, access controls, scarcity, and licensing can help publishers regain economic value. ## AI’s rapid transformation of the Internet - Generative AI adoption has reached more than 2.5 billion regular users—over 30% of humanity—in roughly 3.5 years, reportedly more than twice the adoption speed of smartphones. - Users now spend only about 15 minutes on the open web for every hour spent searching for information. - Instead of visiting and comparing multiple websites, users increasingly receive consolidated answers directly from AI systems. - More than 50% of Internet traffic is now non-human, marking the arrival of what Cloudflare calls the “agentic Internet.” ## Crawlers are increasingly focused on AI - AI training accounted for 52% of crawler requests in June 2026, up from 22% in spring 2025. - Mixed-use crawlers, combining search, agent activity, and training, represented more than 36% of crawler traffic. - Traditional search crawlers make up a smaller share of activity, even though they remain important for sending visitors to publishers. - Mixed-purpose crawling makes it difficult for site owners to remain visible to AI-driven discovery without also giving away content for training without compensation. ## The traditional web business model is breaking down - Historically, publishers allowed search engines to crawl their content in exchange for visibility and referral traffic. - AI systems now answer questions, conduct research, compare products, and complete tasks without necessarily sending users to original sources. - Content can therefore be crawled, indexed, and monetized by AI companies while the original publisher receives little or no traffic. - News and media organizations experienced the disruption first, but retail, software, IT, finance, and other sectors are also affected. - Some heavily crawled categories have seen human traffic fall by as much as 40% in under a year. - Publishers are preparing for “Google Zero,” in which search referrals provide little meaningful traffic. ## The impact extends across industries - Any organization publishing proprietary information online may need a strategy for AI access and monetization. - The issue affects not only traditional publishers but also businesses whose websites contain valuable product, technical, financial, or industry knowledge. - Cloudflare frames the sustainability of online content as an economic and public-interest concern because the Internet remains a major global information resource. ## Building a market for content Cloudflare says Content Independence Day focused on three goals: - Give site owners transparency and control over how their content is accessed and monetized. - Create scarcity by allowing publishers to restrict or selectively permit AI access. - Establish a marketplace where publishers and AI companies can discover, license, and price content. According to the post, these efforts have helped create the early conditions for a monetized content market. ## Control and data create negotiating power - Cloudflare’s attribution, business intelligence, and enforcement tools let publishers observe AI access at the network level. - These tools provide stronger practical enforcement than voluntary mechanisms such as `robots.txt`. - Publishers can identify: - How often LLMs attempt to access their content - Which competing AI systems are crawling their sites - Which URLs are most in demand - The relationship between crawling and referrals - Restricting or controlling access creates scarcity, which gives publishers leverage in licensing negotiations. - Better operational data reduces information asymmetry and allows content owners to negotiate with evidence rather than guesswork. Ultimately, the post recommends treating online content as an economic asset rather than an unlimited free input. Publishers should measure AI consumption, control access, and pursue licensing arrangements so that the agentic Internet can support content creation instead of undermining it.

Read original(opens in new tab)

AILarge Language ModelsGenerative AICloudflare+3

cloudflare·Jul 1, 2026·3 min readCurated summary

Your site, your rules: new AI traffic options for all customers

Cloudflare is replacing its broad “Block AI Bots” approach with finer controls based on what automated systems do: Search, Agent, or Training. The goal is to let website owners preserve discoverability and useful automation while blocking uncompensated model training and other unwanted access. These controls will be available to all Cloudflare customers, including Free-tier users. ## Why AI traffic needs more nuance - The traditional crawler exchange—content in return for referrals—has weakened as AI systems increasingly consume content without sending traffic back. - Website owners previously faced a binary choice: - Allow AI access to remain discoverable. - Block automation and protect content at the risk of losing visibility. - This tradeoff particularly harms small sites and can favor established search providers that use the same crawlers for search and training. ## A behavior-based AI taxonomy Cloudflare will classify automated traffic by its purpose rather than simply labeling bots as “AI”: - **Search** - Collects or indexes content to answer future queries. - Builds a database proactively. - Should generally provide referrals or other fair compensation. - **Agent** - Acts in real time on behalf of a person. - Includes chat-fetch bots such as ChatGPT-User and browser-use agents driven by Gemini or Claude. - Visits a site to complete a specific task for a human. - **Training** - Collects content to train or fine-tune a model. - Permanently incorporates data into the model’s underlying architecture. Bots may have multiple classifications. Cloudflare encourages operators to separate Search, Agent, and Training crawlers so site owners can understand and control their access more effectively. ## New controls for AI traffic - Cloudflare is adding separate controls for Search, Agent, and Training traffic. - These options replace the need for a single all-or-nothing AI blocking decision. - The controls will be available to all customers, including those on the Free plan. - Cloudflare will continue tracking other automated behaviors, such as ad verification, feed fetching, and agentic transactions. ## New default rules Starting September 15, 2026: - For new domains, **Training** and **Agent** crawlers will be blocked by default on pages displaying ads. - **Search** crawlers will remain allowed by default because they are more likely to send visitors back. - The policy treats ads as an indication that human attention—and therefore monetizable traffic—is the intended outcome. - Multi-purpose crawlers will be governed by all of their classifications, using the most restrictive applicable rule. - As a result, crawlers such as Googlebot, Applebot, and BingBot may be blocked when customers choose to block Training traffic. - Website owners can opt out of the new defaults through Cloudflare Security settings before September 15. Cloudflare’s recommendation is to manage AI access by behavior: allow Search when referrals matter, permit Agents when real-time user tasks are valuable, and block Training where content reuse is not adequately compensated.

Read original(opens in new tab)

AI AgentsCloudflareBot ManagementWeb Crawlers+3

cloudflare·Jul 1, 2026·2 min readCurated summary

Unmasking the crawls with Attribution Business Insights

Cloudflare argues that the traditional exchange between crawlers and publishers has broken down as AI bots extract content without sending meaningful referral traffic. This creates lost revenue for publishers while increasing hosting costs, making granular traffic attribution essential. Its new Attribution Business Insights dashboard aims to help site owners identify which bots provide value and make informed decisions about access, blocking, and commercial relationships. ## The Internet’s Changing Economics - Traditional search engines generally crawled content a few times for each visitor they referred. - That crawl-to-referral balance supported advertising, affiliate revenue, subscriptions, and direct audience relationships. - AI crawlers increasingly create a “zero-click” ecosystem by summarizing content without directing users to the original publisher. - Cloudflare observed AI crawl-to-referral ratios ranging from 118:1 to nearly 50,000:1. - Publishers face both reduced traffic-based revenue and higher infrastructure costs from unproductive automated access. ## Attribution Business Insights Dashboard - The dashboard is available to Cloudflare Bot Management customers. - It provides an immediate view of bot activity without requiring extensive manual analytics filtering. - It measures: - Human versus bot traffic to content pages. - Overall and operator-specific crawl-to-referral ratios. - Crawl-to-referral trends over 24 hours, seven days, or 30 days. - Top bots by traffic volume, country, bandwidth usage, and current allow/block status. - AI crawlers are classified by behavior: - **Training:** collecting data for future large language models. - **Search:** refreshing indexes used by retrieval-augmented generation. - **Agent:** supporting automated interactions that return answers to users. ## Turning Traffic Data into Business Strategy - Site owners can use high-level metrics to evaluate whether their content security policies are effective. - More detailed operator-level data helps publishers understand how individual AI companies use their content. - Comparing operators can support negotiations about: - Blocking or allowing specific crawlers. - Licensing content. - Reconsidering existing commercial agreements. - Prioritizing relationships with companies that provide meaningful compensation or referrals. - The dashboard is intended to give publishers concrete evidence—such as comparative crawl volumes and referral performance—when discussing content access with AI companies. Cloudflare’s recommendation is effectively to stop treating all crawlers alike. Publishers should use crawl-to-referral ratios, resource consumption, crawler purpose, and commercial value to decide which bots deserve access and under what conditions.

Read original(opens in new tab)

Large Language ModelsRAGAi CrawlersWeb Crawling+4

cloudflare·Jun 25, 2026·3 min readCurated summary

How we built saga rollbacks for Cloudflare Workflows

Cloudflare Workflows now supports saga rollbacks, letting each durable step declare how to compensate for its side effects if a later operation fails. This addresses partial failures in multi-step processes, such as refunding a debit when a subsequent credit cannot complete. Rollbacks execute in reverse order and preserve Workflow durability, while requiring the same idempotency safeguards as normal steps. ## The Saga Problem - Durable Workflows can retry steps and persist state, but completed external operations cannot always be directly undone. - In a bank transfer: - Bank A debits the sender. - Bank B fails to credit the recipient. - The original debit must be reversed with a new credit operation. - The pairing of a forward action and its semantic compensation is known as the saga pattern. ## Manual Compensation Before Rollbacks - Developers had to track which steps completed and write centralized `try`/`catch` logic. - Compensation had to: - Run only for completed operations. - Execute in reverse order. - Continue even if one rollback fails. - Remain durable and retryable. - This approach becomes increasingly complex as workflows gain more steps. ## Rollback Functions on `step.do()` - Rollback logic is now declared directly in the step’s options: ```js await step.do("debit-bank-a", debitFn, { rollback: async ({ output }) => refundFn(output.id), }); ``` - Each step carries its own undo operation, making compensation easier to maintain. - Rollbacks can use the original step output, such as a payment or transaction ID. - If a later step fails, previously registered rollback handlers run automatically in reverse step-start order. ## Idempotency and Partial Failures - Rollback functions must be idempotent because they may be retried. - External operations should use idempotency keys to prevent duplicate refunds, credits, or inventory releases. - A step that fails may still need compensation: - It could have modified an external system before failing. - The operation may have succeeded even though Workflows never received its result. - Rollback handlers must therefore handle `output === undefined`. - If user code catches an error and the Workflow continues, rollback does not immediately start. However, if the Workflow later fails, previously registered handlers can still run. ## Practical Usage - Developers pass an options object with a `rollback` function as the final argument to `step.do()`. - Rollbacks can reverse payments, release resources, or perform other compensating actions. - This removes the need for growing manual catch blocks and explicit rollback ordering while retaining durable execution behavior. Cloudflare’s rollback support is best suited to workflows involving external side effects. Developers should define compensation alongside every reversible step and make both forward and rollback operations safely repeatable.

Read original(opens in new tab)

Cloudflare WorkflowsRollbackIdempotencySaga Pattern+2

cloudflare·Jun 24, 2026·3 min readCurated summary

Unlocking the Cloudflare app ecosystem with OAuth for all

Cloudflare opened self-managed OAuth to all customers so developers can build SaaS integrations, internal platforms, CI/CD workflows, and agentic tools without relying on difficult-to-manage API tokens. The expansion required improvements to permissions, consent, revocation, and phishing protections, as well as a major upgrade to the Hydra-based OAuth engine. Cloudflare used staged migrations, custom database changes, token-handling safeguards, and queued revocations to minimize disruption and preserve users’ security controls. ## Why Cloudflare Expanded OAuth Access - Previously, third-party OAuth integrations were limited to manually approved partners. - Other developers had to use API tokens, which are less convenient and poorly suited to delegated access. - Self-managed OAuth lets customers: - Request narrowly scoped permissions. - Give users clearer consent controls. - Revoke application access from the dashboard. - Build integrations and agentic tools using standard OAuth flows. - Cloudflare improved consent screens to identify the requesting application and its permissions, while making application ownership more visible to reduce phishing risks. ## Planning the Hydra Upgrade - Cloudflare used Hydra, an open-source OAuth engine, but its older deployment could not support the platform’s growing scale and new use cases. - The upgrade was split into two stages: - First, move to the latest 1.X release. - Then, perform the larger 2.X migration. - The 1.X database migrations created operational risks: - Standard index creation could take exclusive locks on critical tables. - Schema changes added columns and moved data between tables. - Hydra’s SDK used `SELECT *`, creating deserialization problems after schema changes. - Cloudflare rewrote migrations to use `CREATE INDEX CONCURRENTLY` and built a custom Hydra version that selected explicit columns. ## Designing a Blue-Green Migration - An in-place 2.X upgrade was rejected because of the volume of schema changes. - A blue-green deployment was chosen, but the migration would take several hours. - Disabling writes would prevent new authorizations and revocations, leaving users unable to manage application access during the upgrade. - Instead, Cloudflare kept writes enabled while reducing the amount of data that could be lost during the cutover: - Token expiry times were temporarily extended to multiple hours, reducing refresh-token writes. - Revocation events were written to Cloudflare Queues. - After switching to the green database, queued revocations could be replayed. - Preserving revocations was essential to prevent applications that users had disabled from regaining access. ## Lessons from the 1.X Upgrade - The custom migrations completed faster than expected without user impact. - A hard cutover was necessary because the old Hydra version could not read tokens created by the new version. - The new version introduced stricter refresh-token invalidation: - Reusing a refresh token invalidated the entire access and refresh-token chain. - This caused problems for high-volume clients such as Wrangler and MCP clients. - Cloudflare added refresh-token coalescing in the Worker routing layer: - Briefly caching requests allowed retries to be served without triggering invalidation. - Hydra 2.X provides a configurable refresh-token grace period, offering a more direct solution for safe retries. ## Executing the 2.X Upgrade - Cloudflare prepared a blue-green migration to avoid several hours of customer-facing downtime. - The strategy depended on reducing token writes, recording all revocations externally, switching databases, and replaying queued events afterward. - The provided article ends while beginning the detailed discussion of the 2.X execution. Cloudflare’s approach demonstrates that opening a security-sensitive platform to broad OAuth usage requires more than exposing an authorization endpoint. Safe adoption depends on explicit permissions, transparent consent, reliable revocation, backward-compatible token behavior, and migration plans that protect users even during infrastructure cutovers.

Read original(opens in new tab)

Cloudflare WorkersOauthWranglerDatabase Migrations+3