The issue came from transpiled C code that was used to parse HTML. Writing parsers is hard, writing C is hard, as virtually all infosec people know shipping parsers in C is the perfect recipe for remote exploits.

At the time, Cloudflare was principally built as NGINX modules in C and Lua, which, without surprise, led to memory safety problems.

In February 2017, Rust, a "new" programming language promising memory safety, high performance and great C interoperability, released its version 1.15.

I'm not in Cloudflare's engineers and leadership heads, but the earliest post about Rust on Cloudflare's blog I can find is from January 2018. Probably not a coincidence.

Since then, Cloudflare has been on a relentless course of rewriting its proxy services in Rust, first by writing NGINX modules in Rust and then by replacing NGINX itself with Rust-based proxies and services.

(Diagram: Cloudflare proxies architecture, credit: Cloudflare)

In the diagram above, Pingora is already in Rust, FL is being gradually replaced by FL2 (FL version 2) which is in Rust, and the "HTTP & TLS Termination" layer, which is currently NGINX, is being rewritten... in Rust.

Rust is eating Cloudflare's proxy layer and they are replacing C code as fast as they can. On the other hand, the developer platform and API layer are developed in a mix of Go, TypeScript and probably a few other languages.

One of the many (unfair) advantages provided by Rust, is how easy it is to compile it to a C library to be used in other programming languages via FFI. For example, Cloudflare uses a Rust library in the proxy layer to match requests with rules, wirefilter (e.g. if http.user_agent == 'xxx' -> Block Request), and embeds the exact same library in the Go backend powering the API. Code once, use everywhere.

Pingora is Cloudflare's framework for "building fast, reliable and evolvable network services" which is Open Source.

It has been a huge boost in performance compared to the previous generation of NGINX-based proxies due to, among other things, better connections pooling to origins (the servers hosted behind Cloudflare).

Despite some outages, it's safe to say that Rust has been a huge reliability increase, a huge velocity boost, a huge performance win and therefore a huge costs saver for the company.

This is what happens when the leadershhip of tech companies understand (at least a little bit) tech.

A note on Cloudflare and Open Source

Like many big tech companies, Cloudflare has a pretty active GitHub, but don't be fooled, they are far from an Open Source company. As illustrated by this issue, some (most?) of their GitHub repositories are actually mirrors of their internal repositories and are pushed whenever they want, or can.

We can applaud the effort, but don't expect any kind of support or Open Source governance if your own projects rely on theirs.

November 18, 2025 outage

Less than 24 hours after the outage, Cloudflare already had published a detailed post-mortem, signed by the CEO himself. Bravo!

TL;DR: .unwrap() was called on a Result that was (wrongly) expected to never be Err due to configuration data that was (wrongly) assumed to never be malformed. Oops, sorry, beginner mistake. Always remember the first rule of programming: never trust unverified input.

So, how could it have been avoided?

Avoiding unwrap in Rust, or how the outage could have been prevented

In Rust, .unwrap() can be used on both Result<T, E> and Option<T>. If the value is Err or None, then the program panics.

In Cloudflare's case, .unwrap() was called on a Result with a Err value, which is bad! You should never call .unwrap() on a Result, especially when processing untrusted input (here a malformed configuration file), whatever your assumptions are. Err values should either be handled in place, or bubbled up to somewhere else.

On the other hand, it's not uncommon for Rust developers to .unwrap() on Option when they know (or think they know) that the value is Some(T), which is not a bad practice per se, but Rust gives us many tools to free our code of .unwrap() and thus make it more reliable, otherwise we are back to null-dereference bugs plaguing other languages.

Here is some code that I was often writing (not so) long time ago:

fn get_user_opt() -> Option<User> {
    // ...
}

fn do_something() {
    let user_opt = get_user_opt();
    if user_opt.is_none() {
        // do something else
    }
    let user = user_opt.unwrap();
    // do something
}

.ok_or() / .ok_or_else()

The first technique is to use .ok_or to transform an Option into a Result::Err:

fn do_something() -> Result<(), Error> {
    let user = get_user_opt().ok_or(Error::UserNotFound)?;
    // do something
}

match

Then, of course, there is match:

fn do_something() -> Result<(), Error> {
    let user = match get_user_opt() {
        Some(user) => user,
        None => return Err(Error::UserNotFound);
    };
    // do something
}

if let / let else

Even better, we now have two awesome features: let pattern deconstruction, and if let expressions:

fn do_something() -> Result<(), Error> {
    let Some(user) = get_user_opt() else {
        return Err(Error::UserNotFound);
    }
    // do something
}

fn do_something() -> Result<(), Error> {
    if let Some(user) = get_user_opt() {
        // do something
    } else {
        return Err(Error::UserNotFound);
    }
}

.unwrap() is a code smell and should be avoided at all costs. If you really, really need to .unwrap(), at least use .expect("with an easy-to-grep message").

Some closing thoughts

As I wrote previously, Rust is eating the world. It's the first full-stack programming language that can be used from bare-metal micro-controllers to cloud reverse proxies running on huge servers in data centers, like in Cloudflare's case.

Cloudflare, Google, and my own Pingoo all understand the unfair advantages provided by Rust enabling them to move fast and build vertically-integrated businesses that would only have been possible before with a mashup of many different programming languages and a huge number of developers maintaining fragile piles of mud.

Read the full post, including the author's further reading and book links, at kerkour.com.