Bouncy Castle 1.85 fixes 32 CVEs, and no scanner will flag them

Thirty-two vulnerabilities have been published at once for Bouncy Castle, the standard cryptography library for Java. The identifiers went live on August 3, 2026, assigned by the project itself. Four are rated critical, twenty-two high.

The fix is in 1.85, released July 12, 2026. Treat everything at 1.84 or below as affected. The long-term support line is 2.73.12, and the FIPS edition has a different version per component (more on that below).

Now the part that makes this interesting. Twenty-nine of the thirty-two were found using AI-assisted analysis. The CVE records carry the reporter credit "Alex Gaynor in collaboration with Claude and Anthropic Research." Twenty-nine findings in a single library is among the largest AI-originated disclosures published so far.

And yet — almost none of these thirty-two will show up in the vulnerability scanner you are using. Zero of thirty-two are registered in GitHub's advisory database. Dependabot and GitHub Advanced Security are both silent. Here is the whole picture, in order.

Which version is actually safe

Bouncy Castle ships in three lines, and each line has a different fixed version number. Mixing them up produces the "we upgraded and it still isn't fixed" outcome.

On the standard line this is simple: bring all eight components, starting with org.bouncycastle:bcprov-jdk18on, to 1.85. Use mvn dependency:tree or gradle dependencies to surface versions other libraries are pulling in behind your back.

Numerically, migration has barely started. Public dependency data shows 1,256 components referencing the fixed 1.85, against 7,433 still on the vulnerable 1.84 and 8,749 on 1.78.1.

The FIPS edition makes this considerably messier

Systems built for banks and government agencies use the FIPS edition, which carries US government cryptographic module certification. Here, "just go to 1.85" does not apply. Each component has its own fixed version, and the 1.0.x, 2.0.x and 2.1.x series each have different numbers again.

This table was assembled by cross-referencing the affected-version data in all thirty-two CVE records. We also confirmed, one by one, that each version actually exists on Maven Central.

One naming trap is easy to fall into. The FIPS provider is bc-fips, not bcprov-fips. Because the standard provider is bcprov-jdk18on, searching for the obvious name finds nothing.

There is a worse problem. The vendor's own FIPS download page does not carry the fixed provider. What is listed is 2.1.2, 2.0.1 and 1.0.2.6 — the fixed 2.1.3, 2.0.2 and 1.0.2.7 are absent (they do exist on Maven Central). Follow the official instructions and you will not reach the patched build.

Note also that FIPS certification was obtained against 2.1.0 and 2.0.0, so the fixed 2.1.3 is not a certified version. Environments with certification requirements face a choice between the security fix and the compliance requirement. That depends entirely on the organization, so we will not tell you which way to go.

The four rated critical

Four of the thirty-two are rated 9.3 out of 10. All four share a character: a check that was supposed to be protecting you was quietly passing everything through.

CVE-2026-59638: Hostname verification fell back to a weak mode by default

The broadest of the four. When TLS confirms the server on the other end is genuine, it matches the hostname recorded in the certificate. There is an older matching method (reading the common name) and a current one; the older one is weak against impersonation, so it was meant to be something you opt into explicitly. In the implementation it was enabled by default. The documentation and the actual behaviour disagreed.

CVE-2026-58062: A revocation check passed using another certificate's response

In the mechanism that checks whether a certificate has been revoked (OCSP), the response received was never bound to the certificate being validated. Present a "no problem" response belonging to some other valid certificate, and a revoked certificate passes.

CVE-2026-8763: One trailing dot bypassed certificate issuance limits

Intermediate certificate authorities can be constrained to issue only within a certain range. In the check enforcing that constraint, adding a single trailing dot — user@bank.com. — made the value stop matching the exclusion list. A CA believed to be constrained could issue outside its range.

CVE-2026-59650: A peer-supplied value went into the maths unvalidated

During key agreement, a value received from the other party was fed straight into the computation without confirming it fell in the valid range. Sending a crafted value opens room to steer the resulting shared key toward something the attacker wants.

The remaining twenty-eight have a similar flavour. Signed data with zero signers returned "verification succeeded" (CVE-2026-59639); signature verification skipped the last two bytes of the hash (CVE-2026-12860); plaintext was written into the caller's buffer before the tamper check finished (CVE-2026-58061) — and so on. Not dramatic takeovers, but a run of "the check nominally happened, and did nothing". For a cryptography library, that is the more troubling kind.

Who goes after this, and what for

