Bouncy Castle CVE-2026-71888

Exploitation requires that the target application parse CMS AuthenticatedData via the streaming CMSAuthenticatedDataParser (or the in-memory CMSAuthenticatedData path) AND make an authorization, routing, or labelling decision from the attributes returned by getAuthAttrs(); without that consumption pattern the forged attributes have no effect. The attacker must occupy an active in-transit (man-in-the-middle) position to modify a message, and crafts a message where digestAlgorithm is absent but authAttrs is present. Limiting factors: the attacker needs NO keys (neither key-encryption nor content-MAC key), but does need message-tampering capability and a victim app that trusts authAttrs; the content/eContent itself remains MAC-protected so only the authenticated attributes can be forged, not the payload. Only affects versions before the fixes (BC-Java <1.86, BC-LTS <2.73.13, BC-FJA bcpkix-fips <1.0.13/2.0.13/2.1.13, bcutil-fips <2.0.8/2.1.8).

Signals conflict on whether this merits urgent prioritization. The vendor CVSS 4.0 score of 8.7 (High) reflects AV:N/PR:N/VI:H - a network-reachable, unauthenticated integrity compromise - but the base vector rates AC:L even though the description explicitly requires an attacker 'able to modify a message in transit,' i.e. an active man-in-the-middle position; under CVSS 3.1 that precondition is more honestly AC:H, materially lowering real-world exploitability. No EPSS score was supplied, there is no CISA KEV listing, and no POC was provided, so the exploitation status is 'no public exploit identified at time of analysis' - nothing suggests active or widespread exploitation. Impact is narrow and integrity-only: VC:N/VA:N confirm no confidentiality or availability loss, the content itself stays MAC-bound, and only the authenticated attributes (e.g. an RFC 2634 ESSSecurityLabel) can be forged. Crucially, exploitation only matters if an application both uses the streaming CMSAuthenticatedDataParser AND makes authorization/routing/labelling decisions from getAuthAttrs() - a specific, uncommon usage pattern. Net: a legitimately serious cryptographic authentication-bypass flaw in a very widely used library, but one whose practical risk is gated by an MITM prerequisite and an app-specific consumption pattern, so for most deployments it is lower-urgency than the 8.7 alone implies. Patch available; prioritize for applications that act on CMS authenticated attributes.

An attacker positioned to tamper with traffic intercepts a valid CMS AuthenticatedData message, crafts a variant where digestAlgorithm is absent but authAttrs is present, and inserts a forged authenticated attribute such as an ESSSecurityLabel without possessing the key-encryption or content-MAC key. The streaming parser verifies the genuine content MAC and returns the injected attributes via getAuthAttrs() as if authenticated, so a downstream application makes an authorization, routing, or labelling decision based on attacker-chosen values. No public exploit code is known; the attack requires an active in-transit (MITM) position consistent with the network attack vector.