bc-check

Investigue offline quais dos CVEs do lote de 2026 do Bouncy Castle afetam sua aplicação Java. Zero dependências, um único jar, sem conexão à rede, sem upload de quaisquer dados.

java -jar bc-check.jar ./app.jar
java -jar bc-check.jar --gav bcprov-lts8on:2.73.5 --detail

Por que é necessária uma ferramenta (em vez de apenas olhar o número da versão)

Todas as descrições oficiais de CVE dizem uniformemente uma única frase:

Bouncy Castle for Java before 1.85

Mas, entre quem realmente usa, há duas linhas de produto cujos números de versão não seguem esse formato:

Linha de produto	artifact no formato	versão no formato	«before 1.85» é útil para ela?
BC (versão regular)	bcprov-jdk18on	1.81	✅ Útil
BC-LTS (versão de suporte de longo prazo)	bcprov-lts8on	2.73.5	❌ Impossível de julgar
BC-FJA (versão com certificação FIPS)	bc-fips / bctls-fips …	1.0.2.5 / 2.0.1 / 2.1.2	❌ Impossível de julgar

As versões corrigidas das três linhas são, respectivamente, 1.85, 2.73.12 e um conjunto próprio de números de versão para cada um dos 7 artifacts FIPS. Elas não estão no mesmo eixo numérico; compará-las entre si não faz sentido.

Quatro exemplos que mostram por que uma abordagem única dá conclusões erradas

1. CVE-2026-8149 não afeta de forma alguma a linha BC, afeta apenas BC-LTS 2.73.0–2.73.10. Quem fica olhando para o número de versão «1.85» nunca o descobrirá.
2. CVE-2026-59650 não afeta de forma alguma a versão FIPS. Reportá-lo com base em «before 1.85» é um falso alarme.
3. CVE-2026-59638 no lado FIPS exige verificar o artifact bctls-fips, não bc-fips —— passou do núcleo criptográfico para o módulo TLS. Quem olha apenas para bc-fips não o encontra.
4. CVE-2026-58062 e 58060 listam oficialmente apenas 2.0.2 e 2.1.3 de bc-fips, sem 1.0.x —— ou seja, a linha 1.0.x não é afetada. Já CVE-2026-8763 lista 1.0.2.7, então 1.0.x é afetado. Mesmo artifact, mesma versão, CVEs diferentes dão respostas diferentes.

Há ainda 10 CVEs com versão inicial afetada (from 1.61, from 1.66, from 1.73, todas diferentes), não é «todas as versões afetadas»; além disso, 4 CVEs antigos têm versões corrigidas que são versões de ramificação como 1.80.2 / 1.81.1 / 1.84, e o intervalo afetado é descontínuo (1.74–1.80.1, 1.81, 1.82–1.83).

Suponha que você já leu todos os avisos e conhece todas as respostas, ainda assim não consegue verificar —— porque a resposta não é um número de versão, é uma tabela tridimensional de «linha de produto × artifact × CVE».

Mais uma coisa: seu Dependabot provavelmente não vai alertar sobre este lote de CVEs

Correção (2026-10-12): esta seção dizia originalmente «os 4 CVEs com CVSS critical estão todos unreviewed, o Dependabot não os vê». Entre eles, CVE-2026-8763 foi revisado e incluído pelo GitHub em 2026-09-18, com informações de pacote adicionadas, e agora o Dependabot e o OSV conseguem vê-lo. Os que continuam invisíveis são os outros 3. Abaixo está a versão corrigida conforme medição real de 2026-10-12.

Dos 4 CVEs com CVSS critical, 3 ainda têm status unreviewed no GitHub Advisory, com a lista de pacotes afetados vazia (0 pacotes). Sem nome de pacote, não há como casar com a árvore de dependências —— eles não entram no OSV, o Dependabot não alerta, e o SCA também não os encontra ao escanear a lista de dependências.

Consultando o OSV com org.bouncycastle:bcprov-jdk18on:1.81 (2026-10-12), há 4 correspondências: CVE-2025-14813, CVE-2026-0636, CVE-2026-13506, CVE-2026-8763 —— nenhum dos outros 3 critical está presente.

⚠️ Deixando claro o limite: não é «o Dependabot não vê nenhuma vulnerabilidade do BC» —— CVE-2026-0636, do mesmo lote, é reviewed, tem informações de pacote e alerta normalmente. O que não é visível são os 3 critical marcados como unreviewed na tabela abaixo.

