CVE-2026-8763: Critical Name Constraints Bypass in Bouncy Castle

CVE-2026-8763 is a critical (CVSS 9.1) certificate validation flaw in Bouncy Castle for Java. A trailing dot in an email or URI name lets a certificate slip past name constraints that should have excluded it. Upgrade to BC 1.85, BC-LTS 2.73.12, or the fixed BC-FJA FIPS releases listed below.

What's affected

The Bouncy Castle project wiki page for this CVE lists the affected and fixed versions:

• Bouncy Castle for Java (BC): before 1.85, fixed in 1.85
• Bouncy Castle LTS (BC-LTS): before 2.73.12, fixed in 2.73.12
• Bouncy Castle FIPS Java API (BC-FJA): fixed in bc-fips 1.0.2.7 for the 1.0.x series, 2.0.2 for the 2.0.x series and 2.1.3 for the 2.1.x series

The platform is Java 8 and later. The project says the flawed code is reachable from the production certificate path validator, so applications that validate certificate chains with Bouncy Castle are the ones to look at.

How to check if you're exposed

Bouncy Castle usually arrives as a transitive dependency, so list it from your build tool.

Maven:

mvn dependency:tree | grep -i bouncycastle

Gradle:

gradle dependencies | grep -i bouncycastle

Note the artifact names and versions, for example the provider and PKIX artifacts. Also check fat jars and application servers that ship their own copy, which a build tree will not show. For those, list the jars in the deployment and read the version in each file name or manifest.

Then ask whether your code uses name constraints at all. The flaw matters when a certificate chain includes an intermediate authority that carries constraints on email or URI names, and your application validates that chain with Bouncy Castle.

What to do now

1. Inventory every application that includes Bouncy Castle, directly or through another library.
2. Upgrade to BC 1.85 or later, BC-LTS 2.73.12 or later, or the fixed FIPS release for your series.
3. Rebuild and redeploy, then confirm the new version is the one on the runtime classpath.
4. Check application servers and vendor products that bundle their own copy and ask the vendor for an update.
5. Review any private certificate authority that uses name constraints, and test that excluded names are rejected after the upgrade.

Dependency conflicts are the usual reason an upgrade appears to do nothing. If two libraries ask for different Bouncy Castle versions, your build tool picks one. After you change the version, print the dependency tree again and confirm the resolved version at runtime, not only in your build file.

For services that run in containers, rebuild the image rather than patching a running container, so every replica gets the same fixed jar.

Why it matters

The record lists CWE-295 (improper certificate validation). The project describes the cause plainly. The check for DNS names strips trailing dots before it compares names, but the checks for email and URI names compared the host with a plain case-insensitive match. A certificate naming the same host with an extra trailing dot therefore did not match an excluded subtree, so the exclusion never fired and the chain validated.

Name constraints are how a company limits what an intermediate authority may issue. If the constraint can be sidestepped, an authority that was meant to be limited could vouch for names outside its scope. That is why the integrity impact is high.

The record does not mark this CVE as known exploited, and it is not in the CISA KEV list.

Try it yourself

A library fixed this month may be one you added last year. Continuous monitoring turns a new advisory into a list of affected projects.

Click through it at your own pace, or open it full screen.

Quick check

If you want a quick look at your own dependencies, the free in-browser scan at gold.safeguard.sh/scan needs no repository access.

Sources

Fetched for this guide:

• https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%908763
• https://github.com/bcgit/bc-java/commit/2c28b253a44681fbbc562561eab6ad383d2ae558

Last reviewed: 19 October 2026.