CVE-2026-85515
HighCVSS 8.2Summary
In Bouncy Castle for Java before 1.86, a vulnerability allows truncated OpenPGP encrypted messages to be accepted without error. On the SEIPD version 1 path, no integrity check is performed at all, and on the AEAD path (SEIPD v2 and v5), the trailing authentication tag is skipped, silently dropping packets after the literal. The issue also affects LTS before 2.73.13 and FIPS (BC-FJA) before specified versions, but only on the AEAD route.
Risk Assessment
An organization may receive decrypted data that is not fully authenticated, which for signed and encrypted messages could lead to acceptance of modified content without detection. In the worst case (SEIPD v1), the lack of any integrity check allows an attacker to alter ciphertext that, after decryption, is treated as authentic.
Recommendation
Immediately update Bouncy Castle to version 1.86 or later (for LTS to 2.73.13, and for FIPS to the specified bcpg-fips versions). If an update is not possible, avoid using the high-level OpenPGP API and manually invoke PGPEncryptedData.verify() and read data in whole AEAD chunks.
Other vulnerabilities in Bouncy Castle
See all- CVE-2026-71891High
In Bouncy Castle for Java before 1.86, BLS12_381BasicScheme.keyValidate accepted public keys built on a foreign ECC curve that merely shares BLS12-381's field characteristic. This allowed aggregate signatures to verify with a phantom signer, even without a signature for that key and message pair.
- CVE-2026-71889High
In Bouncy Castle for Java before 1.86, both copies of PKIXCertPathReviewer (org.bouncycastle.pkix.jcajce and the legacy org.bouncycastle.x509) failed to apply X.509 name constraints to the end-entity certificate. The checkNameConstraints method walked the path with a loop bound excluding index zero (the target certificate), so the permitted and excluded subtree checks of RFC 5280 sec. 6.1.3 (b) and (c) never ran against the leaf's subject DN or subjectAltName. As a result, a chain whose leaf violated a NameConstraints extension imposed by its issuing CA was reported as valid (isValidCertPath() returned true with an empty error list), while CertPathValidator rejected the identical chain.
- CVE-2026-71886High
In Bouncy Castle for Java before 1.86, the high-level OpenPGP certificate API accepted third-party certifications or trust delegations from any component key of the issuing certificate, without requiring the component to have certification authority. An attacker could use a restricted subkey (e.g., signing-only or encryption-only) to issue a valid identity certification or trust delegation, which was then attributed to the primary key.
- CVE-2026-71883High
In Bouncy Castle for Java LTS before 2.73.13, the one-shot native packet ciphers for AES-CBC, CCM, CFB, CTR, GCM and GCM-SIV released the caller's key, IV and additional authenticated data arrays with JNI's ReleaseByteArrayElements in mode 0, which commits the native copy back into the Java array. When an application passed the same Java array as both input and destination (e.g., encrypting in place over KeyParameter.getKey()), the later mode-0 release wrote the unchanged key bytes over the ciphertext, exposing the raw AES key. The fix releases read-only input arrays with JNI_ABORT, preventing the copy-back.
- CVE-2026-71885Critical
In Bouncy Castle for Java before 1.86, the Messaging Layer Security (MLS, RFC 9420) implementation did not bind an X.509 credential to a LeafNode's signature_key. LeafNode.verify() checked a leaf's signature against the signature_key carried in the leaf itself, while the credential's X.509 certificate chain was stored but never parsed or validated, so the end-entity certificate's public key was never required to match signature_key as RFC 9420 sec. 5.3 requires. An attacker could present another party's certificate as its credential while signing the leaf, and the enclosing KeyPackage, with an unrelated key, and be accepted under that other party's identity through KeyPackage.verify() and the Group leaf-validation path.
- CVE-2026-58062Critical
In Bouncy Castle for Java before 1.85, a Stapled OCSP response is accepted without binding to the checked certificate. This issue also affects LTS before 2.73.12 and FIPS before 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series).
- CVE-2026-8763Critical
In Bouncy Castle for Java before 1.85, Name Constraints can be bypassed via a trailing dot in rfc822Name and URI. This issue also affects LTS before 2.73.12 and FIPS before appropriate versions.
- CVE-2026-59650Critical
In Bouncy Castle for Java before 1.85, the MTI/A0 Diffie-Hellman key agreement exponentiates an unvalidated peer value. This issue also affects LTS before 2.73.12.
- CVE-2026-17508Medium
In Bouncy Castle for Java before 1.86, several password-based key derivation entry points ran the KDF with cost parameters taken from the untrusted input being processed, without bounding them, so a small input could dictate an arbitrary amount of work before any password or integrity check could reject it. The affected paths are the RFC 9579 PBMAC1 MAC calculator builders, the scrypt parallelization parameter p in the PKCS#8 and PKCS#12 cost guards, the raw JCA PBKDF2 provider, and the bcrypt round count read from an encrypted OpenSSH v1 private key's own kdfoptions. Each now bounds the parameter before deriving, in line with the caps already applied elsewhere in the tree, with the OpenSSH round count configurable through the new org.bouncycastle.openssh.max_rounds property. This completes the bounding begun in 1.85 for the PKCS#8 / PBES2 decryptors (CVE-2026-15055). This issue also affects Bouncy Castle for Java LTS before 2.73.13, and Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series).
- CVE-2026-14682High
In Bouncy Castle for Java before 1.85, a possible Out-of-Memory (OOM) condition exists due to unbounded up-front allocation on a definite-length read. This issue also affects LTS and FIPS versions.
Original NVD description (English source)
In Bouncy Castle for Java before 1.86, a truncated OpenPGP encrypted message was accepted with no error reported, and on the SEIPD version 1 path with no integrity check performed at all. RFC 9580 sec. 13.7 permits an implementation to release the cleartext of the fully authenticated chunks when streaming but requires it to indicate a clear error as soon as the truncation is detected, and to report suspect integrity when it discovers malleable ciphertext. The truncation was detected and then discarded: when a message is truncated but the length field of the enclosing packet is left unchanged, BCPGInputStream.PartialInputStream raises an EOFException for the missing ciphertext, and BCPGInputStream.nextPacketTag() reports an EOFException as a clean end of message, so the packet stream above it stopped as though no packets remained. On the AEAD path (SEIPD version 2 and the version 5 AEAD packet), when the literal data packet ended on an AEAD chunk boundary and the consumer read in increments smaller than one chunk, the look-ahead for the packet after the literal triggered the truncated chunk read, so BcAEADUtil and JceAEADUtil never reached the trailing message tag of sec. 5.13.2 that authenticates the total plaintext length; the caller received the plaintext of the fully authenticated chunks, every packet following the literal was silently dropped, and no exception was raised, so a signed and encrypted message read back as a well-formed unsigned one. Every byte released on that path remained individually authenticated, making this a missing truncation error rather than a forgery, and it is a residual of CVE-2026-12817, which closed the same outcome for an attacker who corrects the outer packet length. On the SEIPD version 1 path the consequence was more serious: IntegrityProtectedInputStream verifies the modification detection code from close(), and reached close() only by closing itself when a read of it returned -1, which a truncated message never produces, so PGPEncryptedData.verify() never ran and the recipient was handed CFB-decrypted plaintext on which no integrity check of any kind had been performed. Measured on a message truncated into that shape, 136 distinct single-byte modifications of the ciphertext produced accepted, altered plaintext with no exception raised. Reachability is a property of the message rather than of attacker-supplied input: the AEAD shape held for 3 of 131 consecutive payload lengths measured, and the SEIPD version 1 shape for one payload length in sixteen, at a truncation offset that did not move with the payload length. The low-level API is unaffected, a caller that invokes PGPEncryptedData.verify() directly getting the check regardless, as are consumers reading in increments of a whole AEAD chunk or more. The AEAD decryption streams now re-throw such an EOFException as a plain IOException, which nextPacketTag() does not launder; OpenPGPMessageInputStream.close() now closes its layer's integrity-protected stream itself rather than relying on that stream having seen the end of its data; and IntegrityProtectedInputStream.close() was made idempotent, as java.io.Closeable requires, which that depends on, since the stream is genuinely closed twice on the ordinary path and PGPEncryptedData.verify() consumes the digest state behind it and cannot be run a second time. This issue also affects Bouncy Castle for Java LTS before 2.73.13, on the AEAD route only, as that edition does not ship the high-level OpenPGP API the SEIPDv1 route runs through. It also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpg-fips 1.0.14 (1.0.X series), 2.0.14.1 (2.0.X series) and 2.1.14 (2.1.X series), on the AEAD route only, as those editions do not ship the high-level OpenPGP API.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS