Bouncy Castle Java EUVD-2026-52136

Two concurrent conditions are required for exploitation. First, the plaintext encrypted under OpenPGP AEAD must be an exact multiple of the configured AEAD chunk length - this is an inherent numerical property of the data rather than a configurable option, meaning it occurs naturally for a non-trivial fraction of real-world messages and files. Second, the attacker must be able to modify the OpenPGP ciphertext after it is produced - either via a network-level man-in-the-middle position or direct write access to the file or message store holding encrypted data. The vulnerability is scoped strictly to the OpenPGP AEAD decryption path (SEIPDv2 per RFC 9580 and the legacy v5 AEAD packet); standard MDC-protected PGP messages (SEIPDv1) use a separate code path and are not affected. Confidentiality of surviving ciphertext chunks is not compromised because each chunk's individual AEAD tag remains intact and valid; only integrity of the overall message length and the presence of trailing chunks is bypassed.

The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N) scores 8.7, reflecting a network-reachable unauthenticated integrity bypass with no stated attack complexity. Real-world risk is genuine but gated: exploitation requires the attacker to both reach a position where they can modify OpenPGP ciphertext (MITM or storage write access) and encounter a chunk-aligned plaintext, which is a natural property of certain file sizes rather than a configuration knob. The integrity failure mode is entirely silent - no exception is raised, verify() returns true, and the recipient application receives truncated plaintext with no indication of tampering - making detection difficult without supplementary out-of-band integrity checks. No EPSS data was provided in the input. No public exploit code exists and the vulnerability is not in CISA KEV, suggesting exploitation has not been observed in the wild at time of analysis. However, the combination of a widely-deployed library, a silent failure mode, and the complete absence of a backstop in the verify() method makes this a genuine remediation priority for any application relying on OpenPGP AEAD for message authenticity - particularly document signing workflows, secure file transfer pipelines, and encrypted email systems.

An attacker with write access to stored OpenPGP AEAD-encrypted files - or positioned as a man-in-the-middle on the encrypted message transport - identifies a ciphertext whose plaintext length is a multiple of the AEAD chunk size, strips one or more trailing data chunks along with the final authentication tag, and patches the outer OpenPGP packet length field to reflect the reduced size. When the intended recipient's Bouncy Castle-based application decrypts the message, each surviving chunk passes its individual tag check, the decrypting stream reaches EOF without verifying the missing final tag, and PGPEncryptedData.verify() returns true - causing the application to silently process truncated plaintext as a fully authentic, unmodified message. No public proof-of-concept code has been identified at time of analysis.