CVE	GHSA	Status (2026-10-12)	Nº de pacotes
CVE-2026-58062	GHSA-j295-77c3-9frf	unreviewed	0
CVE-2026-8763	GHSA-9pwp-9qqc-pr26	reviewed (desde 2026-09-18)	6
CVE-2026-59650	GHSA-ghgq-7g74-28wp	unreviewed	0
CVE-2026-59638	GHSA-8rxj-3p7p-rq39	unreviewed	0

A base de dados global registra para CVE-2026-8763 as versões corrigidas bcprov-jdk18on / bcprov-jdk15to18 1.85, bcprov-lts8on 2.73.12, bc-fips 1.0.2.7 / 2.0.2 / 2.1.3, consistente com a tabela de determinação desta ferramenta.

Uso

java -jar bc-check.jar <路径> [更多路径...] [选项]
java -jar bc-check.jar --gav <坐标>

O caminho pode ser um arquivo jar / war (incluindo Spring Boot fat-JAR, expandido automaticamente camada por camada), ou um diretório (recursivo).

Opção	Descrição
--gav <coordenada>	Não escaneia arquivos, avalia diretamente uma coordenada, como bcprov-lts8on:2.73.5
-d, --detail	Lista item a item os CVEs encontrados e o texto oficial original
--json	Emite JSON, facilitando a integração em pipelines (sempre UTF-8)
--utf8 / --gbk	Força a codificação especificada quando o console exibir caracteres chineses corrompidos
--no-color	Desativa a saída colorida

Códigos de saída: 0 = sem correspondência; 1 = CVE encontrado; 2 = erro de uso. Pode ser usado diretamente como gate de CI.

A saída é assim

[CRITICAL] bcprov-lts8on 2.73.5　BC-LTS 线
  位置　　：app.jar!/BOOT-INF/lib/bcprov-lts8on-2.73.5.jar
  来源　　：jar 内 MANIFEST
  结论　　：命中 29 条 CVE，其中 CVSS critical 4 条
  降噪　　：其中 13 条按官方 FIPS 侧点名的 artifact 反推，大概率出在 bcpkix / bcpg / bctls 模块。
            ⚠️ 这是推断不是官方结论，仅供排优先级。
  处置　　：升级到 2.73.12（BC-LTS 线）

Como ele encontra o Bouncy Castle

Na grande maioria dos casos, o BC não é uma dependência que você mesmo declarou — ele é arrastado por dependências transitivas — TLS, validação de certificados, JWT, assinatura de PDF e PGP todos o trazem. Por isso esta ferramenta não olha o pom, apenas os artefatos reais:

1. Bundle-SymbolicName + Bundle-Version do META-INF/MANIFEST.MF (caminho principal)
2. Nome do arquivo jar
3. META-INF/maven/org.bouncycastle/*/pom.properties (não existe nos jars oficiais, apenas nos reempacotados)
4. Se encontrar apenas classes em org/bouncycastle/ mas não conseguir identificar as coordenadas → reporta UNKNOWN e sugere confirmação manual

O quarto caso é quando o BC foi embutido (shade) no jar hospedeiro; mvn dependency:tree e SCA não o enxergam, esta ferramenta ao menos informa "há BC aqui, mas não consigo identificar a versão", em vez de omiti-lo silenciosamente.

Quando o jar é renomeado (muito comum em republicações de repositórios internos), o nome do arquivo não é reconhecido, mas o MANIFEST continua sendo.

De onde vêm os critérios de julgamento

Tudo vem das subpáginas individuais das 37 CVEs de 2026 na wiki oficial do github.com/bcgit/bc-java (texto original de Issue affecting / Fixed versions), não de relatos de segunda mão nem de artigos agregadores.

• Dados primários: tools/data/bc_cves.json
• A tabela de julgamento é gerada automaticamente em CveTable.java pelo tools/gen_rules.py, sem transcrição manual
• O relatório inclui o texto oficial original de cada item, para que você mesmo possa verificar

Regenerar: python tools/gen_rules.py

🔴 Escopo de julgamento (leia isto antes de ver OK)

Esta ferramenta cobre apenas as 37 CVEs de 2026 da wiki oficial. Vulnerabilidades do Bouncy Castle anteriores a 2026 não estão no escopo — a maioria delas já está no OSV, podendo ser consultada pelo Dependabot / SCA; esta ferramenta não reinventa a roda.