🟢CVE-2026-8763, CVE-2026-13506

Overview

This advisory addresses two known security vulnerabilities identified in a third-party dependency used within DPGW. Both are fixed by the same Bouncy Castle release, so they are covered by a single advisory.

Vulnerability Details

  • CVE ID: CVE-2026-8763, CVE-2026-13506
  • Dependency Name:
    • org.bouncycastle:bcprov-jdk18on (direct dependency)
    • org.bouncycastle:bcpkix-jdk18on (direct dependency)
    • org.bouncycastle:bcutil-jdk18on (transitive, via bcpkix-jdk18on)
  • Affected Version of Dependency: all versions < 1.85 — fixed in 1.85 (released 2026-07-12)
  • Severity Score:
    • CVE-2026-8763 — Name Constraints bypass via trailing dot in rfc822Name and URI (CWE-295): NIST 9.1 Critical
      (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N), CNA 9.3 Critical
      (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N)
    • CVE-2026-13506 — Lazy ASN.1 sequence forcing resets nesting-depth guard (CWE-674): NIST 7.5 High
      (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), CNA 8.7 High
      (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N)

Affected Versions of DPGW

All branches in scope bundle a vulnerable version of the library:

  • 1.12 — all releases (<= 1.12.54-REL), bundles bcprov-jdk18on / bcpkix-jdk18on / bcutil-jdk18on 1.84
  • 1.13 — all releases (<= 1.13.34-REL), bundles bcprov-jdk18on / bcpkix-jdk18on / bcutil-jdk18on 1.84
  • 1.14 — all releases (<= 1.14.11-REL), bundles bcprov-jdk18on / bcpkix-jdk18on / bcutil-jdk18on 1.84

For completeness: 1.11 (<= 1.11.47-REL) bundles bcprov-jdk18on 1.78.1 and bcpkix-jdk18on 1.81, which also fall into the affected range. The analysis below applies to that branch unchanged.

Risk Assessment & Applicability

Usage
DPGW declares bcprov-jdk18on and bcpkix-jdk18on as direct dependencies; bcutil-jdk18on is pulled in transitively by bcpkix-jdk18on. dependency:tree -Dincludes=org.bouncycastle on 1.12, 1.13 and 1.14 shows no other Bouncy Castle artifact in the tree (the bcprov-jdk15on that org.apache.cxf:cxf-rt-ws-security would otherwise contribute is explicitly excluded in the POM).
Bouncy Castle is registered as a JCA provider in DPGWMain (and, for the CLI entry point, in CmdLineRunner) with
‘Security.addProvider(new BouncyCastleProvider());’
Security.addProvider() appends the provider to the end of the provider list — it is not inserted at position 1. Provider-less JCA lookups such as CertificateFactory.getInstance("X.509"), CertPathValidator.getInstance("PKIX") and TrustManagerFactory.getInstance("PKIX") therefore continue to resolve to the JDK’s own SUN / SunJSSE providers. Bouncy Castle is only reached where DPGW asks for it explicitly.
TLS does not go through Bouncy Castle. bctls / BCJSSE is not on the classpath. The HTTPS connectors in WebServerImpl are built with org.jsslutils.sslcontext.PKIXSSLContextFactory, which uses TrustManagerFactory.getInstance(...) and CertificateFactory.getInstance("X.509") without a provider argument, i.e. the JDK’s SunJSSE/SUN implementation. The same applies to the LDAP, e-mail and HL7 client socket factories. WS-Security (wss4j via CXF) is used only to attach an outbound UsernameToken; no inbound signature verification or Merlin crypto configuration is present.

