Cloudflare

196 posts

blog.cloudflare.com

Filter by tag

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)
cloudflare3 min readCurated summary

2025 Q4 DDoS threat report: A record-setting 31.4 Tbps attack caps a year of massive DDoS assaults

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

Read original(opens in new tab)
cloudflare3 min readCurated summary

Improve global upload performance with R2 Local Uploads

R2 Local Uploads improves global upload performance by first writing object data near the client, then asynchronously copying it to the bucket’s region. Objects become immediately available and remain strongly consistent during replication. Cloudflare reports up to a 75% reduction in upload request duration for cross-region uploads. ## Faster Global Uploads - Local Uploads targets `PutObject` and `UploadPart` requests made far from the bucket’s location. - Synthetic tests showed median upload TTLB dropping from about 2 seconds to 500 milliseconds. - Tests used 5 MB objects uploaded from Western North America to an Asia-Pacific bucket at roughly 20 requests per second. - The feature is available in open beta and can be enabled in the Cloudflare Dashboard or with: ```bash npx wrangler r2 bucket local-uploads enable [BUCKET] ``` ## The Cross-Region Distance Problem - R2 requests enter through a globally distributed Gateway Worker, which handles authentication and routing. - Object metadata is managed by a distributed Durable Object Metadata Service. - Encrypted object data is stored in R2’s distributed storage infrastructure. - Without Local Uploads, streamed data must travel to the bucket’s region before the upload can complete. - Long-distance transfers can increase latency and introduce upload variability or reliability issues. ## How Local Uploads Works - If the client and bucket are in the same region, R2 uses its normal storage flow. - If they are in different regions: - Data is initially written to storage near the client. - Metadata is published in the bucket’s region. - The object becomes readable as soon as the local write completes. - Background replication later copies the data to the bucket’s primary region. - There is no read-unavailability window while replication is in progress. - Local Uploads is unavailable for jurisdiction-restricted buckets, including EU and FedRAMP buckets. ## When to Use It - Applications have users or devices distributed across multiple regions. - Upload speed and reliability are important. - You want faster writes without moving the bucket’s primary location. - R2’s Metrics page can help identify regional request patterns through the “Request Distribution by Region” graph. ## Replication Architecture - R2 represents the background copy operation as a replication task. - Cloudflare Queues process these tasks asynchronously. - Queues provide: - Rate control for replication. - Automatic retries. - Dead-letter queue support for failures. - Sharding across multiple queues for each storage region. - When publishing object metadata, R2 atomically: - Stores the object metadata. - Creates a pending-replica key describing unfinished replication work. - Creates a timestamp-based replication marker that determines when the task enters a queue. - The pending-replica record includes the replication plan, source and destination locations, mode, priority, and whether the source can be deleted after successful replication. Local Uploads is a strong fit for globally distributed upload-heavy workloads. Enable it when cross-region write latency matters, while keeping in mind the restriction on jurisdiction-constrained buckets.

Read original(opens in new tab)
cloudflare3 min readCurated summary

Google’s AI advantage: why crawler separation is the only path to a fair Internet

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.

Read original(opens in new tab)
cloudflare3 min readCurated summary

Building vertical microfrontends on Cloudflare’s platform

