On 8/3/2026 7:37 PM, Peter Gutmann wrote: Alan Coopersmith <alan.coopersmith () oracle com> writes: It also says the release contains fixes for the following CVEs: Given the quantity and sweeping scope of those, was this the result of some new tool used for code analysis? I'm assuming AI, it sounds like there'd be an interesting backstory to how all of this was turned up. I didn't see anything in the announcements from the Bouncy Castle folks about that.

They do have more info about the CVE's in their wiki, such as: https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%908763 but I don't see any reference there to how they were found/reported.

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

Alan Coopersmith <alan.coopersmith () oracle com> writes: It also says the release contains fixes for the following CVEs: Given the quantity and sweeping scope of those, was this the result of some new tool used for code analysis? I'm assuming AI, it sounds like there'd be an interesting backstory to how all of this was turned up.

Peter.

Alan Coopersmith <alan.coopersmith () oracle com> writes: The common failure is accepting the sender provided length for the authentication tag, and not enforcing the minimum length specified in the RFC - allowing an attacker to specify a one-byte tag length and then use brute force to determine which of the 256 possible values matches the first byte of the actual tag. As with far too many other RFCs, the required skill for them isn't implementing them correctly, it's knowing which bits you need to ignore in order to implement them appropriately. I just checked my code and it hardcodes an allowed MAC length range of 16 ... 64 bytes for RFC 6476 use (Authenticated-Enveloped-Data, but with an explicit MAC), so no matter what any RFC says you can't feed it a MAC value less than 128 bits.

And an additional thought, these are all very high-visibility libraries and therefore obvious targets for checking whether they get it right. Given the failure rate with those, I wonder how many other lesser-known ones also got it wrong?

Peter.

https://blog.calif.io/p/how-to-format-a-ciphertext discusses how the issue that OpenSSL disclosed on June 9 as CVE-2026-34182 similarly affected the PKCS#7 / CMS parsing implementations from WolfSSL, Bouncy Castle, & GnuPG.

The common failure is accepting the sender provided length for the authentication tag, and not enforcing the minimum length specified in the RFC - allowing an attacker to specify a one-byte tag length and then use brute force to determine which of the 256 possible values matches the first byte of the actual tag.

The OpenSSL CVE-2026-34182 was already covered on oss-security in: https://www.openwall.com/lists/oss-security/2026/06/09/15

The WolfSSL CVE-2026-5500 was also already sent here in: https://www.openwall.com/lists/oss-security/2026/04/14/6

https://x.com/califio/status/2068786334844715142 notes: Both Bouncy Castle and GnuPG have acknowledged and fixed the reported issues.

CVE-2026-12802 will be published with Bouncy Castle 1.85. -- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris