bc-check

Identifiez hors ligne quelles CVE de la vague 2026 de Bouncy Castle affectent votre application Java. Zéro dépendance, un seul jar, sans connexion réseau, sans téléversement d'aucune donnée.

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

Pourquoi un outil est nécessaire (et pas un simple coup d'œil au numéro de version)

Toutes les descriptions officielles des CVE se résument à une seule phrase :

Bouncy Castle for Java before 1.85

Mais parmi ceux qui l'utilisent réellement, les numéros de version de deux gammes de produits ne ressemblent pas du tout à cela :

Gamme de produits	artifact de la forme	numéro de version de la forme	« before 1.85 » lui est-il utile
BC (version standard)	bcprov-jdk18on	1.81	✅ utile
BC-LTS (version support à long terme)	bcprov-lts8on	2.73.5	❌ impossible de juger
BC-FJA (version certifiée FIPS)	bc-fips / bctls-fips …	1.0.2.5 / 2.0.1 / 2.1.2	❌ impossible de juger

Les versions corrigées des trois lignes sont respectivement 1.85, 2.73.12, et un jeu de numéros de version propre à chacun des 7 artifacts FIPS. Elles ne se situent pas sur le même axe numérique ; les comparer entre elles n'a aucun sens.

Quatre exemples montrant pourquoi une approche uniforme donne des conclusions erronées

1. CVE-2026-8149 n'affecte pas du tout la ligne BC, il n'affecte que BC-LTS 2.73.0–2.73.10. Ceux qui se focalisent sur le numéro de version « 1.85 » ne le découvriront jamais.
2. CVE-2026-59650 n'affecte pas du tout la version FIPS. Le signaler selon « before 1.85 » provoque une fausse alerte.
3. CVE-2026-59638 côté FIPS, l'artifact à vérifier est bctls-fips, et non bc-fips —— on passe du cœur cryptographique au module TLS. Ceux qui ne regardent que bc-fips ne le trouveront pas.
4. CVE-2026-58062 et 58060 ne listent officiellement que 2.0.2 et 2.1.3 de bc-fips, sans 1.0.x —— cela signifie que la ligne 1.0.x n'est pas affectée. Or CVE-2026-8763 liste 1.0.2.7, donc 1.0.x est affecté. Même artifact, même version, des CVE différents donnent des réponses différentes.

Il y a aussi 10 CVE avec une version de début d'affectation (from 1.61, from 1.66, from 1.73 tous différents), ce n'est pas « toutes les versions sont affectées » ; 4 autres anciens CVE ont une version corrigée qui est une version de branche comme 1.80.2 / 1.81.1 / 1.84, et l'intervalle affecté est discontinu (1.74–1.80.1, 1.81, 1.82–1.83).

Supposez que vous ayez déjà lu toutes les annonces et connaissiez toutes les réponses, vous ne pouvez toujours pas vérifier —— car la réponse n'est pas un numéro de version, c'est un tableau tridimensionnel « gamme de produits × artifact × CVE ».

Autre chose : votre Dependabot ne vous alertera probablement pas sur cette série de CVE

Correction (2026-10-12) : cette section indiquait initialement « les 4 CVE de criticité CVSS critical sont tous unreviewed, invisibles pour Dependabot ». Parmi eux, CVE-2026-8763 a été le 2026-09-18 examiné et intégré par GitHub avec ajout des informations de paquet, désormais Dependabot et OSV le voient. Les 3 autres restent invisibles. Voici la version corrigée selon les tests réels du 2026-10-12.

Sur les 4 CVE de criticité CVSS critical, 3 ont encore le statut unreviewed dans GitHub Advisory, la liste des paquets affectés est vide (0 paquet). Sans nom de paquet, impossible de faire correspondre l'arbre de dépendances —— ils n'entrent pas dans OSV, Dependabot n'alerte pas, et un scan SCA des manifestes de dépendances ne les détecte pas non plus.

En interrogeant OSV avec org.bouncycastle:bcprov-jdk18on:1.81 (2026-10-12), on obtient 4 résultats : CVE-2025-14813, CVE-2026-0636, CVE-2026-13506, CVE-2026-8763 —— aucun des 3 autres critical n'y figure.

⚠️ Précisons les limites : ce n'est pas « Dependabot ne voit aucune vulnérabilité de BC » —— dans la même série, CVE-2026-0636 est justement reviewed, avec informations de paquet, et alerte normalement. Ce qui est invisible, ce sont les 3 critical marqués unreviewed dans le tableau ci-dessous.

CVE	GHSA	Statut (2026-10-12)	Nombre de paquets
CVE-2026-58062	GHSA-j295-77c3-9frf	unreviewed	0
CVE-2026-8763	GHSA-9pwp-9qqc-pr26	reviewed (depuis le 2026-09-18)	6
CVE-2026-59650	GHSA-ghgq-7g74-28wp	unreviewed	0
CVE-2026-59638	GHSA-8rxj-3p7p-rq39	unreviewed	0

La version corrigée enregistrée par la base globale pour CVE-2026-8763 est bcprov-jdk18on / bcprov-jdk15to18 1.85, bcprov-lts8on 2.73.12, bc-fips 1.0.2.7 / 2.0.2 / 2.1.3, ce qui est cohérent avec la table de détermination de cet outil.

Utilisation

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

Le chemin peut être un fichier jar / war (y compris un fat-JAR Spring Boot, décompressé automatiquement couche par couche), ou un répertoire (récursif).

Option	Description
--gav <coordonnées>	Ne scanne pas de fichier, évalue directement une coordonnée, comme bcprov-lts8on:2.73.5
-d, --detail	Liste un par un les CVE correspondantes et le texte officiel d'origine
--json	Sortie JSON, pratique pour l'intégration dans un pipeline (toujours en UTF-8)
--utf8 / --gbk	Force l'encodage lorsque les caractères chinois de la console sont illisibles
--no-color	Désactive la sortie en couleur

Code de sortie : 0 = aucune correspondance ; 1 = CVE correspondante ; 2 = erreur d'utilisation. Utilisable directement comme garde-fou CI.

La sortie ressemble à ceci

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

Comment il trouve Bouncy Castle

Dans la grande majorité des cas, BC n'est pas une dépendance que vous avez ajoutée vous-même : il est tiré par des dépendances transitives — TLS, la validation de certificats, JWT, la signature PDF, PGP l'introduisent tous. C'est pourquoi cet outil ne regarde pas le pom, mais uniquement les artefacts réels :

1. Bundle-SymbolicName + Bundle-Version du META-INF/MANIFEST.MF (chemin principal)
2. le nom du fichier jar
3. META-INF/maven/org.bouncycastle/*/pom.properties (absent des jars officiels, présent uniquement dans les jars repackagés)
4. si seules des classes org/bouncycastle/ sont trouvées sans coordonnées identifiables → signale UNKNOWN et invite à une vérification manuelle

Le quatrième cas correspond à une shade dans le jar hôte : mvn dependency:tree et les SCA ne le voient pas, cet outil vous dira au moins « il y a du BC ici, mais je n'identifie pas la version », plutôt que de l'omettre silencieusement.

Lorsqu'un jar est renommé (fréquent lors d'une republication sur un dépôt d'artefacts interne), le nom de fichier n'est pas identifiable, mais le MANIFEST l'est toujours.

D'où viennent les critères de décision

Tout provient des sous-pages dédiées aux 37 CVE de 2026 du wiki officiel github.com/bcgit/bc-java (texte original de Issue affecting / Fixed versions), pas de reprises de seconde main, pas d'articles agrégateurs.

• Données de première main : tools/data/bc_cves.json
• La table de décision est générée automatiquement en CveTable.java par tools/gen_rules.py, sans recopie manuelle
• Le rapport joint le texte officiel original pour chaque entrée, vous pouvez vérifier vous-même