2026-08-03 · view entry permalink →
Bouncy Castle for Java 1.85 — 32 CVEs published three weeks after the silent fix: three certificate-validation bypasses and a static Diffie-Hellman key-recovery flaw rated critical
Bouncy Castle for Java 1.85 and 1.85.1 shipped on 2026-07-12, and the write-ups describing what those releases fixed only became public on 2026-08-03, when the maintainer published a per-flaw page for each of the 32 identifiers (Legion of the Bouncy Castle, 2026-08-03). The project's official release notes carry the authoritative id-to-flaw list, and its own one-line summaries are the safest binding to work from (Legion of the Bouncy Castle, 2026-08-03). Nothing in the batch is reported exploited and no proof-of-concept is public, but the disclosure clears the out-of-band bar on its own mechanics rather than on exploitation: the fixed binaries have been available for three weeks, the fix commits are linked from each write-up, and the root-cause detail is now specific enough — class, method and the exact comparison that goes wrong — that reconstruction is a reading exercise for anyone who wants one, while any estate still on an older release remains exactly as exposed as it was.
Four flaws carry the batch's highest severity rating — the per-CVE scores are in this entry's CVE metadata — and they are not variations on one bug. Three attack certificate-chain validation, each removing a different guarantee; the fourth is not a certificate flaw at all but a key-recovery bug in a Diffie-Hellman agreement, and it is grouped here only by severity. In CVE-2026-58062 the JCA revocation checker accepts a stapled OCSP response that was never bound to the certificate being checked, so a validly-signed "good" response covering some other certificate is treated as proof the end-entity is unrevoked instead of being rejected in favour of a CRL fallback (Legion of the Bouncy Castle, 2026-08-03). CVE-2026-59638 is a default-configuration inversion: HostnameUtil gates the legacy 'match CN when no dNSName SAN exists' fallback (the maintainer's own phrasing) on a two-argument property lookup that returns the caller-supplied default of true when the property is unset, and as the maintainer puts it, "The javadoc for the property says the unset default must DISABLE the fallback, but the code ships with it active in every deployment that doesn't explicitly set the property to false" — an issue present since 1.61 (Legion of the Bouncy Castle, 2026-08-03). Because RFC 5280 name constraints only bind SAN entries of the constrained type, a leaf certificate carrying no dNSName SAN passes a dNSName-constrained chain and is then matched on its attacker-chosen CN. The odd one out is CVE-2026-59650, which involves no certificate, chain or PKIX code path: it is a missing peer-value check in the MTI/A0 two-pass Diffie-Hellman agreement, which exponentiates the raw wire value with no range or subgroup-membership test: the write-up states that "each exchange leaks x mod r for some small prime r; combining these via CRT recovers the full static private key" — the classical small-subgroup confinement attack, against a static key (Legion of the Bouncy Castle, 2026-08-03). CVE-2026-8763 is an inconsistency in PKIXNameConstraintValidator, which strips trailing dots before comparing dNSName constraints but compares rfc822Name and URI hosts with a bare case-insensitive equality, so a trailing dot slips an excluded name past the check and "An attacker who controls a name-constrained intermediate CA can issue certificates for email/URI hosts that the constraints were meant to exclude" (Legion of the Bouncy Castle, 2026-08-03).
The rest of the batch matters less individually and more as patch-scope. Around fourteen more are integrity and authenticity bypasses in the CMS, S/MIME, OpenPGP and AEAD code paths — among them a CMS signature check that returns success for signed data carrying no signers at all (CVE-2026-59639), an RSA PKCS#1 verification path that skips the last two hash bytes when the DigestInfo NULL is omitted (CVE-2026-12860), an S/MIME validator that trusts a signer-asserted signing time for path validation (CVE-2026-59641), and CCM-family modes that write plaintext into the caller's buffer before the tag is checked (CVE-2026-58061). The remainder are resource-exhaustion defects where an attacker-supplied file or message dictates allocation or work factor: unbounded KDF cost when loading BCFKS, PKCS#12 and PKCS#8 material, quadratic-time X.500 name stringification, an unbounded HSS public-key level count, and a DTLS reassembler sizing a buffer from an unchecked 24-bit length. All 32 are fixed in 1.85, and most — though not all — also in BC-LTS 2.73.12; four of the batch never affected BC-LTS, which this entry's CVE metadata records per identifier. The FIPS modules carry their own per-module fixed builds, and there are at least three families rather than one: bc-fips 1.0.2.7, 2.0.2 and 2.1.3 for the provider flaws (Legion of the Bouncy Castle, 2026-08-03), bctls-fips 1.0.24, 2.0.24 and 2.1.24 for the JSSE hostname issue (Legion of the Bouncy Castle, 2026-08-03), and bcpg-fips 2.0.13 for at least one of the OpenPGP flaws (Legion of the Bouncy Castle, 2026-08-03). A FIPS estate has to resolve its exposure per module, not per product.
Detection here is an inventory problem before it is a telemetry one, because Bouncy Castle is overwhelmingly a transitive dependency: the first sweep is software-composition analysis over build manifests, container images and mobile packages for org.bouncycastle artifacts below the fixed versions, not a search for an application named "Bouncy Castle". Where a runtime check is warranted, the observable classes follow the mechanics — in OCSP responder logs, a response whose subject or serial does not correspond to the certificate that was actually being validated, where a CRL fallback should have fired instead; in TLS session telemetry from JSSE clients, peers accepted against a certificate with no dNSName SAN whose CN merely matches the target hostname. Discriminating the benign case is largely a matter of where the client terminates: a Bouncy Castle JSSE client talking to a pinned internal endpoint on a trusted segment produces the same telemetry with none of the risk, while the same client terminating against partner networks, VPN concentrators or any on-path-capable segment is where a forged chain would actually be presented. Two interim levers exist before a full upgrade: setting the JSSE hostname CN-fallback property explicitly to false, which is the control the maintainer names for CVE-2026-59638 (Legion of the Bouncy Castle, 2026-08-03), and the strict-DigestInfo property the release notes expose as org.bouncycastle.pkcs1.strict_digestinfo for CVE-2026-12860 (Legion of the Bouncy Castle, 2026-08-03). The OCSP-binding, Diffie-Hellman and name-constraint flaws have no configuration toggle and require the version bump.
One note on reading the maintainer's own advisory index, because it moved during the course of this reporting: the page filed under the CVE-2026-58062 slug initially displayed the write-up for CVE-2026-58063, the unrelated and much less severe keystore issue, rather than the OCSP-binding flaw. The maintainer has since corrected it, and both pages now show their own content — checked again immediately before publication (Legion of the Bouncy Castle, 2026-08-03). It is recorded here only because anyone who triaged this batch from that index in its first hours would have read the most serious flaw in it as a denial-of-service bug, and may want to re-check what they concluded.
CVE-2026-58062 - Stapled OCSP response accepted without binding to the checked certificate.
The javadoc for the property says the unset default must DISABLE the fallback, but the code ships with it active in every deployment that doesn't explicitly set the property to false.
An attacker who controls a name-constrained intermediate CA can issue certificates for email/URI hosts that the constraints were meant to exclude.