New Release: Bouncy Castle Java 1.85 (fixes 32 CVEs!)

[Lonzak]

There was a release of Bouncy Castle Java 1.85 on July 28th.

The release includes additional features, fixed defects, and resolution to 32! CVEs.

• Expanded Post-Quantum Cryptography Support
• Practical Post-Quantum Migration for PKI
• High-Level CAdES API for Advanced Electronic Signatures
• Modernised CMS and Secure Messaging
• Enhanced Blockchain and Digital Asset Support

It also says the release contains fixes for the following CVEs:

•      CVE-2026-8763 - Name Constraints bypass via trailing dot in rfc822Name and URI.
•      CVE-2026-12185 - BKS/UBER keystore allocates from untrusted lengths before integrity check.
•      CVE-2026-12802 - CMS AuthEnvelopedData fails to enforce tag-length on decryption.
•      CVE-2026-12803 - KCCMBlockCipher MAC does not bind nonce when AAD is absent (cross-nonce AEAD forgery).
•      CVE-2026-12816 - IESEngine stream-mode MAC forgery via length-dependent KDF split.
•      CVE-2026-12817 - OpenPGP AEAD decryption skips final tag on chunk-aligned data.
•      CVE-2026-12852 - MLS wire decoder allocates attacker-declared opaque length before bounds check.
•      CVE-2026-12860 - RSA PKCS#1 verification skips last two hash bytes in NULL-omitted path.
•      CVE-2026-13506 - Lazy ASN.1 sequence forcing resets nesting-depth guard.
•      CVE-2026-13586 - PKCS#12 MAC and bag-decryption KDF iteration-count bound (DoS).
•      CVE-2026-14682 - Possible OOM from unbounded up-front allocation on a definite-length read.
•      CVE-2026-15055 - PKCS#8 / PBES2 decryptors honour unbounded KDF cost from input.
•      CVE-2026-58059 - Quadratic-time escaping when stringifying X.500 distinguished names.
•      CVE-2026-58060 - HSS public-key level count unbounded, enabling huge allocation on verify.
•      CVE-2026-58061 - CCM-family modes write plaintext to caller buffer before tag check.
•      CVE-2026-58062 - Stapled OCSP response accepted without binding to the checked certificate.
•      CVE-2026-58063 - BCFKS keystore load honours unbounded KDF cost from untrusted file.
•      CVE-2026-59638 - JSSE hostname verifier CN-fallback enabled by default despite documented opt-in.
•      CVE-2026-59639 - CMS verifySignatures returns true for SignedData with zero signers.
•      CVE-2026-59640 - OpenPGP CFB quick-check oracle active on symmetric/session-key paths.
•      CVE-2026-59641 - S/MIME validator trusts signer-asserted signingTime for path validation.
•      CVE-2026-59642 - CMS AuthenticatedData content not bound to MAC when authAttrs present.
•      CVE-2026-59643 - OpenPGP inline-signature policy failures silently ignored.
•      CVE-2026-59644 - MLS hash-ratchet honours arbitrary 32-bit generation counter from sender.
•      CVE-2026-59645 - OER parser recurses without depth limit on self-referential IEEE 1609.2 schema.
•      CVE-2026-59646 - DTLS handshake reassembler allocates buffer from unchecked 24-bit length.
•      CVE-2026-59647 - CRMF/CMP password-MAC honours unbounded iteration count.
•      CVE-2026-59648 - OpenPGP Argon2 S2K honours attacker-chosen memory and passes.
•      CVE-2026-59649 - OpenPGP user-attribute subpacket length bounded only by JVM max memory.
•      CVE-2026-59650 - MTI/A0 DH agreement exponentiates unvalidated peer value.
•      CVE-2026-59651 - BKS keystore accepts legacy version with 16-bit integrity MAC key.
•      CVE-2026-59652 - LDAP filter injection in legacy jdk1.4 LDAPStoreHelper.

