CVE‐2026‐71888

Title: CMS AuthenticatedData exposes attacker-inserted authAttrs when digestAlgorithm is absent.

Issue affecting: BC before 1.86, BC-LTS before 2.73.13, BC-FJA before bcpkix-fips 1.0.13, 2.0.13 and 2.1.13 and bcutil-fips 2.0.8 and 2.1.8.

Fixed versions: BC 1.86, BC-LTS 2.73.13, BC-FJA bcpkix-fips 1.0.13, 2.0.13 and 2.1.13 and bcutil-fips 2.0.8 and 2.1.8.

Platform affected: Java 8 and later.

RFC 5652 sec. 9.1 pairs digestAlgorithm and authAttrs: "If the digestAlgorithm field is present, then the authAttrs field MUST also be present." Sec. 9.2 then makes the pairing load-bearing — with authAttrs the MAC is computed over their DER encoding, and without them it covers the eContent OCTET STRING directly.

CMSAuthenticatedDataParser must pick between those two strategies in its constructor, since it selects the CMSSecureReadable before any content is streamed. authAttrs sits later in the SEQUENCE than that decision point, so the parser chose on digestAlgorithm alone and never revisited it. Given a message with digestAlgorithm absent but authAttrs present, it verified the content MAC — genuinely, the content was untouched — and then handed the attributes back through getAuthAttrs() as if they had been authenticated. Nothing had covered them.

An attacker who can modify a message in transit needs neither the key-encryption key nor the content-MAC key to exploit this: take a valid message that carries no attributes, splice in an authAttrs set, leave the content and the MAC alone. An application that reads those attributes for an authorization, routing or security-labelling decision — an RFC 2634 ESSSecurityLabel, for instance — then acts on attacker-chosen values from a message that looks fully verified. The content itself stays MAC-bound throughout; this is not a content-forgery.

asn1.cms.AuthenticatedData now rejects the mismatched pairing at parse, so the in-memory CMSAuthenticatedData path reports it as CMSException("Malformed content."), and CMSAuthenticatedDataParser cross-checks the two fields once authAttrs is actually read, failing both getAuthAttrs() and getMac().

This is a variant of CVE-2026-59642, which bound the content to the MAC for messages that legitimately carry authAttrs. That fix starts from a message where both fields are present; this one starts from a message where both are absent and inserts authAttrs alone, and remained reproducible after it.

The fix was introduced in commit dcb683b32b44.

Credit: Bhargava Shastry.