Cloudflare Suffers A Second Outage In Less Than A Month
Please note that we are not authorised to provide any investment advice. The content on this page is for information purposes only.
Cloudflare, a global network and security provider, suffered its second outage in less than a month, according to its blog post published December 5.
The company’s second incident, following the November 18 incident, affected multiple banking websites, such as Norway’s central bank, as well as multiple major firms, including Zoom, Shopify, and LinkedIn.
The previous outage caused a bigger problem, knocking out the website for longer, including X and ChatGPT, which were down for several hours. In comparison, the December 5 incident lasted for only 25 minutes total, but it was still quite noticeable, given the massive user bases of affected firms and banks.
The Outage Was Not Caused By An Attack Of Any Kind
The firm said that the incident affected a subset of customers, accounting for around 28% of all HTTP traffic served by Cloudflare. It also highlighted several factors that needed to be combined for an individual customer to be affected.
Commenting on the nature of the incident, Cloudflare stressed that it was not caused, directly or indirectly, by a cyber attack on its systems or malicious activity of any kind. The announcement says that it was triggered by changes being made to its body parsing logic while attempting to detect and mitigate an industry-wide vulnerability disclosed in React Server Components earlier last week.
“Any outage of our systems is unacceptable, and we know we have let the Internet down again following the incident on November 18. We will be publishing details next week about the work we are doing to stop these types of incidents from occurring,” Cloudflare said.
What Actually Happened
Commenting on what went wrong, the firm explained that, as part of its ongoing work to protect users against the critical vulnerability (CVE-2025-55182), the company started rolling out several minor changes. During the first such change, the company noticed that its internal WAF testing tool did not support the increased buffer size.
The second change was to turn it off, since it had no effect on customer traffic. However, to do so, the firm used a global configuration system that does not support gradual rollouts, which led to an error state that resulted in 500 HTTP error codes being served from its network.
In other words, the outage was caused by a chain reaction as Cloudflare attempted to patch the vulnerability unveiled earlier last week. The company explained what led to the incident in its blog post, noting that it will publish a detailed breakdown of all the resiliency projects underway before the end of this week, including the ones listed above.