Cloudflare’s new Vertical Microfrontends (VMFE) Worker template lets independent teams map separate Workers to different URL paths on one domain. Unlike horizontal microfrontends, each team owns an entire vertical slice—including its framework, frontend, deployment pipeline, and operations. The approach enables technology flexibility and team autonomy while using view transitions and preloading to preserve a seamless user experience. ## Vertical Microfrontend Architecture - Applications are divided by URL path rather than by components on a single page: - `/` → Marketing - `/docs` → Documentation - `/blog` → Blog - `/dash` → Dashboard - Routes can be split into more granular verticals, such as: - `/dash/product-a` → Worker A - `/dash/product-b` → Worker B - Each route can be an entirely separate frontend project with its own: - Framework and libraries - Codebase - CI/CD pipeline - Owning team - This allows teams to choose technologies suited to their needs—for example, Astro for marketing and React for a dashboard. - It also reduces the risk of monolithic releases, where one team’s regression can force multiple teams to roll back. - Cloudflare applies a similar model internally, routing users from its core dashboard to separate products such as Zero Trust based on URL paths. ## Creating a Unified Experience - Independent applications must still appear cohesive to users. - Users generally accept distinct experiences between marketing, documentation, and dashboards. - However, related areas within one product—such as `/dash/product-a` and `/dash/product-b`—should not expose their separate repositories or Workers. - The goal is to hide implementation boundaries while preserving independent ownership. ## CSS View Transitions - Navigating between separately deployed Workers can otherwise produce a brief blank screen while the next document loads. - CSS View Transitions can preserve shared elements, such as navigation, during page changes. - The transition API allows teams to: - Keep DOM elements visible across navigations - Animate differences between the old and new pages - Make multi-page applications feel more like a single-page application - A small CSS rule can assign a transition name to the navigation and apply an eased animation to the page transition. ## Document Preloading - Seamless animation is not enough; navigation should also feel immediate. - The Speculation Rules API lets compatible browsers prefetch likely future document navigations. - Teams can define a `script` with `type="speculationrules"` and list URLs for related vertical slices, such as links in shared navigation. - Chrome, Edge, and Opera support the newer API, while Firefox and Safari currently do not. Cloudflare’s VMFE approach is most useful when teams need independent ownership and technology choices without sacrificing a unified product experience. Path-based Worker routing, shared visual conventions, view transitions, and selective prefetching provide the foundation for making separate applications behave like one.

Read original(opens in new tab)
cloudflare2 min readCurated summary

Introducing Moltworker: a self-hosted personal AI agent, minus the minis

Moltworker adapts the self-hosted Moltbot personal AI assistant to run on Cloudflare without requiring users to buy a dedicated Mac mini. It combines a Cloudflare Worker, Sandbox SDK, Browser Rendering, R2, AI Gateway, and Cloudflare Access to provide a globally available, secured deployment. The result is a managed infrastructure layer around Moltbot’s standard Gateway runtime while preserving its integrations and persistent state. ## Running a Personal Agent on Cloudflare - Cloudflare Workers increasingly supports Node.js APIs natively, reducing the need for compatibility hacks and making it easier to run existing JavaScript and TypeScript packages. - An internal test of the 1,000 most popular NPM packages found that only 15 relevant packages failed to run in Workers. - Although much of Moltbot runs inside a container, improved Workers compatibility is useful for building agent logic closer to users. - Cloudflare’s Developer Platform provides the main infrastructure components: - **Sandboxes** for securely running untrusted code. - **Browser Rendering** for automated headless browser interactions. - **R2** for persistent object storage. - Cloudflare’s global network for scalability and security. ## Moltworker Architecture - Moltworker consists of: - An entrypoint Worker serving as an API router and proxy. - Cloudflare Access protecting the Worker and administration interface. - A Sandbox container running Moltbot’s standard Gateway and integrations. - R2 for persistent storage. - This structure separates the public API and administrative layer from the isolated environment where the agent executes. ## AI Gateway Integration - Cloudflare AI Gateway proxies requests between Moltbot and AI providers. - It provides: - Centralized request visibility. - Cost monitoring, logs, and analytics. - Provider and model switching without changing Moltbot code. - Fallback providers or models for improved reliability. - Secrets can be managed through: - **Bring Your Own Key (BYOK)**, where provider credentials are stored centrally. - **Unified Billing**, where users purchase credits and Cloudflare handles provider billing. - Integration requires creating an AI Gateway instance, enabling a provider such as Anthropic, and setting `ANTHROPIC_BASE_URL`; Moltbot itself does not need code changes. ## Sandbox-Based Execution - The Sandbox SDK runs agent code in isolated environments built on Cloudflare Containers. - It provides simplified APIs for: - Executing commands. - Managing files and directories. - Running background processes. - Exposing services. - Executing code in contexts such as Python. - The SDK abstracts container lifecycle, networking, filesystem, and process-management concerns behind TypeScript APIs. Moltworker offers a way to run a capable personal AI agent online with managed security, storage, browser automation, and model access—without maintaining dedicated hardware.

Read original(opens in new tab)
cloudflare3 min readCurated summary

Building a serverless, post-quantum Matrix homeserver

The post describes a proof-of-concept Matrix homeserver ported from Synapse to Cloudflare Workers. It replaces traditional VPS, PostgreSQL, Redis, and filesystem infrastructure with Workers, Durable Objects, D1, KV, and R2, reducing operational overhead and allowing costs to fall near zero when idle. The design also provides post-quantum TLS automatically while preserving Matrix’s end-to-end encryption, though the homeserver still exposes metadata. ## From Synapse to Cloudflare Workers - Traditional Synapse deployments depend on: - PostgreSQL for persistent state - Redis for caching - Filesystem storage for media - VPS infrastructure and operational maintenance - The proof of concept reimplemented core Matrix functionality in TypeScript with Hono, including: - Event authorization - Room state resolution - Cryptographic verification - Cloudflare services replace the traditional components: - Durable Objects provide strongly consistent, atomic coordination. - D1 replaces PostgreSQL. - KV replaces Redis. - R2 replaces filesystem-based media storage. ## Benefits of a Serverless Homeserver - Deployment becomes a single `wrangler deploy` command. - Cloudflare provides TLS termination, load balancing, DDoS protection, and global distribution. - Request-based pricing means the homeserver can cost almost nothing during periods of inactivity. - Workers execute close to users in more than 300 locations, reducing latency for globally distributed communities. - Built-in security features reduce the need to configure firewalls, rate limiting, WAF rules, and IP reputation systems manually. ## Post-Quantum TLS and Matrix Encryption - Cloudflare’s TLS 1.3 connections use hybrid `X25519MLKEM768`. - This combines: - X25519, a classical elliptic-curve algorithm - ML-KEM, a lattice-based post-quantum algorithm standardized by NIST - The hybrid design requires both cryptographic systems to be broken before the connection is compromised. - Traditional deployments would need to upgrade cryptographic libraries, configure cipher suites, test client compatibility, and monitor negotiation failures. - Workers provide this protection automatically through Cloudflare’s infrastructure. ## How Messages Are Protected - Matrix clients encrypt messages locally using Megolm before sending them. - The encrypted Megolm payload is then transported over TLS using post-quantum hybrid key agreement. - The Worker terminates TLS but receives only ciphertext, which it stores and routes without seeing plaintext. - Recipients download the ciphertext over another protected TLS connection and decrypt it locally. - This creates two independent encryption layers: - TLS protects data in transit. - Megolm end-to-end encryption protects message contents from the homeserver and infrastructure providers. ## Metadata and Privacy Limits - The homeserver operator can still observe metadata, including: - Room membership - Room existence - Message timing - Other routing and account information - Message contents remain inaccessible because they are encrypted before reaching the server. - Encrypted-room media is also encrypted client-side, and private keys remain on user devices. ## Storage Architecture - The design assigns each storage primitive to the consistency model it supports best. - D1 stores durable, queryable Matrix data, including users, rooms, events, and device keys across more than 25 tables. - Durable Objects handle real-time coordination and the strong consistency needed for Matrix state resolution. - KV provides cache-like storage, while R2 handles media and filesystem-style objects. The project demonstrates that a Matrix homeserver can be made substantially easier to operate with serverless infrastructure while gaining globally distributed execution and automatic post-quantum transport security. It remains a personal proof of concept, so production deployments should evaluate feature completeness, scalability, compatibility, and the privacy implications of relying on Cloudflare.

Read original(opens in new tab)
cloudflare4 min readCurated summary

Cable cuts, storms, and DNS: a look at Internet disruptions in Q4 2025

