bc-check

Investiga sin conexión cuáles de los CVE de Bouncy Castle de 2026 afectan a tu aplicación Java. Sin dependencias, un único jar, sin conexión a la red, sin subir ningún dato.

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

Por qué se necesita una herramienta (y no basta con mirar el número de versión)

Todas las descripciones oficiales de los CVE dicen uniformemente una sola frase:

Bouncy Castle for Java before 1.85

Pero entre quienes realmente lo usan, hay dos líneas de producto cuyos números de versión no se parecen en nada a eso:

Línea de producto	artifact con forma	versión con forma	¿Le sirve «before 1.85»?
BC (versión normal)	bcprov-jdk18on	1.81	✅ Sirve
BC-LTS (versión de soporte a largo plazo)	bcprov-lts8on	2.73.5	❌ Imposible de determinar
BC-FJA (versión con certificación FIPS)	bc-fips / bctls-fips …	1.0.2.5 / 2.0.1 / 2.1.2	❌ Imposible de determinar

Las versiones corregidas de las tres líneas son 1.85, 2.73.12 y un conjunto de números de versión propio para cada uno de los 7 artifacts FIPS, respectivamente. No están en el mismo eje numérico; compararlas entre sí no tiene sentido.

Cuatro ejemplos que muestran por qué aplicar una regla única da conclusiones erróneas

1. CVE-2026-8149 no afecta en absoluto a la línea BC, solo afecta a BC-LTS 2.73.0–2.73.10. Quien se fija en el número de versión «1.85» nunca lo descubrirá.
2. CVE-2026-59650 no afecta en absoluto a la versión FIPS. Reportarlo según «before 1.85» es una falsa alarma.
3. CVE-2026-59638 en el lado FIPS el artifact que hay que consultar es bctls-fips, no bc-fips —— se pasa del núcleo criptográfico al módulo TLS. Quien solo mira bc-fips no lo encontrará.
4. CVE-2026-58062 y 58060 oficialmente solo listan 2.0.2 y 2.1.3 de bc-fips, no 1.0.x —— es decir, la línea 1.0.x no está afectada. En cambio, CVE-2026-8763 lista 1.0.2.7, así que 1.0.x sí está afectada. El mismo artifact, la misma versión, distintos CVE dan respuestas distintas.

Además, 10 CVE tienen versión inicial afectada (from 1.61, from 1.66, from 1.73, todas distintas), no es «todas las versiones afectadas»; otros 4 CVE antiguos tienen como versión corregida versiones de rama como 1.80.2 / 1.81.1 / 1.84, y los intervalos afectados están discontinuos (1.74–1.80.1, 1.81, 1.82–1.83).

Supón que ya has leído todos los avisos y conoces todas las respuestas, y aun así no puedes consultarlo —— porque la respuesta no es un número de versión, sino una tabla tridimensional de «línea de producto × artifact × CVE».

Una cosa más: es muy probable que Dependabot no te alerte de este lote de CVE

Corrección (2026-10-12): esta sección decía originalmente «los 4 CVE de CVSS critical están todos unreviewed, Dependabot no los ve». De ellos, CVE-2026-8763 fue revisado e incorporado por GitHub el 2026-09-18 y se le añadió la información de paquetes, así que ahora Dependabot y OSV sí lo ven. Los que siguen sin verse son los otros 3. Abajo está la versión corregida según la comprobación real del 2026-10-12.

De los 4 CVE de CVSS critical, 3 siguen con estado unreviewed en GitHub Advisory, y la lista de paquetes afectados está vacía (0 paquetes). Sin nombre de paquete no se puede hacer coincidir con el árbol de dependencias —— no entran en OSV, Dependabot no alerta, y un SCA que escanee el manifiesto de dependencias tampoco los detecta.

Consultando OSV con org.bouncycastle:bcprov-jdk18on:1.81 (2026-10-12), se obtienen 4 coincidencias: CVE-2025-14813, CVE-2026-0636, CVE-2026-13506, CVE-2026-8763 —— ninguno de los otros 3 critical aparece.

⚠️ Para dejar claro el límite: no es que «Dependabot no vea ninguna vulnerabilidad de BC» —— CVE-2026-0636, del mismo lote, está reviewed, tiene información de paquetes y alerta con normalidad. Lo que no se ve son los 3 critical marcados como unreviewed en la tabla siguiente.

CVE	GHSA	Estado (2026-10-12)	Nº de paquetes
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

La base de datos global registra para CVE-2026-8763 las versiones corregidas bcprov-jdk18on / bcprov-jdk15to18 1.85, bcprov-lts8on 2.73.12, bc-fips 1.0.2.7 / 2.0.2 / 2.1.3, en consonancia con la tabla de determinación de esta herramienta.

Uso

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

La ruta puede ser un archivo jar / war (incluyendo Spring Boot fat-JAR, que se expande automáticamente capa por capa), o también un directorio (recursivo).

Opción	Descripción
--gav <coordenada>	No escanea archivos, evalúa directamente una coordenada, como bcprov-lts8on:2.73.5
-d, --detail	Lista uno por uno los CVE encontrados y el texto oficial original
--json	Salida en JSON, fácil de integrar en pipelines (siempre UTF-8)
--utf8 / --gbk	Fuerza la codificación especificada cuando el chino en la consola se muestra como caracteres corruptos
--no-color	Desactiva la salida en color

Códigos de salida: 0 = sin coincidencias; 1 = CVE encontrado; 2 = error de uso. Se puede usar directamente como puerta de control en CI.

La salida se ve así

[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 线）

Cómo encuentra Bouncy Castle

En la gran mayoría de los casos, BC no lo has introducido tú mismo, sino que ha llegado arrastrado por dependencias transitivas: TLS, validación de certificados, JWT, firma de PDF y PGP lo incluyen. Por eso esta herramienta no mira el pom, sino solo el artefacto real:

1. Bundle-SymbolicName + Bundle-Version de META-INF/MANIFEST.MF (ruta principal)
2. El nombre del archivo jar
3. META-INF/maven/org.bouncycastle/*/pom.properties (no existe en los jars oficiales, solo en los reempaquetados)
4. Si solo se encuentran clases en org/bouncycastle/ pero no se reconocen las coordenadas → se reporta UNKNOWN y se indica que se confirme manualmente

El cuarto caso es el de BC embebido (shade) dentro del jar anfitrión; ni mvn dependency:tree ni SCA lo ven. Esta herramienta al menos te dirá «aquí hay BC, pero no reconozco la versión», en lugar de omitirlo silenciosamente.

Cuando el jar ha sido renombrado (algo habitual en republicaciones de repositorios internos), el nombre del archivo no se reconoce, pero el MANIFEST sí.

De dónde provienen los criterios de determinación

Todo proviene de las subpáginas individuales de las 37 CVE de 2026 en la wiki oficial de github.com/bcgit/bc-java (texto original de Issue affecting / Fixed versions), no de relatos de segunda mano ni de artículos agregados.

• Datos de primera mano: tools/data/bc_cves.json
• La tabla de determinación se genera automáticamente a partir de tools/gen_rules.py en CveTable.java, sin transcripción manual
• En el informe se adjunta el texto original oficial de cada entrada, para que puedas verificarlo tú mismo

Regenerar: python tools/gen_rules.py

🔴 Alcance de la determinación (lee esto antes de ver OK)