Security is traditionally a game of defense. You build walls, set up gates, and write rules to block traffic that looks suspicious. For years, Cloudflare has been a leader in this space: our Application Security platform is designed to catch attacks in flight, dropping malicious requests at the edge before they ever reach your origin. But for API security, defensive posturing isn’t enough.
That’s why today, we are launching the beta of Cloudflare’s Web and API Vulnerability Scanner.
We are starting with the most pervasive and difficult-to-catch threat on the OWASP API Top 10: Broken Object Level Authorization, or BOLA. We will add more vulnerability scan types over time, including both API and web application threats.
The most dangerous API vulnerabilities today aren’t generic injection attacks or malformed requests that a WAF can easily spot. They are logic flaws—perfectly valid HTTP requests that meet the protocol and application spec but defy the business logic.
To find these, you can’t just wait for an attack. You have to actively hunt for them.
The Web and API Vulnerability Scanner will be available first for API Shield customers. Read on to learn why we are focused on API security Continue reading
In December 2025, Cloudflare received reports of HTTP/1.x request smuggling vulnerabilities in the Pingora open source framework when Pingora is used to build an ingress proxy. Today we are discussing how these vulnerabilities work and how we patched them in Pingora 0.8.0.
The vulnerabilities are CVE-2026-2833, CVE-2026-2835, and CVE-2026-2836. These issues were responsibly reported to us by Rajat Raghav (xclow3n) through our Bug Bounty Program.
Cloudflare’s CDN and customer traffic were not affected, our investigation found. No action is needed for Cloudflare customers, and no impact was detected.
Due to the architecture of Cloudflare’s network, these vulnerabilities could not be exploited: Pingora is not used as an ingress proxy in Cloudflare’s CDN.
However, these issues impact standalone Pingora deployments exposed to the Internet, and may enable an attacker to:
Bypass Pingora proxy-layer security controls
Desync HTTP request/responses with backends for cross-user hijacking attacks (session or credential theft)
Poison Pingora proxy-layer caches retrieving content from shared backends
We have released Pingora 0.8.0 with fixes and hardening. While Cloudflare customers were not affected, we strongly recommend users of the Pingora framework to upgrade as soon as possible.
The reports Continue reading
We haven’t implemented support for Cisco SD-WAN in netlab yet, and we might never do so; after all, netlab isn’t meant to be a kitchen sink of vendor-specific features. However, having an open-source tool that uses input and output files with standardized encoding (JSON or YAML) makes it easy to develop an independent solution that adds functionality.
That’s exactly what Sebastien d’Argoeuves did: he developed a solution that automates Cisco SD-WAN deployment after the corresponding netlab lab is started, and published it in a GitHub repo. If you’re an SD-WAN fan, you must give it a try ;)
For years, the cybersecurity industry has accepted a grim reality: migrating to a zero trust architecture is a marathon of misery. CIOs have been conditioned to expect multi-year deployment timelines, characterized by turning screws, manual configurations, and the relentless care and feeding of legacy SASE vendors.
But at Cloudflare, we believe that kind of complexity is a choice, not a requirement. Today, we are highlighting how our partners are proving that what used to take years now takes weeks. By leveraging Cloudflare One, our agile SASE platform, partners like TachTech and Adapture are showing that the path to safe AI and Zero Trust adoption is faster, more seamless, and more programmable than ever before.
The traditional migration path for legacy SASE products—specifically the deployment of Secure Web Gateway (SWG) and Zero Trust Network Access (ZTNA)—often stretches to 18 months for large organizations. For a CIO, that represents a year and a half of technical debt and persistent security gaps.
By contrast, partners like TachTech and Adapture are proving that this marathon of misery is not a technical necessity. By using a unified connectivity cloud, they have compressed these timelines from 18 months Continue reading
Cloudflare One has grown a lot over the years. What started with securing traffic at the network now spans the endpoint and SaaS applications – because that’s where work happens.
But as the market has evolved, the core mission has become clear: data security is enterprise security.
Here’s why. We don’t enforce controls just to enforce controls. We do it because the downstream outcomes are costly: malware, credential theft, session hijacking, and eventually the thing that matters most: sensitive data leaving the organization. What looks like a simple access policy can be the first link in a chain that ends in incident response, customer impact, and reputational damage.
So when you take a step back, most security programs – even the ones that look different on paper – are trying to answer the same questions:
Where is sensitive data?
Who can access it?
What paths exist for it to move somewhere it shouldn’t?
That’s the backbone of our data security vision in Cloudflare One: a single model that follows data across the places it moves, not a pile of siloed controls. That means:
Protection in transit (across Internet + SaaS access)
Visibility and control at rest (inside SaaS)
Enforcement Continue reading
It’s 2026, and it’s time for a new cellular telephone hype cycle: 6G! Doug Dawson from CCG joins Russ and Tom to talk about why 5G is really 4.5G, the proposed changes for 6G, and the challenges higher frequency ranges and bandwidths face in the real world.
It’s definitely worth following Doug’s daily post about the telecom and wireless worlds over at Pots and Pans.
download
Akvorado, a network flow collector, relies on Traefik, a reverse HTTP proxy, to expose HTTP endpoints for services implemented in a Docker Compose setup. Docker labels attached to each service define the routing rules. Traefik picks them up automatically when a container starts. Instead of maintaining a static configuration file to collect Prometheus metrics, we can apply the same approach with Grafana Alloy, making its configuration simpler.
Traefik listens for events on the Docker socket. Each service advertises its configuration through labels. For example, here is the Loki service in Akvorado:
services: loki: # … expose: - 3100/tcp labels: - traefik.enable=true - traefik.http.routers.loki.rule=PathPrefix(`/loki`)
Once the container is healthy, Traefik creates a router forwarding requests
matching /loki to its first exposed port. Colocating Traefik configuration
with the service definition is attractive. How do we achieve the same for
Prometheus metrics?
Grafana Alloy, a metrics collector that can scrape Prometheus endpoints,
includes a discovery.docker component. Just like Traefik,
it connects to the Docker Continue reading
Last Updated: 2026-03-05 When I see spreadsheets like this I want to cry and tear my hair out. What if I want to select a subset? (Hide the other rows, seriously?). What does the color coding mean???? A Visceral Response It took me a while to understand why seeing something like this made my skin READ MORE
The post Don’t be a bobo! be a Dolt! appeared first on The Gratuitous Arp.
You’ve likely seen this support ticket countless times: a user’s Internet connection that worked just fine a moment ago for Slack and DNS lookups is suddenly hung the moment they attempt a large file upload, join a video call, or initiate an SSH session. The culprit isn't usually a bandwidth shortage or service outage issue, it is the "PMTUD Black Hole" — a frustration that occurs when packets are too large for a specific network path, but the network fails to communicate that limit back to the sender. This situation often happens when you’re locked into using networks you do not manage or vendors with maximum transmission unit (MTU) restrictions, and you have no means to address the problem.
Today, we are moving past these legacy networking constraints. By implementing Path MTU Discovery (PMTUD), the Cloudflare One Client has shifted from a passive observer to an active participant in path discovery.
Dynamic Path MTU Discovery allows the client to intelligently and dynamically adjust to the optimal packet size for most network paths using MTUs above 1281 bytes. This ensures that a user’s connection remains stable, whether they are on a high-speed corporate backbone or a restrictive cellular network.
Yesterday, I had a short presentation on netlab use cases during the NetBCN event. It covered a dozen examples, from rapid prototyping to testing network automation software and arguing with vendor TAC. I added the “use cases” part of the presentation to the standard netlab presentation; you can view the results on ipSpace.net (no account or registration required).
When you need to use a proxy to keep your zero trust environment secure, it often comes with a cost: poor performance for your users. Soon after deploying a client proxy, security teams are generally slammed with support tickets from users frustrated with sluggish browser speed, slow file transfers, and video calls glitching at just the wrong moment. After a while, you start to chalk it up to the proxy — potentially blinding yourself to other issues affecting performance.
We knew it didn’t have to be this way. We knew users could go faster, without sacrificing security, if we completely re-built our approach to proxy mode. So we did.
In the early days of developing the device client for our SASE platform, Cloudflare One, we prioritized universal compatibility. When an admin enabled proxy mode, the Client acted as a local SOCKS5 or HTTP proxy. However, because our underlying tunnel architecture was built on WireGuard, a Layer 3 (L3) protocol, we faced a technical hurdle: how to get application-layer (L4) TCP traffic into an L3 tunnel. Moving from L4 to L3 was especially difficult because our desktop Client works across multiple platforms (Windows, macOS, Linux) so we couldn’t use Continue reading
The public Internet relies on a fundamental principle of predictable routing: a single IP address points to a logically unique destination. Even in an Anycast architecture like Cloudflare’s, where one IP is announced from hundreds of locations, every instance of that IP represents the same service. The routing table always knows exactly where a packet is intended to go.
This principle holds up because global addressing authorities assign IP space to organizations to prevent duplication or conflict. When everyone adheres to a single, authoritative registry, a routing table functions as a source of absolute truth.
On the public Internet, an IP address is like a unique, globally registered national identity card. In private networks, an IP is just a name like “John Smith”, which is perfectly fine until you have three of them in the same room trying to talk to the same person.
As we expand Cloudflare One to become the connectivity cloud for enterprise backbones, we’ve entered the messy reality of private IP address space. There are good reasons why duplication arises, and enterprises need solutions to handle these conflicts.
Today, we are introducing Automatic Return Routing (ARR) in Closed Beta. ARR is an optional tool for Continue reading