In Q4 2025, Internet disruptions were driven primarily by submarine cable cuts, power failures, extreme events, technical problems, and one government-directed shutdown. Tanzania experienced a prolonged election-related blackout, while damaged international cables disrupted connectivity in Haiti, Pakistan, Cameroon, and the Dominican Republic. Cloudflare’s analysis uses major deviations in network traffic and routing announcements to identify these incidents, though it is not exhaustive. ## Government-Directed Shutdown ### Tanzania - Internet traffic fell by more than 90% on October 29 during violent protests surrounding the presidential election. - The initial shutdown lasted about 26 hours, but a second near-total outage began shortly after service briefly returned. - Connectivity did not substantially recover until November 3. - Announced IPv4 and IPv6 address space declined slightly but never disappeared entirely, indicating that Tanzania was not completely disconnected from the global Internet. - Internet and social media restrictions had also occurred ahead of Tanzania’s 2020 elections. ## Submarine and Fiber Cable Cuts ### Digicel Haiti - Digicel Haiti suffered two international fiber cuts during the quarter. - On October 16, traffic fell to nearly zero; the provider reported two cuts and restored the first fiber within several hours. - On November 25, another cut along National Road 1 caused a complete outage lasting roughly six hours. - Service was restored after repairs to the international optical fiber infrastructure. ### Cybernet/StormFiber in Pakistan - Traffic dropped to about half its expected level on October 20, while announced IPv4 address space fell by more than one-third. - The cause was a cut to the PEACE submarine cable in the Red Sea near Sudan. - Pakistan has multiple international cable routes, including IMEWE and SEA-ME-WE-4, which helped enable rapid recovery. - Traffic and address announcements returned close to normal by October 21, ahead of the provider’s October 27 restoration target. ### Cameroon and the WACS Cable - Camtel, MTN Cameroon, and Orange Cameroun experienced major disruptions on October 23 because of an incident involving the West Africa Cable System (WACS). - Traffic initially fell around 05:00 local time and recovered by approximately 22:00, although it fluctuated dramatically and sometimes dropped by 90–99%. - MTN and Orange also saw reductions in announced IP address space, while Camtel’s announcements remained stable. - The volatility may have reflected attempts to reroute traffic over other submarine cables. - Connectivity in the Central African Republic and Republic of Congo was reportedly affected as well. ### Claro Dominicana - Claro Dominicana experienced two sharp traffic declines on December 9. - Traffic eventually fell 77% below the comparable level from the previous week. - The provider attributed the disruption to two severed fiber-optic cables, which caused intermittent service and slow speeds. - Technicians restored nationwide service after repairing the cables. ## Power-Related Disruption ### Dominican Republic - A transmission-line outage on November 11 caused a major national power interruption. - Internet traffic fell by nearly 50% compared with the previous week and remained depressed until December 12. - The electrical operator later reported that 96% of national demand had been restored. - A technical report traced the blackout to a manually disconnected live line at the 138 kV San Pedro de Macorís I substation. - The resulting short circuit triggered protection systems and disconnected nearby lines, separating 575 MW of generation. ## Overall Pattern - More than 180 Internet disruptions were observed globally during 2025. - Q4 included only one government-directed shutdown, but several international cable failures caused severe regional outages. - Traffic measurements and BGP address announcements helped distinguish partial connectivity loss from complete national disconnection. - The incidents demonstrate how dependent national networks remain on a limited number of submarine cables, fiber routes, and reliable electrical infrastructure. Cloudflare’s findings suggest that network operators should diversify international cable routes, improve redundancy, and prepare for power and infrastructure failures. The Cloudflare Radar Outage Center provides a broader list of verified anomalies and confirmed outages.

Read original(opens in new tab)
cloudflare3 min readCurated summary

Route leak incident on January 22, 2026

