CVE-2026-71888 in BC-JAVA
요약
\~에 의해 VulDB • 2026. 10. 03.
Java용 Bouncy Castle 버전 1.86 미만에서 스트리밍 CMS AuthenticatedData 파서가 digestAlgorithm과 authAttrs 필스가 인증된 속성(authenticated attributes)의 존재 여부에 대해 서로 다른 값을 가진 메시지를 허용했습니다. RFC 5652 섹션 9.1은 이 두 필스를 쌍으로 묶어, digestAlgorithm이 있을 경우 authAttrs도 반드시 포함되어야 한다고 요구하며, 섹션 9.2는 authAttrs가 있는 경우 MAC(메시지 인증 코드)이 authAttrs의 DER 인코딩을 커버하고, 없는 경우에는 eContent OCTET STRING을 직접 커버하도록 규정합니다. CMSAuthenticatedDataParser는 SEQUENCE 내에서 나중에 나타나는 authAttrs에 도달하기 전인 생성자 단계에서 이 두 가지 방식 중 하나를 선택해야 하는데, digestAlgorithm만을 기준으로 결정했습니다: digestAlgorithm은 없으나 authAttrs가 있는 메시지의 경우, MAC이 해당 속성들을 커버하지 않았음에도 불구하고 콘텐츠 MAC을 검증한 후 getAuthAttrs()를 통해 인증된 것처럼 속성을 반환했습니다. 전송 중인 메시지를 수정할 수 있는 공격자는 키-암호화 키나 콘텐츠-MAC 키를 보유하지 않은 상태에서도 유효한 메시지에 RFC 2634 ESSSecurityLabel과 같은 인증된 속성을 삽입할 수 있으며, 이러한 속성으로부터 권한 부여, 라우팅 또는 레이블링 결정을 내리는 애플리케이션은 공격자가 선택한 값을 기반으로 동작하게 됩니다. 콘텐츠 자체는 여전히 MAC에 의해 보호됩니다(asn1.cms.AuthenticatedData). 이제 asn1.cms.AuthenticatedData는 파싱 시 불일치하는 페어링을 거부하며, CMSAuthenticatedDataParser는 authAttrs를 읽은 후 두 필스를 교차 검증합니다. 이는 CVE-2659642의 변형으로, 해당 CVE는 legitimately(authAttrs가 포함된 정당한) 메시지에 대해 콘텐츠를 MAC에 바인딩하지만 본 사례는 다루지 않습니다. 이 문제는 Java용 Bouncy Castle LTS 버전 2.73.13 미만과, Java용 Bouncy Castle FIPS(BC-FJA)의 bcpkix-fips 1.0.13 미만(1.0.X 시리즈), 2.0.13 미만(2.0.X 시리즈), 2.1.13 미만(2.1.X 시리즈), 그리고 bcutil-fips 2.0.8 미만(2.0.X 시리즈) 및 2.1.8 미만(2.1.X 시리즈)에서도 영향을 받습니다.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.