On October 19, 2026, we learned about eMudhra’s eight shockingly weak keys: where eMudhra was trusted to pick a 115-digit number for their virtual combination lock protecting the Internet, they picked the number 4. Not even four digits, just the number 4. The other seven keys were similarly weak: 56, 66, 115, 155, 156, 230 and 237.
The next day, we wrote a blog post on the immediate action we took to mitigate this leak, and what customers needed to do on their end to stay secure. Now, we are sharing a more in-depth follow up on the evidence we’ve seen of exploitation, and the progress seen on visitors patching their systems.
Let's start with the scale of the problem. A certificate authority (CA) with weak keys this serious is unprecedented, and the potential consequences are significant. While there have been plenty of compromised certification authorities in the past (such as DigiNotar, TÜRKTRUST, and TrustWave), access to their keys has always been contained to a degree; these incidents gave a limited set of attackers or organizations the ability to issue fraudulent certificates. The eMudhra incident is fundamentally different; the affected intermediate private keys could be recovered almost Continue reading
Today, Cloudflare services for private origins is generally available. Point a proxied DNS record at a private IP, and Cloudflare reaches the origin over your existing Cloudflare One connection. Your origin stays private, while web application firewall (WAF), caching, bot management, and Workers work just as they do for public origins.
In June, we launched this capability in closed beta to address a problem we kept hearing from customers: Their internal APIs, AI agent backends, MCP servers, and operational tools weren’t built to face the Internet, but those services still need to accept requests from partners, customers, or agents over the Internet. Before the beta, putting Cloudflare in front of these services meant exposing a public IP, opening a firewall port, or running cloudflared alongside the origin.
Those requirements often left private applications without the same protections and controls they used for public applications, including WAF, bot management, rate limiting, caching, traffic acceleration, rewrites, and Workers.
During the closed beta, eligible customers requested access through their account team. Today, we’re opening access beyond that beta group.
Point a proxied A or AAAA record at a private IP, and Cloudflare’s application services work Continue reading

Imagine your product strategy team gets stuck on a positioning problem. Somebody opens an AI chat window and asks for an unconventional angle. The model comes back with a concept nobody in the room has thought about in years. Maybe it’s the Lindy effect or Chesterton’s fence or something borrowed from evolutionary biology. The room loves it. It feels fresh and a little clever. Three months later a competitor walks onto a keynote stage with the same framing. How did that happen? Did someone leak the deck?
You’ve probably felt a smaller version of this. You learn a new word and it shows up in three articles that same week. The linguist Arnold Zwicky named this on Language Log in 2005. He called it the frequency illusion, though you may know it by its folk name, the Baader-Meinhof phenomenon. Once you notice something, you think it’s everywhere. Most of the time it isn’t. Your attention changed. The world didn’t. When the coincidences really start piling up, some people reach for something grander. Great minds think alike. Ideas are in the air. Maybe there’s a universal consciousness out there that we’re all dipping into. Or maybe it’s as bland as Continue reading
Welcome to the 26th edition of Cloudflare's DDoS Threat Report. This edition covers the third quarter of 2026 — July, August, and September — and returns the series to its quarterly cadence following the combined H1 2026 volume. The analysis is produced by Cloudforce One, Cloudflare's Threat Intelligence organization, providing a comprehensive analysis of the evolving threat landscape of Distributed Denial of Service (DDoS) attacks based on data from the Cloudflare network.
In part five of a series on AI data center networking, various interconnected networks are discussed, highlighting the differences between traditional and AI clusters. Key topics include back-end and front-end networks, the folded-Clos topology, adaptive routing, and the significance of switch design in addressing network congestion. Dragonfly topology is also mentioned for hyperscale systems.
The post Fabric Topologies for GPU Clusters appeared first on /overlaid.
The example above uses the open source sFlow-RT booth-demo application to demonstrate a 400G data center switch carrying RoCEv2 test traffic. The demo shows a series of RDMA write operations in the Traffic Trend chart. The Switch Port Traffic Flows diagram shows the paths traffic takes as it flows through the switch. In this example, a NCCL ring topology results traffic flowing from port to port as it goes around the logical ring of GPUs.
The quickest way to set up the demo is to run the a pre-built sflow/booth-demo image on a laptop connected to the booth display screen. The Traffic Trend chart is easily customizable to show different flow attributes that are relevant to the demo and the title can be changed to include branding and messaging. If more extensive customization is required, clone the GitHub project Continue reading

