CVE-2026-71887 in BC-JAVA
Sumário
de VulDB • 03/10/2026
No Bouncy Castle para Java anterior à versão 1.86, a API de alto nível do OpenPGP aceitava uma assinatura de dados feita por uma subchave de assinatura cuja Assinatura de Vinculação da Subchave não continha nenhuma Assinatura de Vinculação da Chave Primária (cross-certification) embutida, no caso em que essa vinculação omite um subpacote Key Flags. O RFC 9580, seções 5.2.1.8 e 10.1.3, exige a Assinatura de Vinculação da Chave Primária embutida em qualquer subchave capaz de emitir assinaturas; é o próprio enunciado da subchave que atesta sua pertença à chave primária sob a qual está vinculada. A classe OpenPGPCertificate resolvia as flags (Key Flags) da subchave de duas maneiras diferentes. O método isSigningKey() percorre getKeyFlags() e getApplyingSubpacket(), fazendo fallback para a autoassinatura direta-chave ou User ID da chave primária quando a assinatura de vinculação omite o subpacote, portanto, a subchave herdava as flags SIGN_DATA da chave primária e era considerada capaz de assinar; verifyEmbeddedPrimaryKeyBinding(), que aplica o requisito, lê os subpacotes hashados próprios da assinatura de vinculação, não encontrava SIGN_DATA ali e retornava antecipadamente como uma chave sem capacidade de assinatura, sem jamais exigir a assinatura de retrovinculação (back signature). A mesma subchave era portanto capaz de assinar – logo, suas assinaturas eram atribuídas ao certificado e OpenPGPSignature.OpenPGPDocumentSignature.isValid() retornava true – enquanto estava isenta da cross-certification, onde o GnuPG recusa o mesmo certificado e mensagem. Um atacante precisa apenas da chave pública de assinatura do subchave da vítima, que é material público: ele a vincula à sua própria chave primária com uma Assinatura de Vinculação da Subchave que consegue criar, sem Key Flags nem Assinatura de Vinculação da Chave Primária embutida (que não poderia criar sem a chave privada da subchave), e um partido confiável verificando uma mensagem genuinamente assinada pela vítima contra esse certificado é informado de que a assinatura é válida e recebe o certificado do atacante como seu emissor. Como os User IDs de um certificado são autoafirmados, um verificador que faz pinning no fingerprint ou key ID da subchave enquanto obtém a identidade do certificado envolvente relata uma assinatura real sob uma identidade escolhida pelo atacante. Isso constitui uma má atribuição (misattribution) de uma assinatura genuína e não uma falsificação de uma nova; nenhuma chave privada é recuperada, e a assinatura deve ser necessariamente aquela que a subchave enxertada realmente criou. A API de baixo nível PGPSignature / PGPPublicKeyRing não realiza verificações de vinculação por design e não é afetada. Key Flags são um enunciado sobre a chave à qual a assinatura portadora se refere (RFC 9580, secção 5.2.3.29), portanto uma subchave já não herda essas flags das assinaturas globais do certificado da chave primária: uma Assinatura de Vinculação da Subchave que omite o subpacote agora deixa a subchave sem capacidades em vez de herdá-las da chave primária, o que faz com que as flags consultadas pela verificação de cross-certification sejam as mesmas flags consultadas por todas as outras decisões. Preferências e os outros subpacotes carregados por uma assinatura direta-chave são herdados como antes, e a própria chave primária, cujas flags derivam legitimamente de sua autoassinatura direta-chave ou User ID, não é afetada.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.