What these thirty-two put at risk is not your server as such. The target is the judgement your server makes when it concludes "this peer is genuine" or "this signature is valid".

Concretely, this suits someone positioned in the communication path: whoever runs the public Wi-Fi, an intruder holding a network device along the route, or anyone able to obtain an improperly issued certificate. What they do is get a forged server or a forged signature accepted as the genuine article. Loose hostname matching lets a fake site pass as real; an unbound revocation check brings a revoked certificate back to life.

What makes the damage unusual is that nothing breaks when it works. No error appears, no anomaly reaches the logs, the connection completes normally. From the user's side, the login works and the transaction finishes as always. Meanwhile the contents are being read by a third party, or the peer is not who it claims to be. Monitoring that looks for traces of intrusion will not catch this.

That said, no exploitation has been reported. None of the thirty-two appear on the US CISA list of vulnerabilities known to be exploited (KEV) either.

Who found the twenty-nine

The CVE records name the reporter: "Alex Gaynor in collaboration with Claude and Anthropic Research." Twenty-nine of the thirty-two carry that credit.

According to his GitHub profile, Alex Gaynor is an engineer at Anthropic. He has served on the boards of the Python Software Foundation and the Django Software Foundation, and maintains pyca/cryptography, Python's principal cryptography library. He was a known name in cryptographic implementation long before this. An AI did not find these on its own; a specialist in the field used AI as a tool.

In a July 15, 2026 post he argued that you cannot bug-fix your way out of the "vulnpocalypse" (opening with the disclosure "I work for Anthropic"). New tooling is extracting vulnerabilities from existing software in volumes that break our assumptions about how many there are; fixing them one at a time cannot keep up, so the investment belongs in designs that eliminate whole classes of flaw. These thirty-two are an illustration of that argument.

Anthropic publishes a disclosure policy for vulnerabilities Claude finds: a 90-day deadline, a 7-day target for critical flaws under active exploitation, human review of every report with AI involvement explicitly labelled, and no bulk submissions without prior coordination. The company's May 2026 interim report states that scanning over 1,000 open-source projects produced 23,019 findings, of which 6,202 were high or critical, 530 have been disclosed and 75 patched.

To be clear, that post is not about these thirty-two. It announces separate research the company published on July 28, looking for mathematical weaknesses in cryptographic algorithms themselves rather than bugs in implementations. Anthropic has published nothing official about the Bouncy Castle batch. It appears on neither the company's news nor research pages, nor on its disclosure dashboard; the CVE records are effectively the only primary source.

The vendor's own announcement names neither Gaynor, nor Claude, nor Anthropic. All the 1.85 release announcement says is that the hardening came about "as a result of the help the team has received from people using advanced AI-based coding analysis tools." No proper nouns anywhere.

Not all thirty-two were found by AI

Worth stating plainly. The AI-originated count is twenty-nine, not thirty-two. The other three have different reporters.

CVE-2026-13506 also lists a separate finder under the handle "Yt," with Gaynor named alongside as reporter. Writing "AI found 32 vulnerabilities" would erase the work of real researchers.

Your tooling still will not tell you

This is the part with the most practical bite. An AI finding twenty-nine flaws is worth nothing if the information does not arrive. Right now, it mostly has not.

NVD caught up the same day. When this article first went out the count was 23; the remaining nine (CVE-2026-12802, 12803, 12816, 12817, 12852, 12860, 13506, 13586 and 14682) were ingested during the early afternoon of August 3, so all 32 are now retrievable there. GitHub Advisory has not moved. We queried GitHub's API for all thirty-two identifiers individually and got empty results every time. As a control, an older Bouncy Castle identifier returns one advisory correctly, so the API is not broken. They simply are not registered.

JVN iPedia is worse still: its Bouncy Castle coverage stops in 2023. There is not a single entry for 2024, 2025 or 2026. Organizations tracking vulnerabilities through Japan's national database have received nothing on this library for two years, let alone these thirty-two.

One more detail. Of the thirty-two "vendor advisory" links the CVE records point to, thirty-one are dead. All of them target project wiki pages, and only one such page has been created. That one page uses a non-standard hyphen character in its filename, so the link from the CVE side does not resolve and redirects to the wiki index instead. The project's disclosure policy states that advisories are published within a few days of the fixing release; three weeks past the release, the count is one.

For quick dependency checks there are tools such as our paste-your-package-list scanner, though that one covers npm and Python. For Java you are back to the commands above. For this batch specifically, work on the assumption that none of the automated machinery can be relied on.