This post is part of an ongoing series - see all the posts below.
In the previous part, we built an OSPF network from scratch using Ansible, and then logged in to the routers to check that everything was working. We looked at the OSPF neighbors, checked the routing table, and ran a few pings. That's fine for six routers. But imagine doing it for fifty, before and after every change, at 2 AM during a maintenance window. By router number twelve, you're not really reading the output anymore, you're just looking for the word FULL and hoping for the best.
In this part, we'll let Ansible do the checking for us. We'll write a few simple tests that check whether every router has the right number of OSPF neighbors, and whether every router can reach every other router. If something is wrong, the playbook fails and tells us exactly where the problem is. We'll also break the network on purpose, so we can see what happens when a check fails.
We're continuing with the same lab and project from the previous part, so if you haven't read it yet, I recommend starting there.
I’ve wondered for years why SCHED_IDLE tasks are allowed to preempt other
tasks. Nobody seems to know, and I’ve not had the time to dig in and understand
the Linux kernel scheduler better. But now I finally have my answer.
I want to be able to run a CPU-heavy task in the background, without it stealing any CPU, any at all, from other processes.
If you read various documentation, you’d be forgiven if this is as simple as
schedtool -D -e ./my-background-thing.
SCHED_FIFO can be used only with static priorities higher than 0,
which means that when a SCHED_FIFO thread becomes runnable, it
will always immediately preempt any currently running SCHED_OTHER,
SCHED_BATCH, or SCHED_IDLE thread.
(and similar statements, e.g. from sched.7)
But if you try that, you’ll find that it’ll actually preempt other processes, taking little but nonzero CPU. There’s a test program, if you want to try it out.
I literally want it to take zero CPU. And not just against SCHED_FIFO/RR, but
everything.
There appear to be two places that minmax guarantees can show up.
Settings with default values:
$ sudo sysctl -a | grep sched_rt_
kernel. Continue readingLast week was one for the Internet security history books. First, eight eMudhra intermediate certificates were compromised, creating the possibility of forged certificates that could be used to impersonate servers. Then came php2shell: serious vulnerabilities in PHP, the runtime behind a large portion of the Web.
Cloudflare worked around the clock as these events unfolded to protect our customers and help protect the Internet. We shipped client updates and multiple mitigations, updated our web application firewall (WAF) with new rules to block attackers from exploiting the PHP vulnerabilities, and introduced a new feature called full transaction detection.
As always in situations like this, these new capabilities were made available on all plans, including Free.
Protecting systems from vulnerabilities like these is always an ongoing process, not a one-time event. The widespread adoption of AI allows attackers to discover new vectors with unprecedented speed and efficiency, so collecting real-world data to test our assumptions and strengthen defenses is essential.
That’s why today we're launching the Cloudflare PHP Capture the Flag challenge, run through our Bug Bounty program. We've put a deliberately vulnerable PHP installation behind our WAF, and we're inviting security researchers Continue reading
The Internet can feel invisible when everything is working normally. But when connectivity breaks, the many systems it depends upon become evident in an instant. Because Cloudflare’s global network handles more than 20% of the web’s traffic, it offers a unique perspective of how Internet traffic is behaving. When failures in infrastructure, power, policy, or security disrupt access to the Internet, Cloudflare Radar can observe the impact by monitoring traffic to our customers. Each quarter, we review the disruptions detected and annotated on Radar, highlighting what happened, where it happened, and the broader conditions that shaped each event.
In this post, we examine the major categories of Internet disruptions observed during the third quarter of 2026, including government-directed shutdowns, power outages and natural disasters.
Between July and September, Internet disruptions were largely driven by failures in the systems the Internet depends on. Power grids failed in Cuba, Honduras, Guam, Ukraine, and several other countries. Natural disasters damaged electricity and telecommunications infrastructure from Nepal to Colombia. Government-directed shutdowns remained the most frequent source of disruption, driven largely by exam-related shutdowns in Iraq, while renewed conflict in Ethiopia’s Tigray region showed how quickly connectivity can become part of Continue reading
Here’s another you can’t make this up SNAFU observation I made when running integration tests for netlab Syslog functionality: Cisco Nexus OS cannot send Syslog messages to a directly connected silent host.
The setup is as trivial as it can get: a Cisco Nexus OS VM (running version 10.6(2)) connected to a dnsmasq container running rsyslogd.
In a previous post I described load balancing for TCP-based HTTP with connection offloading, and mentioned that HTTP/3 can do even more. By the power of AI writing a HTTP/3 version of both the load balancer (sni-router-h3) and the webserver (tarweb-h3), I have experimented enough to have more to say about how that works.
To be clear: this post is 100% human-written.
In this post I will use this terminology:
While it is possible to use TCP_REPAIR to transfer an established connection
between machines (from router to backend), it requires some more
infrastructure. The kernel on the chosen backend must be synced up on the
connection state (sequence numbers, etc) that TCP_REPAIR provides, but that’s
actually just the easy part. It must also be able to send packets to the client
with the original server’s IP address as source, and packets going from the
client to the backend must somehow find their way to the same backend, in a
network-efficient way.
There are other problems Continue reading