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.
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.
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).
15 comments
[ 2.6 ms ] story [ 41.1 ms ] thread"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?
>The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue, as the CMS implementation is outside the OpenSSL FIPS module boundary.
"I hereby define the vulnerability to be outside the bit that I define to be secure, therefore we're not vulnerable".
https://security-tracker.debian.org/tracker/CVE-2025-11187
[1]: https://news.ycombinator.com/item?id=46624352
We are still suffering from that mistake, and LibreSSL is well-maintained and easier to migrate to than it ever was.
What the hell are we waiting for?
Is nobody at Debian, Fedora or Ubuntu able to step forward and set the direction?
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).