Vulnerable versions are in active use in Japan

"A Java cryptography library" may sound remote, but it turns up close to home. And as far as public information goes, every case below is on a pre-fix version.

First, OSSTech's "LibJeID" is a library for reading the IC chips in My Number cards, driving licences, passports and residence cards from NFC-capable smartphones. It is used for identity verification and counter operations. The company's release notes record "2026-04-02: updated to Bouncy Castle LTS 2.73.10." The fixed version is 2.73.12.

Second, NTT Data's Java framework Nablarch uses Bouncy Castle in its sample for sending digitally signed mail. The configuration in the official documentation specifies bcjmail-jdk18on at 1.78.1. That component is directly hit by the S/MIME signing-time validation flaw in this batch (CVE-2026-59641). To its credit, the same documentation explicitly instructs readers to check for newer releases.

Third, GMO Payment Gateway states in a technical blog post that it chose Bouncy Castle for PGP encryption in the merchant file-exchange option of its utility-billing payment service (presented at JJUG CCC Fall 2025). The bcpg component that handles PGP carries five of this batch's flaws. The version in use is not stated in the post, so whether it is affected is unconfirmed.

None of this asserts that any of them is at risk. It notes that the versions verifiable from public information predate the fix.

How large is AI-assisted vulnerability discovery now

To place twenty-nine findings in one library against what has come before.

The aggregate trend is larger still. Epoch AI's analysis puts high and critical CVEs published in June 2026 at roughly 1,500, more than 3.5 times the previous monthly record of about 400 to 430. The count is restricted to disclosures from 21 well-known organizations including Microsoft, Google, Apple, Oracle and Cisco, so obscure filings are not inflating it.

We ran our own test some time ago, asking Claude Code and Codex to fix real vulnerabilities, and recorded one success in seventeen attempts. Finding and fixing are different capabilities — that was the conclusion then. These twenty-nine show the finding side reaching production scale. When VulnCheck counted in April 2026, Anthropic-credited CVEs totalled 40 across all vendors. The third-party tracker that follows them still lists only one for Bouncy Castle; this batch has not been added yet.

The fix has been out for three weeks

Laying out the dates shows what kind of event this is.

Twenty-two days separate the fix from the CVE publication. Through that window nothing was detectable, because no identifiers existed — so environments that auto-updated to 1.85 without knowing why coexisted with environments still on 1.84.

This "fix first, number later" order is not new for this library. The CVE-2024-14041 described next was also assigned an identifier more than two years after its fix.

Published July 2026: a private key leaking through timing, CVE-2024-14041

What follows concerns a separate vulnerability published on July 28, 2026. It is not part of the batch above, but it belongs to the same library, so we keep it here on the record.

CVE-2024-14041 allows a private key that must never leave the machine to be reconstructed by measuring, many times over, tiny differences in how long processing takes. The severity is 8.2 on CVSS 4.0.

This was already fixed in 1.78, released April 2024. Only environments stuck between 1.73 and 1.77 are affected. Anything at 1.72 or earlier is out of scope because the implementation of ML-KEM (formerly Kyber), the scheme where this occurs, did not exist yet.

A division instruction is enough to leak a key

This class of flaw is called a timing attack: inferring the secret values a program is handling not from its output but from how long it took.

The hinge is CPU division. On many processors, how long a division takes varies slightly with the contents of the dividend. The ML-KEM implementation contained several places that divided a secret value by a fixed, publicly known number (3329). The divisor being public does not help: if the dividend is secret, the elapsed time leaks information about it. Observe that across enough traffic, accumulate it statistically, and the long-term private key itself can be reconstructed.

The issue is known as KyberSlash. Bouncy Castle was affected in three places: Poly.toMsg, which extracts the decrypted message (KyberSlash1), and Poly.compressPoly / PolyVec.compressPolyVec, which compress ciphertext (KyberSlash2). The compression that runs during encryption is not affected, because the values it handles end up as public ciphertext anyway. Only the decryption side matters.

The fix is straightforward. Two changes, on December 16, 2023 and January 5, 2024, replaced every division on secret data with a combination of multiplication and bit shifts. Multiplies and shifts take the same time regardless of contents.

That post is from cryptographer Daniel J. Bernstein, announcing the issue in December 2023. KyberSlash was first noticed by the Cryspen team, who were building a formally verified Kyber implementation; they reported it to pq-crystals and the first site was fixed on December 1, 2023. Bernstein found it independently and published a working key-recovery demonstration on December 30 that year. The resulting paper won best paper at CHES 2025, reporting key recovery "in minutes for KyberSlash2 and hours for KyberSlash1." This is a working attack, not a theoretical one.

