The Internet suffered a major disruption on December 5, 2025, after a failure inside Cloudflare’s network caused widespread unavailability for thousands of websites. The incident began at 08:47 UTC, and although it lasted only about 25 minutes, nearly 28% of all HTTP traffic routed through Cloudflare experienced errors.

According to Cloudflare, the outage was not the result of a cyberattack, malware, or any form of external compromise. Instead, the failure originated from an internal configuration update connected to urgent security adjustments the company was making in response to a newly disclosed vulnerability in React Server Components. The intention was to enhance protection—but the change unintentionally triggered a critical error in one of the company’s older proxy systems.

How the Outage Unfolded

Cloudflare engineers were rolling out updates to increase request body buffer sizes from 128KB to 1MB. This adjustment was meant to strengthen defenses against the industry-wide CVE-2025-55182 vulnerability affecting React. The deployment was gradual, using Cloudflare’s controlled rollout system.

During the update, an internal test tool began throwing errors. Since the tool wasn’t essential for live traffic, Cloudflare decided to temporarily disable it through their global configuration system—a system that deploys changes instantly across their entire global network.

This step triggered an unexpected failure in the FL1 version of Cloudflare’s proxy. Within seconds, websites using the older proxy combined with Cloudflare’s Managed Ruleset began returning HTTP 500 errors instead of loading normally. A few test endpoints like /cdn-cgi/trace continued working, but most traffic served through this configuration crashed.

The root cause? A long-standing but previously unseen bug in the proxy’s ruleset evaluation logic. When a feature called a “killswitch” was used to disable a rule that contained an “execute” action, the system attempted to access a value that no longer existed. This caused a Lua exception, immediately breaking request processing and resulting in 500 errors across affected zones.

Why the Bug Went Undetected

Cloudflare admitted that the faulty code had existed “for many years” and had never been triggered because a killswitch had never been applied to a rule containing an execute action before. In contrast, the newer FL2 proxy—written in Rust—handled the scenario correctly.

The outage was reversed at 09:12 UTC, after engineers rolled back the configuration change. Traffic began returning to normal instantly.

Why This Incident Is Serious

This is the second major Cloudflare outage within two weeks, following a separate incident on November 18. In both cases, systemwide changes meant to improve security inadvertently caused global disruption.

Cloudflare acknowledged customer frustration, noting that work on new resilience tools—like enhanced rollout controls, safer configuration systems, and fail-open logic—was still underway and not yet fully deployed.

The company apologized publicly, stressing that such incidents “are not acceptable for a network like ours” and promising a detailed breakdown of resilience projects in the coming week.

FAQ Section

Was the Cloudflare outage caused by a cyberattack?

No. Cloudflare confirmed that the outage had no connection to hacking, DDoS attacks, or malicious activity.

How long did the outage last?

Approximately 25 minutes, from 08:47 to 09:12 UTC.

Who was affected?

About 28% of Cloudflare’s global HTTP traffic—primarily websites running on the older FL1 proxy combined with the Managed Ruleset.

Will Cloudflare prevent this from happening again?

The company says upcoming resilience improvements—such as controlled rollouts, better rollback systems, and fail-open error handling—will reduce future risk.

Why did the configuration change propagate so rapidly?

Cloudflare’s global configuration system does not use phased rollouts; changes propagate globally within seconds.