CVE-2026-71888 in BC-JAVA
Summary
by MITRE • 10/03/2026
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).
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/03/2026
The vulnerability identified in Bouncy Castle for Java prior to version 1.86 represents a critical logic flaw within the streaming CMS AuthenticatedData parser, specifically concerning the handling of authenticated attributes versus content authentication mechanisms. The core technical failure stems from an incorrect parsing sequence where the decision on how to verify message integrity is made prematurely based solely on the presence or absence of the digestAlgorithm field, rather than cross-referencing it with the authAttrs field as mandated by RFC 5652. According to section 9.1 of RFC 5652, authenticated attributes must be present whenever a digest algorithm is specified, and section 9.2 dictates that when these attributes are present, the Message Authentication Code (MAC) must cover their DER encoding. Conversely, if no authenticated attributes exist, the MAC covers only the eContent OCTET STRING directly. The flawed implementation in CMSAuthenticatedDataParser chooses its verification strategy during construction based exclusively on digestAlgorithm availability. This creates a dangerous edge case where a message contains authAttrs but lacks digestAlgorithm. In this scenario, the parser incorrectly assumes that because no digest algorithm is present, there are no authenticated attributes to protect via MAC over their encoding. Consequently, it proceeds to verify only the content MAC against the eContent, ignoring the fact that authAttrs were actually included in the structure.
This architectural oversight leads to a severe integrity bypass where an attacker can manipulate the message metadata without possessing either the key-encryption key or the content-MAC key. By inserting authenticated attributes, such as an RFC 2634 ESSSecurityLabel, into a validly signed and MACed message that originally lacked them, an adversary can inject arbitrary authorization data. Since the parser does not verify the integrity of these injected authAttrs against the MAC, it accepts them as legitimate. Applications relying on this library for security-critical decisions will then process these attacker-controlled attributes as if they were authentically bound to the content. For instance, a routing engine might direct traffic based on forged labels, or an authorization service might grant permissions derived from manipulated ESSSecurityLabel values. While the actual payload data remains protected by the MAC and cannot be altered without detection, the metadata governing how that data is treated can be completely subverted, leading to potential unauthorized access, misrouting of sensitive information, or incorrect security labeling in downstream systems.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the parser fails to correctly validate the structural consistency between related fields within an ASN.1 structure. It also relates to CWE-345 Insufficient Verification of Data Authenticity because the system accepts data that has not been properly authenticated relative to its context. In terms of offensive security frameworks, this flaw facilitates attacks categorized under MITRE ATT&CK T1078 Valid Accounts or T1190 Exploit Public-Facing Application if leveraged in conjunction with other vulnerabilities, specifically enabling privilege escalation through forged attributes rather than direct code execution. The issue is distinct from CVE-2026-59642, which addressed a different variant where content binding was insufficient for messages that legitimately carried authAttrs; this current flaw addresses the opposite edge case of mismatched presence flags and remains unmitigated in previous patches targeting the other scenario.
The impact extends across multiple versions of Bouncy Castle due to shared codebases between standard and FIPS-compliant distributions. The vulnerability affects Bouncy Castle for Java before version 1.86, as well as the Long Term Support branch prior to 2.73.13. Furthermore, it impacts the FIPS-validated modules, including bcpkix-fips versions below 1.0.13 in the 1.0.X series, 2.0.13 in the 2.0.X series, and 2.1.13 in the 2.1.X series. Similarly, bcutil-fips is vulnerable in versions prior to 2.0.8 for the 2.0.X series and 2.1.8 for the 2.1.X series. Organizations utilizing these libraries must upgrade immediately to ensure that the parser correctly cross-checks digestAlgorithm and authAttrs fields before finalizing integrity verification strategies. Mitigation requires patching to versions where ASN1.cms.AuthenticatedData rejects mismatched pairings during parsing and CMSAuthenticatedDataParser performs rigorous validation of both fields once they are read, thereby ensuring that any authenticated attributes are properly covered by the MAC or correctly excluded from it based on consistent structural presence.