For security reasons, it’s best to update but watch out before you update since the first issues for that version are coming in:

• Duplicate class org.bouncycastle.asn1.iana.IANAObjectIdentifiers in bcprov-jdk15to18 and bcutil-jdk15to18 1.85 #2356
• Certificate parsing in 1.85 rejects empty issuer DNs with no opt-out, breaking libp2p TLS interop #2387

Given the sheer number and broad scope of these findings, were they uncovered using a new code-analysis tool?
I would guess AI have been involved. It sounds like there is an interesting story behind how all of this came to light.

[dghgit]

Yep, we were the lucky (and I guess that really is true, although there have been moments in the last month or so where we have been reflecting on the risks associated with getting what you wished for) of several AI generated reports based on scans done of our github repositories. By way of further information, no idea what the token spend was, first round of reports included 83 items, there were about a dozen duplicates (scans are done using multiple sub-agents, it appears that what can happen is two, or more, sub-agents will find the same thing, but report on it slightly differently). There was one false positive. I'd definitely say it spoke well of the quality of the tool.

The duplicate class issue is fixed in a 1.85.1 point release, too many moving parts, but sorted out now. We are using AI tools now, it took a few weeks to get up to speed, partly due to the shock factor (I've been writing code since I was 14, even in an industry defined by constant change, I hardly expected to run into something that was going to cause an existential crisis 50 years later!) and also just getting a better understanding of what the tools can do and what they cannot (very important). We needed to invest time in things like AGENTS.md/CLAUDE.md (don't change them by hand either, get the tools to do it, it's not really natural language, it's "agent speak" and the tools know how to write it) and skills. The duplicate class was a good example of the result of a "gap" we hadn't picked up on.

I hate to say it, but #2387 probably would have happened anyway. We've spent the last couple of years working our way through the APIs trying to tighten things up. If you look at the history of "attacks" we seem to have moved into a world where sneaking things in that have side effects is popular, ensuring (where possible) that encoded inputs are precisely as they should be is really the only defense against this. That said, we do try to interoperate where we can. Can't blame the AI for that one, more that I had no idea that someone had, erm..., adapted X.509 in such a fashion. It'll be fixed in the 1.85.2 patch release we're working on now.

As for what happens next, well, we care about the security of the libraries, and we will use what ever we can get our hands that will help us improve that. I'd like to say "the worst" is over, but I'm not sure, although things certainly seem to have improved in terms of what is currently being reported using current technology, these tools are not deterministic, so things can show up that were previously missed. The contributions from 3rd parties though (both AI and not-AI, see the CVEs and CONTRIBUTORS file have been a great help though and we are grateful. That said, if someone asks me in Jan 2027 what I thought of 2026, I'm probably going to say it was one tough year.

<blatant-plug>For those interested in hearing more, I'll be giving a talk on this at the OpenSSL conference in Prague later this year. <blatant-plug>

It has been quite a wild ride.

[fencepost-error]

Did you deliberately allow empty DNs (as PKIX requires) or was it an accident? We disable that by default, along with a number of other PKIX booby-traps like path-kludge certificates where you can have a self-signed certificate in the middle of a path rather than at the root and things are supposed to work normally.

[Lonzak]

Reminds me of our journey with AI - thanks for sharing this story!

[dghgit]

@fencepost-error So, it's legal to have an empty subject DN providing the subjectAlternativeName is present. It's not legal to have an empty issuer, under that profile, we simply never enforced as under RFC 5280 a certificate like that will be rejected anyway. Turns out someone found a use case for an empty issuer as well - it's probably not something I'd encourage though.

@Lonzak I've feeling the journey is not over yet either. You're welcome!

[dghgit]

As a follow up, I've just put provider jars for a patch release 1.85.2 up on https://www.bouncycastle.org/betas which fixes all the current defects, or in some cases "features" which seem to be causing people issues. Feedback from people affected that the new jars are working okay would be most welcome.