Legion of the Bouncy Castle BC-JAVA/BC-LTS-JAVA/BC-FJA up to 2.73.12 Streaming CMS AuthenticatedData Parser AuthenticatedData.java CMSAuthenticatedDataParser digestAlgorithm/authAttrs improper authorization

Summaryinfo

A vulnerability has been found in Legion of the Bouncy Castle BC-JAVA, BC-LTS-JAVA and BC-FJA up to 2.73.12 and classified as critical. This vulnerability affects the function CMSAuthenticatedDataParser of the file asn1/cms/AuthenticatedData.java of the component Streaming CMS AuthenticatedData Parser. The manipulation of the argument digestAlgorithm/authAttrs leads to improper authorization. This vulnerability is traded as CVE-2026-71888. It is possible to initiate the attack remotely. There is no exploit available. The affected component should be upgraded.

Detailsinfo

A vulnerability was found in Legion of the Bouncy Castle BC-JAVA, BC-LTS-JAVA and BC-FJA up to 2.73.12 and classified as critical. This issue affects the function CMSAuthenticatedDataParser of the file asn1/cms/AuthenticatedData.java of the component Streaming CMS AuthenticatedData Parser. The manipulation of the argument digestAlgorithm/authAttrs with an unknown input leads to a improper authorization vulnerability. Using CWE to declare the problem leads to CWE-285. The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action. Impacted is confidentiality, integrity, and availability. The summary by CVE is:

In Bouncy Castle for Java before 1.86, the streaming CMS AuthenticatedData parser accepted a message whose digestAlgorithm and authAttrs fields disagreed about whether authenticated attributes were present. RFC 5652 sec. 9.1 pairs the two, requiring that authAttrs be present whenever digestAlgorithm is, and sec. 9.2 makes the MAC cover the DER encoding of authAttrs when they are present and the eContent OCTET STRING directly when they are not. CMSAuthenticatedDataParser has to choose between those two in its constructor, before it can reach authAttrs, which comes later in the SEQUENCE, so it chose on digestAlgorithm alone: for a message with digestAlgorithm absent but authAttrs present it verified the content MAC and then returned the attributes through getAuthAttrs() as though they had been authenticated, when the MAC had never covered them. An attacker able to modify a message in transit could insert an authenticated attribute, such as an RFC 2634 ESSSecurityLabel, into an otherwise valid message while holding neither the key-encryption key nor the content-MAC key, and an application taking an authorization, routing or labelling decision from those attributes would act on attacker-chosen values. The content itself remained MAC-bound. asn1.cms.AuthenticatedData now rejects the mismatched pairing when parsing and CMSAuthenticatedDataParser cross-checks the two fields once authAttrs is read. This is a variant of CVE-2026-59642, which bound the content to the MAC for messages that legitimately carry authAttrs, and which does not address this case. 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), and bcutil-fips 2.0.8 (2.0.X series) and 2.1.8 (2.1.X series).

It is possible to read the advisory at github.com. The identification of this vulnerability is CVE-2026-71888 since 08/08/2026. The exploitation is known to be easy. The attack may be initiated remotely. No form of authentication is needed for a successful exploitation. Technical details of the vulnerability are known, but there is no available exploit. The attack technique deployed by this issue is T1548.002 according to MITRE ATT&CK.

Upgrading to version 1.86, 2.73.13, 1.0.13, 2.0.13, 2.1.13, 2.0.8 or 2.1.8 eliminates this vulnerability.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Productinfo

Type

• Programming Language Software

Vendor

• Legion of the Bouncy Castle

Name

• BC-FJA
• BC-JAVA
• BC-LTS-JAVA

Version

• 1.0
• 1.0.0
• 1.0.1
• 1.0.2
• 1.0.3
• 1.0.4
• 1.0.5
• 1.0.6
• 1.0.7
• 1.0.8
• 1.0.9
• 1.0.10
• 1.0.11
• 1.0.12
• 1.1
• 1.2
• 1.3
• 1.4
• 1.5
• 1.6
• 1.7
• 1.8
• 1.9
• 1.10
• 1.11
• 1.12
• 1.13
• 1.14
• 1.15
• 1.16
• 1.17
• 1.18
• 1.19
• 1.20
• 1.21
• 1.22
• 1.23
• 1.24
• 1.25
• 1.26
• 1.27
• 1.28
• 1.29
• 1.30
• 1.31
• 1.32
• 1.33
• 1.34
• 1.35
• 1.36
• 1.37
• 1.38
• 1.39
• 1.40
• 1.41
• 1.42
• 1.43
• 1.44
• 1.45
• 1.46
• 1.47
• 1.48
• 1.49
• 1.50
• 1.51
• 1.52
• 1.53
• 1.54
• 1.55
• 1.56
• 1.57
• 1.58
• 1.59
• 1.60
• 1.61
• 1.62
• 1.63
• 1.64
• 1.65
• 1.66
• 1.67
• 1.68
• 1.69
• 1.70
• 1.71
• 1.72
• 1.73
• 1.74
• 1.75
• 1.76
• 1.77
• 1.78
• 1.79
• 1.80
• 1.81
• 1.82
• 1.83
• 1.84
• 1.85
• 2.0.0
• 2.0.1
• 2.0.2
• 2.0.3
• 2.0.4
• 2.0.5
• 2.0.6
• 2.0.7
• 2.0.8
• 2.0.9
• 2.0.10
• 2.0.11
• 2.0.12
• 2.1.0
• 2.1.1
• 2.1.2
• 2.1.3
• 2.1.4
• 2.1.5
• 2.1.6
• 2.1.7
• 2.1.8
• 2.1.9
• 2.1.10
• 2.1.11
• 2.1.12
• 2.73.0
• 2.73.1
• 2.73.2
• 2.73.3
• 2.73.4
• 2.73.5
• 2.73.6
• 2.73.7
• 2.73.8
• 2.73.9
• 2.73.10
• 2.73.11
• 2.73.12

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discussion