On January 22, 2026, a routing-policy automation error caused Cloudflare to leak IPv6 BGP prefixes from its Miami data center. For 25 minutes, external traffic was redirected through Miami, congesting backbone links, increasing latency and packet loss, and causing some traffic to be dropped by firewall filters. The incident resulted from removing prefix-list constraints, leaving a Juniper policy that accepted and externally advertised unintended internal routes. ## What a BGP Route Leak Is - A route leak occurs when an autonomous system advertises routes it is not supposed to forward. - This violates valley-free routing principles, such as sending routes learned from a peer onward to another peer or provider. - The leaking network may lack the capacity or firewall rules to handle the redirected traffic. - Cloudflare’s incident involved a mixture of Type 3 and Type 4 route leaks under RFC 7908. ## Incident Impact and Timeline - The triggering automation change was merged at **19:52 UTC**. - At **20:25 UTC**, it ran on a single Miami edge router and caused unexpected advertisements to peers and transit providers. - The network team began investigating at **20:40 UTC** and formally coordinated the incident at **20:44 UTC**. - At **20:50 UTC**, an operator reverted the bad configuration and paused automation on the router. - The leak lasted approximately **25 minutes**, causing: - Congestion on Miami backbone infrastructure - Increased packet loss and latency for some Cloudflare customers - Traffic from unrelated external networks to be funneled through Miami - Packet drops from firewalls configured to accept only Cloudflare-related traffic - The triggering code change was reverted at **21:47 UTC**, and automation was later verified and resumed. ## The Configuration Error - Cloudflare intentionally removed Miami advertisements for a Bogotá data center after infrastructure changes made the Miami-to-Bogotá forwarding path unnecessary. - The change removed `6-BOG04-SITE-LOCAL` prefix-list conditions from multiple export policies. - Those prefix lists had constrained policies to specific Bogotá prefixes. - Once removed, policies such as `6-TELIA-ACCEPT-EXPORT` still matched routes with `route-type internal` and accepted them for export. - On Juniper JunOS and JunOS EVO, `route-type internal` matches any non-external route, including Internal BGP (IBGP) routes. - Consequently, routes that should have remained internal were treated as exportable and advertised to external peers and providers. - The problem affected IPv6 traffic only. ## Response and Remediation - Operators manually reverted the generated router configuration. - Automation was paused on the affected Miami router to prevent the faulty policy from being reapplied. - The source-code change was reverted, and the router was checked before automation resumed. Cloudflare’s incident demonstrates that removing seemingly obsolete route filters can unintentionally broaden a policy. Export policies should explicitly constrain acceptable prefixes and include validation or safeguards that prevent internal routes from being advertised externally.

Read original(opens in new tab)
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)
cloudflare3 min readCurated summary

Astro is joining Cloudflare

Astro Technology Company is joining Cloudflare, with the Astro team continuing to develop the framework as Cloudflare employees. Astro will remain MIT-licensed, open source, portable across platforms, and governed through a public roadmap and open contributions. The partnership aims to strengthen Astro’s role as a fast, accessible framework for content-driven websites, with Astro 6 introducing major development and runtime improvements. ## What the Cloudflare Acquisition Means - Astro remains: - Open source and MIT-licensed - Open to community contributions - Supported by a public roadmap and open governance - Deployable across any cloud or hosting platform - Astro’s full-time employees are joining Cloudflare and will continue working on the framework. - Cloudflare will support the Astro Ecosystem Fund alongside partners such as Webflow, Netlify, Wix, Sentry, and Stainless. - The project’s commitment to portability and platform independence will not change. ## Why Developers Choose Astro Astro has focused on content-driven websites rather than attempting to serve every type of application equally. - **Content-driven:** Built to showcase websites’ content. - **Server-first:** Renders HTML on the server for better performance. - **Fast by default:** Designed to make slow websites difficult to build. - **Easy to use:** Accessible without deep JavaScript tooling expertise. - **Developer-focused:** Provides tools and resources intended to support successful development. Astro’s Islands Architecture supports this approach: - Most pages are delivered as fast, static HTML. - Interactive sections can be rendered as client-side “islands.” - Developers can use multiple UI frameworks on the same page, including React, Vue, Svelte, and Solid. ## Shared Vision for Web Development Cloudflare and Astro share a goal of making the web faster and easier to build on. - Astro was created in 2021 to simplify the increasingly difficult process of building fast websites. - Its simple, structured foundation also helps coding agents and AI-assisted development produce better results. - Platforms including Webflow Cloud, Wix Vibe, and Stainless use Astro to help their customers create and publish websites. - These platforms run on or integrate with Cloudflare infrastructure while using Astro as their content and application foundation. ## Astro 6 Improvements Astro 6 is entering beta, with general availability expected soon. - A redesigned development server is built on Vite’s Environments API. - With the Cloudflare Vite plugin, local development can run in `workerd`, the Cloudflare Workers runtime. - Developers can locally use production-like APIs such as: - Durable Objects - D1 - KV - Agents - The Vite Environments API is not limited to Cloudflare; other JavaScript runtimes can provide similar integrations. - Live Content Collections are now stable, allowing content to update without rebuilding the site while retaining validation and caching. - Additional features include first-class Content Security Policy support, simpler APIs, and Zod 4 support. Cloudflare’s investment is intended to give Astro greater long-term support without changing its open, portable character. Developers can try the Astro 6 beta with `npm create astro@latest -- --ref next` or upgrade an existing project using `npx @astrojs/upgrade beta`.

Read original(opens in new tab)
cloudflare3 min readCurated summary

Human Native is joining Cloudflare

Cloudflare has acquired Human Native, a UK-based marketplace that helps AI developers obtain structured, licensed multimedia data. The acquisition supports Cloudflare’s broader effort to create a fairer AI ecosystem in which content owners control access, receive compensation, and get credit. Together, the companies aim to replace indiscriminate crawling with structured data delivery and machine-to-machine payments. ## Human Native’s Role - Human Native transforms messy, unstructured content into data that can be searched, understood, licensed, and valued. - Its approach treats data as a transparent, governed asset rather than something freely scraped. - A UK video AI customer reportedly replaced its existing training data with higher-quality, fully licensed content sourced through Human Native. - Cloudflare expects the team to help publishers and developers make content more usable for AI systems. ## Strain on the Internet’s Existing Economic Model - The traditional web exchange has been: - Creators publish content. - Search engines and social platforms send traffic. - Creators monetize that traffic through advertising, subscriptions, or direct support. - AI crawling is disrupting this model, with tens of thousands of bot crawls sometimes occurring for every human visit. - Content owners often do not know how crawlers use their material and increasingly want control over AI access. - Cloudflare’s AI Crawl Control and Pay Per Crawl tools are intended to let owners choose whether content is broadly accessible, restricted, or available only for compensation. ## Structured Access for AI Developers - Crawling the open web is costly and unreliable, producing duplicate, spammy, illegal, or otherwise low-quality material. - Cloudflare’s AI Index is designed to provide AI companies and agents with content at scale without repeated, indiscriminate crawling. - Through a publish/subscribe model, participating websites could send structured, real-time updates whenever content changes. - This approach may improve data quality while giving publishers more opportunities to create sustainable business models. ## Machine-to-Machine Payments - Cloudflare is working with Coinbase on the x402 Foundation to support automated payments for digital resources. - Traditional web payments require human actions such as adding items to a cart and entering card details. - AI agents and other automated systems need protocols that allow them to discover, purchase, and exchange digital resources directly. - Human Native’s technology and Cloudflare’s payment infrastructure are intended to support these emerging transactions. ## Practical Outlook The acquisition positions Cloudflare to build an AI data ecosystem based on licensed content, structured distribution, owner-controlled access, and automated compensation. Its stated goal is an Internet that remains open and useful while becoming fairer and more economically sustainable in the age of AI.

Read original(opens in new tab)
cloudflare2 min readCurated summary

What came first- the CNAME or the A record

