Cloudflare Outage on December 5: What Went Wrong

On December 5, 2025, at 08:47 UTC, a portion of Cloudflare's network began serving errors at scale. The incident lasted approximately 25 minutes, with full service restoration at 09:12 UTC. During that window, roughly 28% of all HTTP traffic routed through Cloudflare was impacted, affecting customers who met a specific set of conditions.

The disruption was not the result of a cyber attack or any malicious activity. It was triggered by changes Cloudflare was making to its body parsing logic as part of an effort to mitigate CVE-2025-55182, a critical vulnerability in React Server Components disclosed earlier in the week.

Root Cause: A Buffer Increase and a Disabled Test Tool

Cloudflare's Web Application Firewall (WAF) buffers HTTP request bodies in memory to analyze them for malicious payloads. Prior to this incident, the buffer size was set to 128KB. To broaden protection against the React vulnerability, Cloudflare began rolling out an increase to 1MB—the default limit permitted by Next.js applications.

That change was deployed through Cloudflare's gradual deployment system. However, during the rollout, the team noticed that an internal WAF testing tool did not support the larger buffer size. Since the internal tool was not required at the time and had no effect on customer traffic, a second change was made to turn it off. This second change was pushed through Cloudflare's global configuration system, which propagates changes to the entire server fleet within seconds, unlike the gradual rollout system.

The interaction between these two changes proved problematic. When the global configuration propagated, it caused an error state in Cloudflare's FL1 proxy under certain conditions, leading to HTTP 500 errors being served to end users.

Why Only Some Customers Were Affected

Impact was limited to customers whose web assets were served by the older FL1 proxy and who had the Cloudflare Managed Ruleset deployed. Requests to sites meeting both criteria returned HTTP 500 errors, with the exception of certain test endpoints like /cdn-cgi/trace. Traffic on the China network and customers not meeting both conditions were unaffected.

The error traced back to the ruleset evaluation system. Cloudflare's rulesets consist of rules, each with a filter that selects traffic and an action. Actions can include block, log, or skip. For internal testing, Cloudflare uses an action of execute to trigger evaluation of a separate ruleset containing test rules—and it was these test rules that were being disabled at the time of the incident.

Cloudflare's killswitch subsystem is designed to quickly disable a misbehaving rule. It receives updates from the global configuration system. While the killswitch procedure was followed per the Standard Operating Procedure, this was the first time it had been applied to a rule with an execute action. When the killswitch was applied, the code skipped evaluating the execute action and its associated sub-ruleset. However, the code that processed the overall ruleset evaluation results expected the skipped rule's result object to exist. Because it did not, the Lua-based code in the FL1 proxy threw an exception when attempting to look up a value in a nil object. The error had been latent in the codebase for years. The newer FL2 proxy, written in Rust, handles this case correctly due to its stronger type system.

Reflections on the Broader Context

This incident bears clear similarities to the outage on November 18. In both cases, a change intended to mitigate a security issue propagated network-wide and generated errors for the vast majority of customers. According to Cloudflare, the mitigation work discussed with customers after November 18 incidents would likely have reduced the impact of this new event—but that work was not yet fully deployed.

Cloudflare has outlined several projects intended to prevent such incidents from recurring:

  • Enhanced Rollouts & Versioning: Extend gradual deployment and health validation practices used for software releases to configuration data and rapid threat response updates, with quick rollback capabilities.
  • Streamlined break glass capabilities: Guarantee that critical operations can still be executed in the face of additional failure scenarios, across both internal services and standard customer-facing control plane functions.
  • "Fail-Open" Error Handling: Replace hard-fail logic in critical data-plane components. Where configuration is corrupt or out-of-range, the system should log the error and revert to a known-good state rather than dropping requests. Some services may offer customers a choice between fail-open and fail-closed behavior in specific scenarios.

Cloudflare states that all network changes are currently locked down until better mitigation and rollback mechanisms are in place. A detailed breakdown of the resilience work is expected to be published before the end of next week.

This marks the second major availability disruption for Cloudflare in two weeks—an unacceptable pattern for a network of this scale. The team has issued an apology to customers and the broader internet community for the continued impact.