OpenPGP message truncation not reported, bypassing the SEIPDv1 integrity check (CVE-2026-85515)

What is affected, what to do

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.

Update Legion of the Bouncy Castle BC-JAVA to version 1.86, Legion of the Bouncy Castle BC-LTS-JAVA to version 2.73.13, Legion of the Bouncy Castle BC-FJA to version 1.0.14.

Affected

• Legion of the Bouncy Castle BC-JAVA lt 1.74..1.86
• Legion of the Bouncy Castle BC-LTS-JAVA lt 2.73.0..2.73.13
• Legion of the Bouncy Castle BC-FJA lt 1.0.7..1.0.14
• Legion of the Bouncy Castle BC-FJA lt 2.0.7..2.0.14.1
• Legion of the Bouncy Castle BC-FJA lt 2.1.0..2.1.14

Fixed in

• Legion of the Bouncy Castle BC-JAVA 1.86
• Legion of the Bouncy Castle BC-LTS-JAVA 2.73.13
• Legion of the Bouncy Castle BC-FJA 1.0.14
• Legion of the Bouncy Castle BC-FJA 2.0.14.1
• Legion of the Bouncy Castle BC-FJA 2.1.14

Not sure whether and how you are affected? Ask a question about this vulnerability

Metrics

Detection rules

No NEOSEC detection rule is available for this vulnerability yet.

Classification under NIS2 and CRA

Rule-based classification from exploitation status and severity. It does not replace a case-by-case assessment.

NIS2

NIS2 is EU Directive (EU) 2022/2555 to raise the level of cybersecurity across the Union. It substantially broadens obligations compared with the first NIS directive: more sectors, mandatory risk management, staged reporting duties and personal accountability of senior management.

Read in glossary

High technical severity: assess and remediate the vulnerability in vulnerability handling under Art. 21(2)(e) NIS2 and document the decision.

CRA

The CRA is EU Regulation (EU) 2024/2847 setting horizontal cybersecurity requirements for „products with digital elements“ — from industrial controllers and software to connected consumer devices. For the first time manufacturers must ensure security across the entire product lifecycle, handle vulnerabilities and provide security updates.

Read in glossary

From 11.12.2027, Annex I Part II CRA requires manufacturers of affected products with digital elements to handle vulnerabilities without delay and provide security updates.

ISO/IEC 27001

ISO/IEC 27001 is the internationally leading standard for an information security management system (ISMS). It describes a risk-based, process-oriented framework to systematically plan, implement, review and improve information security.

Read in glossary

Control A.8.8, management of technical vulnerabilities: assess relevance to your systems, plan remediation and keep evidence.

Description

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.

Source: BSI WID Portal, BSI CSAF, NVD (NIST), cvelistv5, suse_csaf

Vendors and products

• Legion Of The Bouncy Castle Inc. Bc-fja
• Legion Of The Bouncy Castle Inc. Bc-java
• Legion Of The Bouncy Castle Inc. Bc-lts-java
• Open Source Bouncy Castle Java
• Open Source Bouncy Castle Java Lts

Weakness classes (CWE)

• CWE-354Improper Validation of Integrity Check Value

  Base

  The product does not validate or incorrectly validates the integrity check values or "checksums" of a message. This may prevent it from detecting if the data has been modified or corrupted in transmission.

  Entry at MITRE CWE-354

• CWE-345Insufficient Verification of Data Authenticity

  Class

  The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.

  Entry at MITRE CWE-345

References & sources

• github.combcgit/bc-java/wiki/CVE‐2026‐85515Vendor advisory
• github.combcgit/bc-java/commit/ab7a235d1c20e3da28ce77167a96b5c14025efa7Patch

Changes to this CVE

Who changed this CVE and when: NVD (analysis, affected products, CVSS), the CVE publisher (CNA) and additional providers such as CISA (ADP).

1. 05.10.2026Record modifiedCISA ADP

   CISA assessment (SSVC): exploitation: none known, automatable: no

   Show the original change

   Individual changes of this event as published by NVD

   Type	Action	Before	After
   SSVC assessment	added	—	{"id":"CVE-2026-85515","role":"CISA Coordinator","options":[{"exploitation":"none"},{"automatable":"no"},{"technicalImpact":"partial"}],"version":"2.0.3","timestamp":"2026-10-05T18:03:26.858540Z"}

   Source identifier: 134c704f-9b21-4f2e-91b3-4a467353bcc0

2. 03.10.2026Receivedbcorg

   CVSS V4.0: AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/U:Amber

   Weakness type: CWE-345, CWE-354

   Description added or changed

   New references:

   • https://github.com/bcgit/bc-java/commit/ab7a235d1c20e3da28ce77167a96b5c14025efa7
   • https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%9085515
   Show 7 original changes

   Individual changes of this event as published by NVD

   Type	Action	Before	After
   Description	added	—	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.
   CVSS	added	—	AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Amber
   Weakness type (CWE)	added	—	CWE-345
   Weakness type (CWE)	added	—	CWE-354
   Affected versions (publisher)	added	—	New affected value received. <a href="https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/85xxx/CVE-2026-85515.json">CVE-2026-85515</a>
   Reference	added	—	https://github.com/bcgit/bc-java/commit/ab7a235d1c20e3da28ce77167a96b5c14025efa7
   Reference	added	—	https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%9085515

   Source identifier: 91579145-5d7b-4cc5-b925-a0262ff19630