CVE-2026-8763

CVE-2026-8763 is a name constraint bypass in Bouncy Castle's X.509 validation where a trailing dot in DNS names is incorrectly treated as semantically equivalent to no trailing dot. When a CA certificate contains a Name Constraint permitting 'example.com' and a subordinate CA issues a certificate for 'example.com.' (with trailing dot), Bouncy Castle treats this as within the constrained namespace when it should reject it. A trailing dot defines an absolute FQDN per RFC 1034 — it terminates resolution at the DNS root and cannot be a suffix match. A name without a trailing dot is relative and may be resolved against search domains. These are not interchangeable, and the validation layer failed to reason about that distinction. Affected versions are 1.85, LTS releases before 2.73.12, and the FIPS-certified series BC-FJA 1.0.2.7, 2.0.2, and 2.1.3. The FIPS angle is significant: validation testing typically uses normalized certificate chains that never contain absolute DNS names with trailing dots, meaning the problematic code path was never exercised during certification. This is a boundary artifact — the certification validates cryptographic operations against a test suite, not semantic correctness against the full RFC surface area. For defenders, the priority is determining whether your PKI issues certificates with absolute DNS names in the SAN. If your CAs consistently produce normalized names without trailing dots, the practical exploitability is low — the vulnerable code path may never be triggered. However, if you're in a mixed environment or consume certificates from third-party CAs with non-normalized encodings, you should verify your Bouncy Castle version and apply the patch. The attack scope is CA-to-CA delegation: a subordinate CA could escape namespace restrictions imposed by its parent, effectively expanding its certificate authority beyond what was constitutionally permitted. This is not a single-certificate spoof — it's a constraint-evasion issue that affects all certificates issued under a misconfigured CA. The deeper takeaway is that name constraint validation operates on an implicit normalization model that RFC 5280 never formally specifies. Bouncy Castle's behavior diverged from OpenSSL and JSSE, which normalize trailing dots. If you're running Bouncy Castle alongside other TLS stacks in a trust chain, verify that you're not relying on inconsistent name-equivalence assumptions that could create silent validation gaps.

Reviewed through automated stages and approved by a human before publication.