Cloudflare Accidentally DDoSes Itself

On September 12, 2025, Cloudflare techs had one of those panicked “Did you turn it off and back on again?” kind of days. Except that instead of rebooting their Wi-Fi router for some max FPS, it was their entire dashboard and API system crashing. To the outside world, it appeared to be a massive, malicious DDoS attack from a nefarious player. But the truth is Cloudflare accidentally DDoSed… itself.

What is CloudFlare

Cloudflare is a web infrastructure and security company founded in 2010 that helps keep websites fast, reliable, and secure. Headquartered in San Francisco, it operates one of the largest global networks, handling over 20% of internet traffic. Cloudflare provides services like content delivery (CDN) to speed up sites, DDoS protection to guard against massive traffic floods, DNS resolution through its popular 1.1.1.1 service, and a web application firewall to block hackers. It also offers developer tools such as Cloudflare Workers and Pages for building apps at the network edge, along with Zero Trust security solutions for businesses. For most internet users, Cloudflare is invisible, but it powers millions of sites behind the scenes, acting as both a shield and a fast lane for the modern web. In other words, their main job, their reason to exist, is to protect sites from DDOS, which makes this even a smidge funnier.

The Bug That Broke the Dashboard

A React useEffect bug in the Cloudflare dashboard made the frontend spam their own backend. The effect ran more often than intended and repeatedly hit the Tenant Service API, which had just been updated and wasn’t resilient enough under that burst. The combo created a feedback loop: more renders → more requests → more failures → more retries. Result: dashboard and management APIs face-planted, while the edge network kept serving sites normally.

Who Felt the Pain

The outage was the control panel only:

* Dashboard: Broken. Logins, settings, and UI actions failed.
* Management APIs: Many calls returned errors, so DNS/firewall/Workers/Pages changes failed.
* Tenant Service API: Overloaded.
* Edge network and customer sites: Still serving traffic as usual.

What useEffect Is (and why it failed here)

CloudFlare uses React. React is an open-source JavaScript library used to build fast user interfaces. In React, the function useEffect is a hook used for running side effects in a component, like fetching data, starting timers, or subscribing to events. Its signature looks like this:

useEffect(() => {
// the effect: do something after render
}, [dependencies]); // re-run only when these change


* The function runs after render.
* React re-runs it whenever anything in the dependency array changes.
* Dependencies are compared by reference. That means “new object each render” counts as “changed,” even if it looks the same.

Correct usage (stable deps)

useEffect(() => { fetchData(); }, [userId]);
// Runs when userId changes

Buggy usage (unstable deps recreated each render)

useEffect(() => { fetchData(); }, [{}]);
// {} is a new object every render → constant re-runs → API storm

Cloudflare’s bug boiled down to unstable dependencies, causing the effect to re-run continuously and overload their APIs. With a fragile backend build behind it — then things snowballed and snowballed and snowballed.

Geeky Takeaway

Cloudflare’s edge stayed rock solid, but the control plane tripped over its own shoelaces like Larry in a Stooges film. A minor useEffect error, combined with a sensitive API rollout, led to hours of chaos. Credit to Cloudflare for quickly rolling and stabilizing the service as well as adding future safeguards. Truth is, we’ve all been there, brother! Just ask the team at MajorGeeks how many times I have personally borked the site. Our hearts goes out to whoever took the fall on this. But it’s a reminder that if you’re not careful about effect dependencies, retries, and rate limits, you probably won't be Employee of the Month and get that sweet parking spot.