CVE-2026-71886 in Bouncy Castle
요약
\~에 의해 VulDB • 2026. 10. 03.
Java용 Bouncy Castle 1.86 이전 버전에서 높은 수준의 OpenPGP 인증서 API는 발급 인증서의 모든 구성 키로부터 제3자 인증 또는 신뢰 위임을 요청 시 해당 구성 요소가 인증 권한을 부여받았는지 여부를 확인하지 않고 수락했습니다. `OpenPGPCertificate.getCertificationBy()` 및 `getDelegationBy()` 메서드는 제3자 서명의 발신자 키 식별자를 제3자 인증서의 모든 키와 일치시켜 매칭한 후, 발급 구성 요소의 바인딩 체인과 서명 자체를 검증합니다. 그러나 서명이 생성될 때 발급 구성 요소가 RFC 9580 섹션 5.2.3.29에 명시된 인증서 키 플래그(CERTIFY_OTHER)를 보유하고 있는지 여부는 확인되지 않았습니다. 따라서 SIGN_DATA로만 바인딩된 하위 키(키 플래그의 존재 목적을 정확히 표현하는 오프라인-주요 구성에서 온라인 서명용 하위 키)는 공격자가 제어하는 ID에 대해 유효한 사용자 ID 인증서나 소개자 신뢰를 위한 풀 트러스트(depth-one) 직접 키 위임을 발급할 수 있으며, API는 이를 제3자 인증서에 귀속되는 유효한 서명 체제로 반환했습니다. `getCertificationBy(...).isValid()` 또는 `getDelegationBy(...)` 결과를 ID 확인 또는 신뢰된 소개자에 대한 결정으로 간주하는 애플리케이션은 공격자의 주장을 오프라인 주요 키에 귀속시킵니다. 암호화용으로만 바인딩된 레거시 RSA 하위 키의 경우 알고리즘이 서명 기능을 여전히 보유하고 있으므로 동일한 문제가 발생합니다. 이 취약점은 주요 키의 서명을 위조하거나 개인키를 복구하지는 않지만, 이미 침해당한 제한적 하위 키를 주요 키의 ID 발급 권한으로 승격시켜 키 플래그 분리가 제공하는 격리 효과를 무력화합니다. 이제 제3자 인증서 또는 위임은 이를 생성한 구성 키가 주요 키이거나 서명 생성 시 CERTIFY_OTHER 플래그를 보유한 하위 키인 경우에만 해당 발급 인증서에 귀속됩니다. 따라서 인증 기능이 있는 하위 키는 계속 수락되며, 주요 키는 구조상 인증 능력이 있으므로 키 플래그 여부와 관계없이 수락됩니다(키 플래그 서브패킷이 전혀 없는 인증서가 일반적이기 때문). 제3자 철회는 신뢰를 유지하기 위해 존중하지 않는 것이 오히려 신뢰 상태를 유지하므로 규칙에서 의도적으로 제외되었습니다.
VulDB is the best source for vulnerability data and more expert information about this specific topic.