Few attackers can actually use it

This technique is not available to someone scanning indiscriminately for weak servers. It requires being positioned to send tens or hundreds of thousands of requests to a server that keeps reusing the same key, and to measure each response time precisely — a neighbouring virtual machine on the same cloud, a position inside the same network, or similar.

What such an attacker does is reconstruct the server's long-term private key computationally from the distribution of measured timings. With the key in hand, they decrypt traffic as a legitimate recipient. No trace of intrusion is left. What is lost is everything that key protected, potentially including previously recorded traffic. Assembling those preconditions is demanding, though, and this is not something you stumble into via mass scanning.

The class of flaw that post-quantum migration will keep producing

ML-KEM is the flagship of post-quantum cryptography, designed to resist future quantum computers, and was standardized by the US National Institute of Standards and Technology as FIPS 203 in 2024. Google has said publicly that it treats 2029 as the point where today's cryptography starts to break.

What KyberSlash demonstrated is unglamorous and heavy: a mathematically sound scheme still leaks the key if the implementation is written a certain way. And the cause was not advanced cryptanalysis — it was using one division. The thirty-two above are the same in character: about implementations, not schemes. Flaws in cryptography libraries tend to undermine the foundation of trust in ways that are hard to notice, as with node-forge's signature forgery.

What to check now

First, count the Bouncy Castle copies in your dependency graph. Even where you never declared it, other libraries frequently pull it in. Use mvn dependency:tree or gradle dependencies to surface transitive versions. Well-known projects such as the Keycloak identity platform track Bouncy Castle vulnerability work as an open issue.

Second, move to the fixed version for your line: 1.85 on the standard line, 2.73.12 on LTS. For FIPS, check component by component against the table above. This is the easiest thing to get wrong here.

Third, do not trust the automated check. Dependabot staying quiet does not mean you are clear. For this batch, a green scanner most likely means the data has not been registered yet. There is no way to confirm this other than reading version numbers by hand.

Fourth, if anything between 1.73 and 1.77 survives, CVE-2024-14041 above also applies. Going to 1.85 resolves both. As for how much to panic when a staple Java component has a hole, this is not the Fastjson takeover: that one was unauthenticated and immediate, this one is conditional verification bypass. Rank the urgency separately.

Summary

Thirty-two vulnerabilities were published for Bouncy Castle at once — four critical, twenty-two high — mostly of the "the check nominally happened and did nothing" variety. The fix is 1.85 on the standard line, 2.73.12 on LTS, and a per-component version on FIPS. Treat 1.84 and earlier as affected. No exploitation has been reported.

Twenty-nine of the thirty-two were found by an engineer at Anthropic using AI. There is no precedent for that scale in a single library. But not all thirty-two were AI-found: three came from other researchers.

And the point this article most wants to land is not the glamorous discovery but the fact that those twenty-nine have reached zero scanners worldwide. GHSA zero, Debian zero, Ubuntu zero, JVN zero. Thirty-one of the vendor's own detail links are dead. The machinery for delivering findings has not kept pace with the machinery for producing them. The more vulnerabilities AI extracts, the wider that gap grows. This time it showed up in numbers you can read off a page.

Sources

• ▸Bouncy Castle - 1.85 release announcement (list of 32 CVEs)
• ▸Bouncy Castle - FIPS edition downloads
• ▸Bouncy Castle - vulnerability disclosure policy
• ▸NVD - CVE-2026-59638 (hostname verification default)
• ▸NVD - CVE-2026-8763 (name constraints bypass)
• ▸Alex Gaynor, "You can't bug fix your way out of the vulnpocalypse"
• ▸Anthropic - coordinated vulnerability disclosure policy
• ▸Anthropic - Project Glasswing initial update (May 2026)
• ▸VulnCheck - counting Anthropic-credited CVEs (April 2026)
• ▸Epoch AI - trend in high-severity CVE publication
• ▸NVD - CVE-2024-14041 (KyberSlash)
• ▸KyberSlash - reference page (Daniel J. Bernstein and others)
• ▸KyberSlash - status by implementation
• ▸bc-java - KyberSlash1 (Poly.toMsg) fix commit
• ▸bc-java - KyberSlash2 (compression) fix commit
• ▸Paper: "KyberSlash: Exploiting secret-dependent division timings in Kyber implementations" (CHES 2025 best paper)