bc-check

Verifica offline quali di queste CVE di Bouncy Castle del 2026 influenzano la tua applicazione Java. Zero dipendenze, un singolo jar, nessuna connessione di rete, nessun caricamento di dati.

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

Perché serve uno strumento (e non basta dare un'occhiata al numero di versione)

Tutte le descrizioni ufficiali dei CVE riportano un'unica frase:

Bouncy Castle for Java before 1.85

Ma tra chi lo usa davvero, ci sono due linee di prodotto i cui numeri di versione non hanno affatto questo aspetto:

Linea di prodotto	artifact del tipo	versione del tipo	«before 1.85» è utile?
BC (versione standard)	bcprov-jdk18on	1.81	✅ Sì
BC-LTS (versione a supporto a lungo termine)	bcprov-lts8on	2.73.5	❌ Impossibile da determinare
BC-FJA (versione con certificazione FIPS)	bc-fips / bctls-fips …	1.0.2.5 / 2.0.1 / 2.1.2	❌ Impossibile da determinare

Le versioni corrette delle tre linee sono rispettivamente 1.85, 2.73.12 e una serie di numeri di versione distinti per ciascuno dei 7 artifact FIPS. Non si trovano sullo stesso asse numerico, quindi confrontarle tra loro non ha senso.

Quattro esempi che mostrano perché un approccio indiscriminato porta a conclusioni errate

1. CVE-2026-8149 non influisce affatto sulla linea BC, riguarda solo BC-LTS 2.73.0–2.73.10. Chi si concentra sul numero di versione «1.85» non lo scoprirà mai.
2. CVE-2026-59650 non influisce affatto sulla versione FIPS. Segnalarlo in base a «before 1.85» è un falso allarme.
3. CVE-2026-59638 sul lato FIPS richiede di verificare l'artifact bctls-fips, non bc-fips —— si passa dal nucleo crittografico al modulo TLS. Chi guarda solo bc-fips non lo trova.
4. CVE-2026-58062 e 58060 elencano ufficialmente solo 2.0.2 e 2.1.3 di bc-fips, senza 1.0.x —— il che significa che la linea 1.0.x non è interessata. Mentre CVE-2026-8763 elenca 1.0.2.7, quindi 1.0.x è interessata. Stesso artifact, stessa versione, CVE diversi danno risposte diverse.

Ci sono inoltre 10 CVE con una versione iniziale interessata (from 1.61, from 1.66, from 1.73, tutte diverse), non è «tutte le versioni sono interessate»; altre 4 vecchie CVE hanno come versione corretta versioni di ramo come 1.80.2 / 1.81.1 / 1.84, e gli intervalli interessati sono discontinui (1.74–1.80.1, 1.81, 1.82–1.83).

Anche supponendo di aver letto tutti gli avvisi e di conoscere tutte le risposte, non potresti comunque verificare —— perché la risposta non è un numero di versione, ma una tabella tridimensionale «linea di prodotto × artifact × CVE».

Un'altra cosa: molto probabilmente il tuo Dependabot non segnalerà questo gruppo di CVE

Correzione (2026-10-12): questa sezione in precedenza diceva «tutti e 4 i CVE con CVSS critical sono unreviewed, Dependabot non li vede». Tra questi, CVE-2026-8763 è stato revisionato e incluso da GitHub il 2026-09-18, con l'aggiunta delle informazioni sui pacchetti, quindi ora Dependabot e OSV lo vedono. Restano invisibili gli altri 3. Di seguito la versione corretta in base alle verifiche effettive del 2026-10-12.

Dei 4 CVE con CVSS critical, 3 hanno ancora lo stato unreviewed nel GitHub Advisory, con la lista dei pacchetti interessati vuota (numero di pacchetti 0). Senza il nome del pacchetto non è possibile confrontare l'albero delle dipendenze —— non entrano in OSV, Dependabot non segnala, e anche la scansione SCA degli elenchi delle dipendenze non li rileva.

Interrogando OSV con org.bouncycastle:bcprov-jdk18on:1.81 (2026-10-12), si ottengono 4 risultati: CVE-2025-14813, CVE-2026-0636, CVE-2026-13506, CVE-2026-8763 —— nessuno degli altri 3 critical è presente.

⚠️ Per chiarire i limiti: non è che «Dependabot non vede tutte le vulnerabilità di BC» —— CVE-2026-0636, dello stesso gruppo, è reviewed, ha le informazioni sui pacchetti e viene segnalato normalmente. Quelli invisibili sono i 3 critical contrassegnati come unreviewed nella tabella seguente.

CVE	GHSA	Stato (2026-10-12)	Numero di pacchetti
CVE-2026-58062	GHSA-j295-77c3-9frf	unreviewed	0
CVE-2026-8763	GHSA-9pwp-9qqc-pr26	reviewed (dal 2026-09-18)	6
CVE-2026-59650	GHSA-ghgq-7g74-28wp	unreviewed	0
CVE-2026-59638	GHSA-8rxj-3p7p-rq39	unreviewed	0

La versione corretta registrata nel database globale per CVE-2026-8763 è bcprov-jdk18on / bcprov-jdk15to18 1.85, bcprov-lts8on 2.73.12, bc-fips 1.0.2.7 / 2.0.2 / 2.1.3, coerente con la tabella di valutazione di questo strumento.

Utilizzo

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

Il percorso può essere un file jar / war (inclusi i fat-JAR di Spring Boot, espansi automaticamente livello per livello), oppure una directory (ricorsiva).

Opzione	Descrizione
--gav <coordinate>	Non scansiona file, valuta direttamente una coordinata, ad es. bcprov-lts8on:2.73.5
-d, --detail	Elenca in dettaglio le CVE rilevate e il testo ufficiale originale
--json	Restituisce l'output in JSON, utile per l'integrazione nelle pipeline (sempre UTF-8)
--utf8 / --gbk	Forza la codifica specificata quando i caratteri cinesi nella console risultano illeggibili
--no-color	Disattiva l'output colorato

Codice di uscita: 0 = nessuna corrispondenza; 1 = CVE rilevata; 2 = errore di utilizzo. Utilizzabile direttamente come gate in CI.

L'output è così

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

Come trova Bouncy Castle

Nella stragrande maggioranza dei casi BC non è una tua dipendenza diretta, ma viene trascinato dentro dalle dipendenze transitive — TLS, validazione dei certificati, JWT, firma PDF, PGP lo richiamano tutti. Per questo lo strumento non guarda il pom, ma solo gli artefatti reali:

1. Bundle-SymbolicName + Bundle-Version in META-INF/MANIFEST.MF (percorso principale)
2. il nome del file jar
3. META-INF/maven/org.bouncycastle/*/pom.properties (assente nei jar ufficiali, presente solo in quelli ripacchettizzati)
4. se trova solo le classi org/bouncycastle/ ma non riesce a riconoscere le coordinate → segnala UNKNOWN e invita alla verifica manuale

Il quarto caso è quello in cui BC è stato shade dentro il jar host: mvn dependency:tree e SCA non lo vedono, questo strumento almeno ti dice «qui c'è BC, ma non ne riconosco la versione», invece di ometterlo silenziosamente.

Se il jar è stato rinominato (cosa molto comune quando un repository interno ripubblica gli artefatti), il nome del file non è riconoscibile, ma il MANIFEST lo è ancora.

Da dove provengono i criteri di valutazione

Tutto proviene dalle sottopagine dedicate a ciascuna delle 37 CVE del 2026 sulla wiki ufficiale github.com/bcgit/bc-java (testo originale di Issue affecting / Fixed versions), non da resoconti di seconda mano né da articoli aggregatori.

• Dati di prima mano: tools/data/bc_cves.json
• La tabella di valutazione è generata automaticamente in CveTable.java da tools/gen_rules.py, non copiata a mano
• Il report allega per ogni voce il testo ufficiale originale, così puoi verificarlo da solo

Rigenerazione: python tools/gen_rules.py

🔴 Ambito di valutazione (leggi questa parte prima di vedere OK)