In Bouncy Castle for Java versions prior to 1.86, the streaming CMS AuthenticatedData parser incorrectly accepted messages where the digestAlgorithm and authAttrs fields were inconsistent regarding the presence of authenticated attributes. According to RFC 5652, authAttrs must be present if digestAlgorithm is present, and the MAC covers the DER encoding of authAttrs when present, or the eContent OCTET STRING directly when not. The parser chose verification based on digestAlgorithm alone, allowing messages with absent digestAlgorithm but present authAttrs to pass verification without the MAC covering the inserted authAttrs. This enables an attacker who can modify messages in transit to insert authenticated attributes such as ESSSecurityLabel without possessing the encryption or MAC keys. The vulnerability affects Bouncy Castle for Java before 1.86, including LTS versions before 2.73.13, and various FIPS series before specified patch versions. The issue is a variant of CVE-2026-59642 but affects a different case. The fix involves rejecting mismatched pairings during parsing and cross-checking fields after reading authAttrs.

An attacker capable of modifying messages in transit can insert attacker-controlled authenticated attributes into CMS AuthenticatedData messages without those attributes being covered by the MAC. This can lead to applications making incorrect authorization, routing, or labeling decisions based on these unauthenticated attributes. The actual content remains protected by the MAC, so content integrity is not compromised. There is no indication of known exploits in the wild.

A fix is available in Bouncy Castle for Java version 1.86 and later, as well as in LTS and FIPS versions starting from 2.73.13, 1.0.13, 2.0.13, 2.1.13, 2.0.8, and 2.1.8 respectively. Users should upgrade to these fixed versions to prevent exploitation. No additional mitigation steps are indicated by the vendor advisory.