Bouncy Castle Java CVE-2026-59642

Exploitation requires that the target application uses the Bouncy Castle CMS AuthenticatedData API and processes messages that contain authenticated attributes (authAttrs). The flaw is inert when authAttrs are absent - messages without authenticated attributes MAC the content directly and are explicitly stated as unaffected. The attacker must be able to deliver a crafted or modified AuthenticatedData blob to the vulnerable application, either by acting as the message originator, by intercepting messages in transit, or by substituting stored messages. No authentication to the target system is required (PR:N in the CVSS vector). The flaw affects both the in-memory CMSAuthenticatedData and the streaming CMSAuthenticatedDataParser processing paths. Applications that only use Bouncy Castle for other cryptographic operations (encryption, signing, key exchange) and do not process CMS AuthenticatedData are not affected.

The CVSS 4.0 score of 8.7 (AV:N/AC:L/AT:N/PR:N/UI:N/VI:H) reflects a high-severity integrity bypass exploitable without authentication or preconditions, which aligns with the nature of the flaw: any application that processes externally supplied CMS AuthenticatedData messages with authAttrs is vulnerable without special configuration. The VI:H rating is well-justified - the entire purpose of AuthenticatedData is content integrity assurance, and that assurance is silently absent. No EPSS data was provided, but given no KEV listing and no known POC, real-world exploitation likelihood is currently lower than the CVSS score implies. The attack requires an adversary capable of delivering a crafted CMS AuthenticatedData blob to the target application, which could be a MITM scenario, a malicious sender, or a stored-and-forwarded message. Notably, the CVSS S:U (scope unchanged) and VC:N/VA:N correctly reflect that confidentiality and availability are unaffected - AuthenticatedData does not encrypt content. The Information Disclosure tag in the source data appears to be a mis-categorization; the actual impact is integrity-only. The U:Amber urgency supplemental metric signals elevated but not critical response priority.

An attacker positioned to intercept or inject CMS AuthenticatedData messages - such as in a MITM scenario, a compromised message relay, or by acting as a malicious sender - replaces the eContent field with arbitrary bytes (e.g., a malicious payload or falsified business data) while leaving the authAttrs block and MAC value unchanged. When the recipient application calls recipient.getMac() and compares it to ad.getMac(), the comparison succeeds because the MAC over authAttrs is still valid; the application accepts the tampered content as cryptographically authenticated. No public exploit code is confirmed at time of analysis.