WhatsApp just pulled off something remarkable. They rewrote their entire media processing library in Rust and shipped it to over 3 billion users across Android, iOS, Mac, Web, and even wearables. This isn’t some experimental feature flag or a gradual rollout to 5% of users. This is production code running on billions of devices right now, processing every image, video, and document you share on WhatsApp, Messenger, and Instagram.
The scale is genuinely unprecedented. I’ve seen companies talk about adopting Rust for new projects or rewriting small components, but WhatsApp replaced 160,000 lines of C++ with 90,000 lines of Rust. And somehow, the Rust version ended up being faster and using less memory than the original.
The Stagefright Wake-Up Call
Let me take you back to 2015. Android had this nasty vulnerability called Stagefright that lived in the OS-level media processing libraries. The problem? WhatsApp couldn’t fix it. Neither could any other app. The bug was in Android itself, and all they could do was wait for Google to patch it and then wait even longer for users to actually update their phones.
This is the nightmare scenario for any security team. You know there’s a vulnerability. You know attackers are probably already exploiting it. And you can’t do anything about it except tell users to “please update your phone.”
WhatsApp’s solution was clever. They had this internal C++ library called “wamedia” that they used to send and format MP4 files consistently across platforms. They realized they could modify it to detect malformed media files that didn’t follow the MP4 standard properly. These non-conformant files were exactly the kind of thing that would trigger bugs in vulnerable OS libraries.
So they rolled out checks that would catch these malicious files before they ever reached the vulnerable Android media libraries. It worked. They protected users faster than waiting for OS updates.
But here’s the thing: this library was now sitting in the hot path, automatically processing untrusted media files from the internet. Every image someone sends you, every video, every PDF. All of it flows through wamedia. If there’s a memory safety bug in wamedia itself, you’ve just created a new attack vector.
Why Rust Actually Matters Here
Memory safety vulnerabilities are not some theoretical concern. WhatsApp says explicitly that most of their high severity vulnerabilities came from memory safety issues in C and C++ code. Buffer overflows, use-after-free bugs, all the classics.
The traditional approach is to layer on protections: Control Flow Integrity, hardened memory allocators, safer APIs, security training for developers, strict code review. WhatsApp does all of that. But it’s fundamentally defensive. You’re trying to write safe code in a language that makes it easy to write unsafe code.
Rust flips this around. The language itself won’t let you compile code with data races or memory safety violations (unless you explicitly use unsafe blocks, which you can audit carefully). This isn’t marketing speak, it’s a genuine architectural difference that changes what kinds of bugs are even possible.
The rewrite wasn’t quick or easy. WhatsApp developed the Rust version in parallel with the existing C++ version. They used differential fuzzing to make sure both implementations produced identical results on millions of test cases. They ran extensive integration tests. They had to solve real engineering challenges like dealing with binary size increases from pulling in the Rust standard library and getting the build system to work across all their platforms.
This is where a lot of Rust adoption stories end, actually. Someone gets excited about Rust, writes a prototype, then realizes their iOS build is now 50MB larger and their CI pipeline doesn’t support cross-compilation to 15 different targets. WhatsApp made what they call a “long-term bet” to build that infrastructure. They committed to solving the hard problems.
Kaleidoscope: Beyond Format Checking
The media processing story gets more interesting. WhatsApp built this whole system they call “Kaleidoscope” on top of the Rust library. It’s not just checking if files are valid MP4s or JPEGs.
They detect file type masquerading, where someone renames a malicious executable to have a .jpg extension or lies about the MIME type. They look for risk indicators in file types that are frequently used for malware delivery. PDFs with embedded files or JavaScript, for example, get flagged because those features are legitimate but also commonly abused.
They watch for parser differential exploits, where attackers craft files that one parser interprets differently from another. This is a surprisingly common attack pattern. You send a file that looks benign to the security scanner but gets interpreted as malicious code by the actual media player.
None of these checks are foolproof. WhatsApp is honest about this, they say “format checks will not stop every attack.” But defense in depth matters. Every layer makes the attacker’s job harder, forces them to find more vulnerabilities, increases the chances they’ll make a mistake you can detect.
The Production Reality
What strikes me most about this story is that it’s not aspirational. This isn’t a blog post about how Rust will solve all our problems someday. The code is already running. It’s been running for a while now, processing billions of files every single day.
The Rust version ships to phones, laptops, desktops, watches, browsers. Multiple operating systems. This is client-side code with all the constraints that implies: binary size matters, startup time matters, battery life matters, cross-compilation is mandatory not optional.
And it works. It’s faster than the C++ version. It uses less memory. It’s more secure by construction.
I think this is an important data point for the industry. There’s been this narrative that Rust is great for new projects but too risky or too expensive to use for rewriting existing critical infrastructure. WhatsApp just demonstrated that’s not true. You can rewrite massive, complex, performance-critical security systems in Rust and ship them to billions of users.
The article mentions that Meta’s security teams are now “highlighting opportunities for high impact adoption of Rust to interested teams” and they expect adoption to accelerate. That’s corporate speak for “this worked really well and we’re going to do more of it.”
What This Means For The Rest Of Us
I don’t work at Meta and I’m not getting paid to promote Rust. But I do write a lot of software that processes untrusted input, and I think about these tradeoffs constantly.
The honest truth is that most companies won’t rewrite 160,000 lines of C++ in Rust. They don’t have WhatsApp’s resources or their user scale to justify the investment. But what WhatsApp did do is prove that it’s possible. They built the infrastructure, solved the cross-platform build problems, figured out how to differential fuzz two implementations, and documented what actually works in production.
That matters because the next company that wants to do this doesn’t have to solve all those problems from scratch. The tooling will get better. The patterns will become more established. The binary size overhead will come down as the Rust ecosystem matures.
Memory safety vulnerabilities aren’t going away. C and C++ codebases that process untrusted input will keep shipping security bugs because that’s what happens when you write complex code in memory-unsafe languages. You can be as careful as you want, have all the code review and static analysis you want, and bugs will still slip through.
WhatsApp’s bet is that preventing entire classes of vulnerabilities at compile time is worth the upfront cost of a rewrite and the ongoing cost of working in a younger ecosystem. Given that they’re now running this code on billions of devices and actively expanding their Rust usage, I’d say the bet paid off.