CVE-2026-71888

None

CVSS

—

EPSS

0.1%

Published

Oct 3, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A library used to securely handle encrypted or signed messages could let attackers add fake labels or instructions that some programs would trust, even though the real message content stayed protected.

Exploitation: Remote Unauthenticated
Attacker needs: None
Complexity: Low
Impact: Data Tampering
Component: Library
Class: Cryptographic Weakness
Remediation: Upgrade
Effort: Medium
Patch risk: Low

What it actually does

The streaming CMS AuthenticatedData parser in Bouncy Castle accepts messages where digestAlgorithm indicates absence of authAttrs but authAttrs are present, causing it to return attacker-controlled attributes via getAuthAttrs() without MAC verification coverage as required by RFC 5652.

Why it matters to the business

Applications relying on Bouncy Castle for CMS authenticated messages may make authorization, routing, or labeling decisions based on attacker-supplied values without the attacker needing any keys, while the actual content remains protected.

How an attack unfolds

An attacker intercepts a valid CMS AuthenticatedData message in transit, inserts an attribute such as RFC 2634 ESSSecurityLabel into the authAttrs without the digestAlgorithm reflecting their presence, forwards the message, and the receiving application processes the inserted attribute as authenticated when making security decisions.

How to fix it

Upgrade Bouncy Castle for Java to 1.86 or later, Bouncy Castle for Java LTS to 2.73.13 or later, and BC-FIPS packages to bcpkix-fips 1.0.13/2.0.13/2.1.13 or later and bcutil-fips 2.0.8/2.1.8 or later. For affected Red Hat ocp-tools, apply the fix in 4/jenkins-rhel9:1792041514 (RHSA-2026:88156).

How to confirm the fix worked

Confirm upgraded library versions are deployed, then test parsing of CMS messages with mismatched digestAlgorithm and authAttrs to ensure rejection occurs before attribute access.

Typical attack path

Identify a target application processing streaming CMS AuthenticatedData messages using vulnerable Bouncy Castle
Intercept a legitimate message in transit
Modify the message to add attacker-chosen authenticated attributes while leaving digestAlgorithm unchanged
Forward the altered message to the target
Trigger the target to read attributes and base decisions on the injected values

How to detect it

Search application and library logs for CMS AuthenticatedData parsing events around the time of attribute consumption; look for unexpected attribute values or decisions based on labels/routing data that do not match message origin.

What your security team should do

Immediately upgrade all Bouncy Castle usages to the fixed versions listed, prioritizing internet-facing or high-value services
Review applications that consume CMS AuthenticatedData attributes for authorization or routing decisions and add secondary validation
Monitor vendor advisories for any additional downstream dependents of the affected Red Hat ocp-tools package

The record

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).

Affected packages

Ecosystem	Package	Introduced	Fixed