CVE-2026-85515: 
Bouncy Castle vulnerability analysis and mitigation

CVE-2026-85515 is an OpenPGP message truncation vulnerability in Bouncy Castle for Java that causes truncated encrypted messages to be silently accepted without error or integrity verification. Disclosed on October 3, 2026, it affects bcpg versions 1.74–1.85, bcpg-lts8on versions 2.73.0–2.73.12, and bcpg-fips versions 1.0.7–1.0.13, 2.0.7–2.0.14.0, and 2.1.0–2.1.13. The vulnerability is a partial residual of CVE-2026-12817 and was credited to researcher Arpan Sharma. It carries a CVSS v4.0 base score of 8.2 (High) (GitHub Advisory, BC-Java Wiki).

The root cause is classified as CWE-345 (Insufficient Verification of Data Authenticity) and CWE-354 (Improper Validation of Integrity Check Value). The flaw stems from BCPGInputStream.nextPacketTag() laundering an EOFException — raised when a truncated message leaves the outer packet length field unchanged — as a clean end-of-message signal, causing the packet stream to stop silently. Two distinct exploitation routes exist: on the AEAD path (SEIPDv2 / v5 AEAD packet), when a literal data packet ends on a chunk boundary and the consumer reads in sub-chunk increments, BcAEADUtil/JceAEADUtil never reach the trailing message tag that authenticates total plaintext length, so trailing packets (e.g., signatures) are silently dropped; on the SEIPDv1 (MDC) path, IntegrityProtectedInputStream only verifies the modification detection code from close(), which is never reached on a truncated message, meaning PGPEncryptedData.verify() never runs and CFB-decrypted plaintext is returned with zero integrity checking — 136 distinct single-byte ciphertext modifications were confirmed to produce accepted, altered plaintext. The fix (commit ab7a235) re-throws EOFException as a plain IOException in AEAD utilities and makes OpenPGPMessageInputStream.close() explicitly close the integrity-protected stream (BC-Java Wiki, Fix Commit).

The primary impact is an integrity bypass: an attacker positioned to intercept or modify OpenPGP-encrypted messages in transit can truncate the ciphertext while leaving the outer packet length unchanged, causing the recipient's application to silently accept and decrypt the message without raising any error or performing any integrity check. On the SEIPDv1 path, this enables active ciphertext manipulation — up to 136 confirmed single-byte modifications produced accepted, altered plaintext — effectively nullifying the MDC protection. On both paths, trailing packets such as digital signatures are silently dropped, causing a signed-and-encrypted message to be presented to the caller as a well-formed, unsigned message with an empty signature list. There is no confidentiality impact, but the integrity impact is high for any application relying on Bouncy Castle's high-level OpenPGP API for message authentication (GitHub Advisory, BC-Java Wiki).

No public proof-of-concept exploit code is known, and there is no evidence of in-the-wild exploitation at the time of disclosure (Feedly). Exploitation requires a network-level attacker capable of intercepting and modifying OpenPGP messages in transit (attack requirements: Present), but no privileges or user interaction are needed. The AEAD route is reachable for approximately 3 of every 131 consecutive payload lengths, while the SEIPDv1 route is reachable for roughly 1 in 16 payload lengths — making reachability a property of the message structure rather than purely attacker-controlled input. The vulnerability is not listed in the CISA KEV catalog, and no EPSS score is currently published.

1. Identify target: Determine that the target application uses Bouncy Castle's high-level OpenPGP API (org.bouncycastle.openpgp.api) with a vulnerable version of bcpg (1.74–1.85), bcpg-lts8on (2.73.0–2.73.12), or bcpg-fips (affected ranges) to decrypt messages.
2. Position for interception: Establish a man-in-the-middle position on the network path where OpenPGP-encrypted messages are transmitted (e.g., via ARP spoofing, BGP hijacking, or a compromised relay).
3. Identify exploitable message shape: For the SEIPDv1 route, craft or wait for a message where the preceding packet ends on a cipher block boundary (occurs ~1 in 16 payload lengths). For the AEAD route, identify messages where the literal data packet ends on an AEAD chunk boundary (occurs ~3 in 131 payload lengths).
4. Truncate the ciphertext: Remove trailing ciphertext bytes (including the signature packet and/or final AEAD tag) while leaving the outer packet length field unchanged. This causes BCPGInputStream.PartialInputStream to raise an EOFException that is laundered as a clean end-of-message.
5. Optionally modify ciphertext (SEIPDv1 only): On the SEIPDv1 path, apply single-byte modifications to the CFB-mode ciphertext to alter the decrypted plaintext, since no MDC check will be performed.
6. Deliver to recipient: Forward the truncated (and optionally modified) message to the recipient. The vulnerable library decrypts and returns the plaintext with no error, no integrity exception, and an empty signature list — the message appears as a valid, unsigned plaintext to the application (BC-Java Wiki, GitHub Advisory).

• Application Behavior: OpenPGP messages that are processed successfully but return an empty or zero-length signature list when signatures were expected — callers that inspect signature count rather than only checking for exceptions may detect this anomaly.
• Logs: Absence of integrity verification errors or PGPException entries in application logs when processing messages that should have triggered MDC or AEAD tag verification failures; unexpected successful decryption of messages with altered content.
• Network: OpenPGP-encrypted traffic where the outer packet length field does not match the actual ciphertext length (detectable via deep packet inspection); truncated PGP message streams that terminate before the expected signature or final AEAD tag packet.
• File System: Decrypted output files with unexpected content or size discrepancies compared to known-good originals, particularly in automated OpenPGP processing pipelines.

Upgrade to the following fixed versions as appropriate for your deployment: bcpg (standard) → 1.86 or later; bcpg-lts8on (LTS) → 2.73.13 or later; bcpg-fips (FIPS) → 1.0.14 (1.0.x series), 2.0.14.1 (2.0.x series), or 2.1.14 (2.1.x series). As a workaround for applications that cannot immediately upgrade, use the low-level API and invoke PGPEncryptedData.verify() directly after decryption — this path is unaffected by the vulnerability. Additionally, consumers reading AEAD streams in increments of a full AEAD chunk or larger were not affected by the AEAD route. Applications should also validate that the signature count on decrypted messages is non-zero when signatures are expected, as a defense-in-depth measure (GitHub Advisory, BC-Java Wiki).