CVE-2026-5588

What it actually does

This is a cryptographic weakness in Bouncy Castle Java BCPKIX certificate/signature verification code, associated with the JcaContentVerifierProviderBuilder and JcaContentVerfierProviderBuilder classes. Affected versions may rely on a broken or risky cryptographic algorithm during PKIX-related content verification. Where applications use the affected BCPKIX modules to validate signed data, certificates, certificate revocation artifacts, CMS/PKCS#7 messages, timestamp tokens, or other PKIX structures, an attacker may be able to influence verification behavior under specific conditions. The published CVSS indicates remote, unauthenticated exploitation is possible with low attack complexity, but with additional attack requirements and limited confidentiality impact only; integrity and availability impacts are not indicated by the vector.

Why it matters to the business

Applications that depend on vulnerable Bouncy Castle BCPKIX versions may make security decisions using unsafe cryptographic verification behavior. In business terms, systems that process certificates, signed files, signed messages, software updates, document signatures, identity assertions, or compliance evidence could make weaker trust decisions than intended. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has no reported exploit maturity, and has a low EPSS score of 0.0064, so it should be treated as important cryptographic hygiene rather than an active mass-exploitation emergency. Because Bouncy Castle is commonly embedded as a library, exposure may be indirect through Java applications, vendor products, and bundled dependencies.

How an attack unfolds

An attacker first identifies a Java application or product that uses an affected Bouncy Castle BCPKIX module for PKIX or content-signature verification. The attacker then supplies attacker-controlled cryptographic material to a feature that performs verification, such as certificate processing, signed message validation, signed document import, timestamp validation, S/MIME/CMS handling, or a trust-establishment workflow. If the application reaches the vulnerable verification path and the necessary attack prerequisites are met, the risky algorithm behavior may allow the attacker to obtain limited unauthorized disclosure or cause the application to treat cryptographic material differently than expected. Practical impact depends heavily on how the application uses BCPKIX, whether untrusted inputs reach the verifier, and what business decision is made after verification succeeds or fails.

How to fix it

Upgrade affected Bouncy Castle packages to fixed releases or later. For BC-JAVA BCPKIX, upgrade from 1.67-1.79 to at least 1.80.2, from 1.81 to at least 1.81.1, and from 1.82-1.83 to at least 1.84. For BCPKIX-FIPS, upgrade from 2.0.6-2.0.10 to at least 2.0.11 and from 2.1.7-2.1.10 to at least 2.1.11. For BCPIX-LTS, upgrade from 2.73.7-2.73.10 to at least 2.73.11. Update both direct and transitive dependencies, including shaded or repackaged Bouncy Castle JARs embedded in application archives. If immediate upgrade is not possible, reduce exposure by disabling or restricting unauthenticated upload/import of certificates and signed objects, enforcing strict allowlists for acceptable algorithms, rejecting legacy or weak signature algorithms, and ensuring verification results are not used as the sole basis for high-risk authorization decisions.

How to confirm the fix worked

Confirm all deployed Java artifacts use fixed Bouncy Castle versions. Inspect dependency manifests, build files, software bills of materials, container images, application archives, and vendor bundles for bcpkix, bcpkix-fips, bcprov, and related Bouncy Castle components. For Maven or Gradle projects, run dependency resolution commands and verify no affected versions remain in direct or transitive dependency trees. For packaged applications, inspect JAR names and MANIFEST.MF Implementation-Version values. Also search for shaded copies by looking for org/bouncycastle/pkix and the affected class names inside fat JARs or application archives. Functional validation should include regression tests for certificate, CMS/PKCS#7, timestamp, and signed-content verification workflows, with explicit negative tests for weak or disallowed algorithms.

Typical attack path

1. Find an internet-accessible or partner-facing Java application that accepts certificates, signed payloads, CMS/PKCS#7 data, timestamp tokens, signed documents, or similar PKIX-related inputs.
2. Determine or infer that the application uses a vulnerable Bouncy Castle BCPKIX version: BC-JAVA 1.67 before 1.80.2, 1.81 before 1.81.1, or 1.82 before 1.84; BCPKIX-FIPS 2.0.6 before 2.0.11 or 2.1.7 before 2.1.11; or BCPIX-LTS 2.73.7 before 2.73.11.
3. Craft cryptographic input that exercises the affected content-verification implementation and its risky algorithm handling.
4. Submit the crafted input to a verification workflow without needing authentication or user interaction, if the vulnerable feature is exposed remotely.
5. Leverage any resulting weak verification behavior to gain limited unauthorized access to protected information or to influence a trust-dependent workflow, depending on application design.

How to detect it

There are no reliable public indicators that uniquely prove exploitation of this library flaw, and successful abuse may appear as normal certificate or signed-content processing. To assess possible prior exploitation, review application logs for unusual spikes or repeated failures in certificate validation, CMS/PKCS#7 parsing, timestamp verification, signed document import, S/MIME processing, or trust-chain validation. Examine web, API, message-queue, and file-upload logs for untrusted certificate or signed-object submissions shortly before unexpected access, data retrieval, or trust-decision events. Enable or review debug-level logs from components that call Bouncy Castle verification routines, especially around rejected or unusual algorithms, malformed ASN.1 objects, unexpected signature algorithms, or abnormal certificate chains. For forensic review, correlate suspicious signed inputs with application decisions that should have required strong cryptographic validation. Treat the presence of affected class names or vulnerable JAR versions as exposure evidence, not proof of compromise.

What your security team should do

• Inventory all Java applications, vendor products, containers, and build pipelines for Bouncy Castle BCPKIX usage, including shaded or bundled copies.
• Prioritize upgrades for externally reachable services and systems that process untrusted certificates, signed documents, signed messages, S/MIME/CMS data, timestamp tokens, or software-update metadata.
• Upgrade to BC-JAVA 1.80.2, 1.81.1, or 1.84 as applicable; BCPKIX-FIPS 2.0.11 or 2.1.11 as applicable; or BCPIX-LTS 2.73.11 or later.
• Add dependency-management controls to prevent reintroduction of vulnerable Bouncy Castle versions through transitive dependencies.
• Review cryptographic policy configuration and reject weak, deprecated, or unexpected signature algorithms at application boundaries.
• Ask vendors for patched builds or written confirmation when products embed Bouncy Castle but do not expose dependency versions.
• Because this is not currently KEV-listed, not ransomware-associated, and has low EPSS, schedule remediation through normal vulnerability management, but escalate if the affected library is used in authentication, code-signing, payment, identity, document-trust, or update-verification workflows.