- I'd encourage folks to read the recently-published statement [1] about the state of OpenSSL from Python's cryptography project.
[1]: https://news.ycombinator.com/item?id=46624352
- 2026 and we still have bugs from copying unbounded user input into fixed size stack buffers in security critical code. Oh well, maybe we'll fix it in the next 30 years instead.
- Can someone translate
"Applications and services that parse untrusted CMS or PKCS#7 content using AEAD ciphers (e.g., S/MIME AuthEnvelopedData with AES-GCM) are vulnerable"
to human?
by pizlonator
0 subcomment
- I just looked at the vuln in detail.
If you are using OpenSSL compiled with Fil-C, then you're safe. This attack will be nothing more than a denial of service (the attacker won't get to actually clobber the stack, or heap, or anything).
by TacticalCoder
2 subcomments
- Very strange, as I type this both Bullseye and Bookworm are marked as fixed but Trixie isn't yet:
https://security-tracker.debian.org/tracker/CVE-2025-11187
by alanfranz
5 subcomments
- Is this really exploitable? Is stack smashing really still a thing on any modern platform?
by notherhack
1 subcomments
- Looks like Debian and some other distros are still on the vulnerable 3.5.4. Why did Openssl publish before the distros rolled to the fixed version?
- Has anyone built OpenSSL with -fbounds-safety?
- Another "fix" in the long line of OpenSSL "fixes" that includes no changes to tests and therefore can't really be said to fix anything. Professional standards of software development are simply absent in the project, and apparently it cannot be reformed, because we've all been waiting a long time for OpenSSL to get its act together.
- Please use Rust.