CyberSecBulletin
CVE-2026-85515NVD status: Awaiting Analysis

BC-JAVA: Insufficient Verification of Data Authenticity

Published Updated By the CyberSecBulletin desk

CVE-2026-85515 is a high-severity insufficient verification of data authenticity vulnerability in BC-JAVA from Legion of the Bouncy Castle, with a CVSS 4.0 base score of 8.2 out of 10. It can be exploited remotely over the network by an unauthenticated attacker, without any action from a user. The record lists version 1.86 as the first without the flaw, so updating BC-JAVA to that release or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.16% chance of exploitation within 30 days, which is low compared with other CVEs.

Next patch cycle

High severity with no evidence of exploitation so far.

What to do

  1. Update BC-JAVA to 1.86 or a later version.
  2. Update BC-LTS-JAVA to 2.73.13 or a later version.
  3. Update BC-FJA to 1.0.14 or 2.0.14.1 or 2.1.14, whichever matches your release line, or a later version.
  4. Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.

Affected products and versions

VendorProductAffected versionsFixed in
Legion of the Bouncy CastleBC-JAVA1.74 up to, but not including, 1.861.86
Legion of the Bouncy CastleBC-LTS-JAVA2.73.0 up to, but not including, 2.73.132.73.13
Legion of the Bouncy CastleBC-FJA1.0.7 up to, but not including, 1.0.14; 2.0.7 up to, but not including, 2.0.14.1; 2.1.0 up to, but not including, 2.1.141.0.14, 2.0.14.1, 2.1.14

Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector
NetworkCan be exploited remotely over a network, including the internet.
Attack complexity
LowNo special conditions are needed; the attack works reliably.
Attack requirements
PresentThe target must be in a specific state or configuration for the attack to work.
Privileges required
NoneNo account or login is needed.
User interaction
NoneNo action by a victim is required.
Confidentiality (vulnerable system)
NoneNo loss of confidentiality on the vulnerable system.
Integrity (vulnerable system)
HighSerious loss of integrity on the vulnerable system.
Availability (vulnerable system)
NoneNo loss of availability on the vulnerable system.
Confidentiality (other systems)
NoneNo loss of confidentiality on systems beyond the vulnerable one.
Integrity (other systems)
NoneNo loss of integrity on systems beyond the vulnerable one.
Availability (other systems)
NoneNo loss of availability on systems beyond the vulnerable one.

Vector: CVSS:4.0/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. Scored by CNA.

Official 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: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Insufficient Verification of Data Authenticity

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

More Insufficient Verification of Data Authenticity vulnerabilities (CWE-345)

Timeline

  1. CVE record published.
  2. CISA published its SSVC assessment (exploitation: none, automatable: no, technical impact: partial).
  3. Record last changed materially (score, affected products, status or references).

References

Other vulnerabilities in BC-JAVA

All BC-JAVA vulnerabilities

Recent Insufficient Verification of Data Authenticity vulnerabilities

Spotted an error? Tell us.