By ByteBot
Thirteen years. Zero vulnerabilities. A perfect security track record that ended on December 30, 2025.
Libsodium, one of the most trusted cryptographic libraries in the world, disclosed its first-ever CVE. The flaw—a point validation bug in a low-level elliptic curve function—was discovered by the library’s own creator, Frank Denis, while comparing code implementations between C and Zig. And here’s the interesting part: it wasn’t a sophisticated attack or an external researcher who found it. Zig did.
How Zig Caught What 13 Years of Scrutiny Missed
Denis was experimenting with batch signature support in December 2025 when he noticed inconsistent results between his C implementation and code he’d originally written in Zig. The Zig version had a validation check the C code lacked. That missing check? It had been invisible to thousands of security researchers for over a decade.
The bug affected crypto_core_ed25519_is_valid_point(), a low-level function meant to validate elliptic curve points for Edwards25519 cryptography. It checked that X = 0 after multiplying by the group order, but forgot to verify Y = Z. The result: some invalid points incorrectly passed validation.
This is where Zig’s safety features matter. The language enforces strict compile-time checks—overflow detection on both signed and unsigned integers, Unbuffered Sanitizer (UBSan) runtime verification. It caught what C’s more permissive model didn’t. And it raises a question: how many other subtle bugs are lurking in battle-tested code, waiting for a different language to expose them?
Most Developers Aren’t Affected
Before anyone panics: the impact is limited. This function is low-level, used only by developers implementing custom cryptographic schemes with Edwards25519 point arithmetic. If you’re using libsodium’s high-level signing or encryption APIs—which most developers are—you’re fine. The standard implementations don’t touch this function.
Denis patched it immediately. Any libsodium version released after December 30, 2025 includes the fix. If you’re using version 1.0.20 or earlier and calling crypto_core_ed25519_is_valid_point() on untrusted input, update now.
Thirteen Years Without a Single CVE
Let’s put this in context. Libsodium has powered encryption for WordPress verified updates, Facebook’s OpenR routing protocol, and Zcash cryptocurrency since around 2012. It’s been under heavy scrutiny from security researchers the entire time. Cryptography libraries are high-value targets. Yet until December 30, 2025, its CVE count was zero.
Compare that to OpenSSL, which has weathered multiple major vulnerabilities—Heartbleed, Lucky Thirteen, and others. The difference comes down to design philosophy. Libsodium is opinionated: minimal configuration, simple API, hard to misuse. OpenSSL is flexible: many options, complex API, requires security expertise to use correctly. Simpler defaults mean fewer developer mistakes, which means better security outcomes.
Security experts have long recommended libsodium for exactly this reason. As Paragon Initiative put it: developers could have avoided poor cryptography choices “had they just used libsodium and moved on with their lives.”
Transparency Matters More Than Perfection
Denis found the bug himself. He disclosed it publicly the same day. He provided technical details, the fix, and recommendations for developers. No downplaying, no hiding. That’s how security disclosure should work.
Will this hurt libsodium’s reputation? Probably not. In fact, transparent disclosure often strengthens trust. The Hacker News thread that hit the front page on December 31 reflects this: technical discussion, respect for the track record, no panic. The security community understands that perfect code doesn’t exist. What matters is how you handle vulnerabilities when you find them.
This is the opposite of companies that bury bugs, downplay impact, or delay patches. Denis’s approach—immediate disclosure, clear communication, actionable fixes—demonstrates active maintenance and responsible stewardship. If anything, this reinforces why libsodium is trusted.
Use Ristretto255 for Custom Implementations
Denis’s disclosure came with a recommendation: if you’re implementing custom cryptographic schemes, stop using raw Edwards25519. Use Ristretto255 instead.
Ristretto255, added to libsodium in 2019, is a technique for constructing prime-order elliptic curve groups with non-malleable encodings. Translation: “If a point decodes, it’s safe. No further validation required.” It eliminates the cofactor complexity that caused this vulnerability—and others, like the multi-spend bug in Monero cryptocurrency.
The industry is moving toward safer abstractions like Ristretto255 precisely because raw curve operations are error-prone. Even experts make mistakes. Denis’s advice: use the higher-level tool designed to prevent them.
The Broader Lesson
No cryptographic library is perfect, no matter how battle-tested. Thirteen years of scrutiny didn’t catch this bug. A cross-language comparison did. That’s a data point worth remembering.
For developers, the takeaways are clear: update to libsodium versions released after December 30, 2025. If you’re doing custom crypto, switch to Ristretto255. And if you’re choosing a cryptography library, trust the ones with transparent disclosure practices. Libsodium just proved why that matters.