Analysis
CVE-2026-8763 — Name Constraints bypass. In PKIXNameConstraintValidator, the dNSName path strips trailing dots before comparison, while the rfc822Name (isEmailConstrained) and URI (isURIConstrained) paths compare the extracted host with a bare equalsIgnoreCase. A leaf certificate with a SAN rfc822Name of ceo@bank.com. therefore does not match an excludedSubtrees entry of bank.com, so checkExcludedEmail never throws and the path validates. Exploitation requires two things: the vulnerable code must actually run — it is reachable only through PKIXCertPathValidatorSpi_8 → RFC3280CertPathUtilities.processCertBC, i.e. through Bouncy Castle’s own CertPathValidator/TrustManagerFactory implementation — and the trust path must contain a name-constrained intermediate CA under the attacker’s control.
Neither precondition holds in DPGW:

  • No component requests a CertPathValidator, CertPathBuilder or TrustManagerFactory from the "BC" provider, and because BouncyCastleProvider is appended rather than inserted first, the provider-less lookups performed by jsslutils and by the JDK resolve to SunJSSE. Client-certificate authentication on the HTTPS connectors, and every outbound TLS client, are validated by the JDK’s own PKIX implementation, which is not affected by this CVE.
  • DPGW neither issues nor consumes certificates carrying a NameConstraints extension. CAUtils.issueCert() adds only basicConstraints (CA=false), subjectKeyIdentifier and authorityKeyIdentifier — the subjectAlternativeName block in that method is commented out — and no occurrence of NameConstraints, permittedSubtrees or excludedSubtrees exists anywhere in the codebase. Without a name-constrained CA in the chain there is nothing for the bypass to bypass.

CVE-2026-13506 — ASN.1 nesting-depth guard reset. LazyEncodedSequence.force() creates a fresh ASN1InputStream with a re-initialised nesting-depth counter instead of inheriting the remaining depth from the parse that produced it. An attacker who can supply a ~40–50 KB DER structure whose content is a chain of ~10 000 nested SEQUENCEs then causes hashCode()/equals()/toDERObject()/getEncoded()/isSignatureValid() to recurse one Java frame per level with a fresh depth budget each time, producing an uncaught StackOverflowError that kills the handling thread.
The defect is only reachable where lazy evaluation is switched on. In bcprov/bcpkix 1.84 that is the case in exactly two places outside the lazy machinery itself: X509CRLHolder.parseStream() (new ASN1InputStream(stream, true)) and Bouncy Castle’s own JCE CertificateFactory CRL path. Every other entry point — including ASN1Primitive.fromByteArray() and the ASN1InputStream(byte[]) constructor — parses non-lazily and remains protected by the ordinary nesting-depth guard (org.bouncycastle.asn1.max_cons_depth, default 32).
DPGW reaches neither of the two lazy paths. It is also worth noting up front that DPGW performs no CMS, PKCS#7, timestamp (TSP), OCSP or DICOM digital-signature parsing at all — none of those Bouncy Castle APIs appear in the codebase — so the parsing surface is limited to the PEM/PKCS#10 and key-loading paths listed under Usage.

Status
Not Affected

Impact on DPGW

No impact.

CVE-2026-8763 cannot be triggered because Bouncy Castle’s PKIX certificate path validator is never selected — all certificate chain validation, including client-certificate authentication on the HTTPS connectors, is performed by the JDK — and because no certificate handled by DPGW carries a Name Constraints extension.
CVE-2026-13506 cannot be triggered because the lazy ASN.1 evaluation mode that resets the depth guard is only enabled on Bouncy Castle’s CRL parsing paths, which DPGW does not use: it generates CRLs rather than parsing them, and reads CRL files through the JDK’s CertificateFactory. All Bouncy Castle parsing of externally supplied data in DPGW is non-lazy and remains covered by the standard nesting-depth limit.

Remediation & Mitigations

Scheduled fix
Although DPGW is not affected, the vulnerable dependency version will be cleared from the builds as hygiene. Bouncy Castle will be updated from 1.84 to a release >= 1.85 (current upstream release 1.86, published 2026-09-11) for bcprov-jdk18on, bcpkix-jdk18on and the transitively managed bcutil-jdk18on:

  • 1.14 — 1.14.12-REL (release date not yet fixed)
  • 1.13 — 1.13.35-REL (release date not yet fixed)
  • 1.12 — 1.12.55-REL (release date not yet fixed)

User Actions
No user action required.