A memory-optimization change in Cloudflare’s 1.1.1.1 resolver accidentally reordered DNS records, placing CNAMEs after A/AAAA records. Although DNS record order is generally considered irrelevant, some clients—including glibc’s `getaddrinfo`—process answers sequentially and require CNAMEs to appear first. The resulting failures affected users globally until Cloudflare reverted the release. ## Incident Timeline - **December 2, 2025:** The record-reordering change was added. - **December 10:** It reached the testing environment. - **January 7, 2026:** Global deployment began. - **January 8, 17:40 UTC:** The change reached 90% of servers. - **18:19:** The incident was declared. - **18:27:** The release was reverted. - **19:55:** The revert completed and the impact ended. ## How CNAME Chains Are Resolved - A hostname may point through multiple aliases before reaching an A or AAAA record: - `www.example.com → cdn.example.com → server.cdn-provider.com → 198.51.100.1` - Each record has its own TTL and may expire independently. - If only part of a chain expires, 1.1.1.1 can reuse the cached portion and resolve only the missing records. - The resolver then combines the cached CNAME records with newly resolved address records. ## The Memory Optimization That Changed Ordering - Previously, the resolver created a new list: - Insert the existing CNAME chain first. - Append the newly resolved A/AAAA records afterward. - The optimization avoided allocations and copies by appending new CNAME records directly to the existing answer list. - This caused some responses to place address records before CNAME records. ## Why Some DNS Clients Failed - Many clients treat answer-section ordering as irrelevant, but some parse records sequentially. - These clients: - Start by looking for records matching the original queried name. - Update the expected name when they encounter a CNAME. - Accept the corresponding A or AAAA record only after that update. - With the expected order, the client sees the CNAME first and then accepts the address record. - With the address record first, it ignores the address because it does not yet match the expected name. After encountering the CNAME, there are no records left to process, so it reports an empty response. - The affected implementation included glibc’s `getaddrinfo`, widely used for DNS resolution on Linux. The incident demonstrates that even seemingly insignificant DNS response ordering can matter in practice. Resolver implementations should preserve CNAME-before-address ordering, and DNS clients should avoid assuming that record order is meaningful unless the protocol explicitly requires it.

Read original(opens in new tab)
cloudflare3 min readCurated summary

What we know about Iran’s Internet shutdown

Iran’s government effectively disconnected the country from the global Internet on January 8, 2026, amid escalating nationwide protests. Cloudflare observed a near-total loss of traffic after major Iranian networks withdrew most announced IPv6 address space and then lost connectivity almost entirely. Brief access windows on January 9 quickly ended, and the shutdown remained in place through January 10. ## Background and Earlier Shutdowns - Iran has previously restricted Internet access during protests: - More than five days of disruption followed fuel-price protests in November 2019. - Connectivity was disrupted across multiple providers during protests after Mahsa/Zhina Amini’s death in September 2022. - Internet traffic had already been below normal at the beginning of 2026, suggesting connectivity problems preceded the complete shutdown. ## Connectivity Collapsed on January 8 - At 11:50 UTC, Iranian networks reduced announced IPv6 address space by 98.5%, from over 48 million `/48` blocks to roughly 737,000. - This caused IPv6’s share of human-generated traffic to fall from about 12% to 2%, before IPv6 traffic nearly disappeared later that afternoon. - Between 16:30 and 17:00 UTC, overall traffic dropped by nearly 90%. - Major providers affected included: - MCCI (AS197207) - IranCell (AS44244) - TCI (AS58224) - By approximately 18:45 UTC, traffic from Iran had fallen effectively to zero, indicating a nationwide disconnection from the global Internet. ## Brief Connectivity on January 9 - Internal traffic remained below 0.01% of pre-shutdown peaks. - Access to Cloudflare’s `1.1.1.1` DNS resolver briefly returned around 10:00 UTC, producing a short-lived spike in requests. - Several universities also regained connectivity temporarily, including the University of Tehran, Sharif University of Technology, Tehran University of Medical Science, and Tarbiat Modares University. - Traffic from these networks disappeared again by roughly 15:00 UTC. ## Filtering Changes Before the Shutdown - HTTP/3 and QUIC usage declined sharply before the full outage. - On IranCell, HTTP/3 usage fell from as high as 40% to 5% by December 31 and continued declining. - On TCI, HTTP/3 dropped below 5% around January 3. - These changes may indicate increasingly severe filtering and upgraded whitelisting, according to MahsaNet. ## Ongoing Disconnection - Since January 10, Iran’s Internet traffic has shown no significant recovery. - Traffic remains at only a fraction of one percent of previous levels. - Cloudflare continues monitoring the situation through Radar’s traffic and routing data. The available measurements strongly indicate a deliberate, nationwide Internet shutdown rather than an ordinary network failure. Cloudflare Radar’s traffic and routing pages provide the most practical way to follow any restoration or further changes.

Read original(opens in new tab)
cloudflare3 min readCurated summary

A closer look at a BGP anomaly in Venezuela

The post examines a January 2 BGP anomaly involving Venezuela’s CANTV network (AS8048). Although the event prompted speculation about government-directed surveillance, the broader pattern—eleven leaks since December—more strongly suggests inadequate BGP import and export filtering. The affected routes, provider-customer relationships, and heavy AS-path prepending are consistent with a configuration or operational error rather than clear malicious activity. ## Background: How BGP Route Leaks Work - BGP directs traffic between autonomous systems (ASes) according to business relationships: - **Customer-provider:** Providers advertise broad Internet routes to customers; customers advertise their own and downstream routes. - **Peer-peer:** Networks exchange their own and customer routes without payment. - These rules produce “valley-free” paths, where traffic generally moves from customers toward providers and then back down toward customers. - A **route leak**, formally defined in RFC 7908, occurs when routing announcements are propagated beyond their intended scope. - A typical leak happens when a customer receives routes from one provider and incorrectly advertises them to another provider, causing traffic to take an inefficient or overloaded path. ## The AS8048 Route Leak - Cloudflare Radar identified AS8048, operated by Venezuelan ISP CANTV, as the leaking network. - CANTV learned routes from AS6762, Italian telecom Sparkle, and redistributed them to AS52320, Colombia’s V.tal GlobeNet. - The leaked prefixes were originated by AS21980, Dayco Telecom, and belonged to the same `200.74.224.0/20` subnet. - Since AS8048 appears to be a provider for AS21980, the leak may reflect incorrect route export policies involving a customer’s prefixes. - The post emphasizes that route leaks are common and are usually caused by mistakes or weak routing controls rather than deliberate attacks. ## Evidence from Routing Relationships - Cloudflare Radar, bgp.tools, and BGPKIT data all indicate a provider-customer relationship between AS8048 and AS21980. - BGPKIT’s relationship analysis showed: - AS8048 was identified as the upstream provider in 9.4% of observations. - AS21980 was almost never identified as upstream. - Although only 9.9% of route collectors saw the two ASes as directly adjacent, the available paths strongly supported AS8048 being AS21980’s provider. ## Significance of AS-Path Prepending - Many leaked routes included repeated instances of AS8048 in their paths. - AS-path prepending is normally used to make a route less attractive and shift traffic away from a particular connection. - A path such as `52320,8048,8048,8048,...,21980` does not mean traffic physically traversed AS8048 repeatedly; the repeated entries are routing-policy padding. - The heavy prepending would have made the leaked routes less preferred, which weakens the case that AS8048 was intentionally trying to attract large volumes of traffic for interception. - The available evidence therefore points more toward poor routing configuration or operational practice than a purposeful man-in-the-middle operation. CANTV’s repeated route leaks and apparent lack of effective routing policies should still be treated as a serious reliability and security concern. However, the post’s evidence supports interpreting this incident as an example of recurring BGP misconfiguration unless further data demonstrates intentional manipulation.

Read original(opens in new tab)