bc-check

Prüfe offline, von welchen CVEs aus der Bouncy-Castle-Charge 2026 deine Java-Anwendung betroffen ist. Keine Abhängigkeiten, eine einzige Jar-Datei, kein Netzwerkzugriff, keine Datenübertragung.

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

Warum ein Tool nötig ist (und nicht einfach ein Blick auf die Versionsnummer)

Alle offiziellen CVE-Beschreibungen enthalten einheitlich einen einzigen Satz:

Bouncy Castle for Java before 1.85

Doch bei den tatsächlichen Nutzern sehen die Versionsnummern zweier Produktlinien überhaupt nicht so aus:

Produktlinie	artifact sieht aus wie	Versionsnummer sieht aus wie	Hilft ihm „before 1.85"?
BC (Standardversion)	bcprov-jdk18on	1.81	✅ Hilfreich
BC-LTS (Long-Term-Support-Version)	bcprov-lts8on	2.73.5	❌ Völlig unbrauchbar zur Beurteilung
BC-FJA (FIPS-zertifizierte Version)	bc-fips / bctls-fips …	1.0.2.5 / 2.0.1 / 2.1.2	❌ Völlig unbrauchbar zur Beurteilung

Die Fix-Versionen der drei Linien sind 1.85, 2.73.12 sowie je ein eigener Versionssatz für die 7 FIPS-Artefakte. Sie liegen nicht auf derselben Zahlenachse; ein gegenseitiger Vergleich ist sinnlos.

Vier Beispiele, die zeigen, warum eine Pauschallösung zu falschen Schlüssen führt

1. CVE-2026-8149 betrifft die BC-Linie überhaupt nicht, sondern nur BC-LTS 2.73.0–2.73.10. Wer auf die Versionsnummer „1.85" starrt, wird es niemals entdecken.
2. CVE-2026-59650 betrifft die FIPS-Version überhaupt nicht. Eine Meldung nach „before 1.85" ist ein Fehlalarm.
3. CVE-2026-59638 betrifft auf der FIPS-Seite das Artefakt bctls-fips, nicht bc-fips – vom Kryptokern wechselt es zum TLS-Modul. Wer nur auf bc-fips starrt, findet es nicht.
4. CVE-2026-58062 und 58060 listen offiziell nur 2.0.2 und 2.1.3 von bc-fips, nicht 1.0.x – das bedeutet, die 1.0.x-Linie ist nicht betroffen. CVE-2026-8763 hingegen listet 1.0.2.7, also ist 1.0.x betroffen. Dasselbe Artefakt, dieselbe Version, unterschiedliche CVEs liefern unterschiedliche Antworten.

Außerdem haben 10 CVEs eine betroffene Startversion (from 1.61, from 1.66, from 1.73 unterscheiden sich jeweils), es ist nicht „alle Versionen betroffen"; bei weiteren 4 alten CVEs sind die Fix-Versionen Branch-Versionen wie 1.80.2 / 1.81.1 / 1.84, und die betroffenen Bereiche sind diskontinuierlich (1.74–1.80.1, 1.81, 1.82–1.83).

Angenommen, du hast alle Ankündigungen gelesen und kennst alle Antworten, kannst du es trotzdem nicht nachschlagen – denn die Antwort ist keine Versionsnummer, sondern eine dreidimensionale Tabelle „Produktlinie × Artefakt × CVE".

Noch etwas: Bei diesen CVEs wird dein Dependabot höchstwahrscheinlich nicht warnen

Korrektur (2026-10-12): Dieser Abschnitt besagte ursprünglich, „alle 4 CVSS-critical-Einträge sind unreviewed, Dependabot sieht sie nicht". Davon wurde CVE-2026-8763 am 2026-09-18 von GitHub geprüft, aufgenommen und um Paketinformationen ergänzt; jetzt sehen Dependabot und OSV es. Unsichtbar bleiben weiterhin die anderen 3. Unten steht die anhand von Messungen vom 2026-10-12 überarbeitete Version.

Von den 4 CVSS-critical-Einträgen haben 3 im GitHub Advisory weiterhin den Status unreviewed, und die Liste der betroffenen Pakete ist leer (Paketanzahl 0). Ohne Paketnamen lässt sich kein Abhängigkeitsbaum abgleichen – sie gelangen nicht in OSV, Dependabot warnt nicht, und auch ein SCA-Scan der Abhängigkeitsliste findet sie nicht.

Fragt man OSV mit org.bouncycastle:bcprov-jdk18on:1.81 ab (2026-10-12), erhält man 4 Treffer: CVE-2025-14813, CVE-2026-0636, CVE-2026-13506, CVE-2026-8763 – von den anderen 3 critical-Einträgen ist keiner dabei.

⚠️ Zur Klarstellung der Grenzen: Es heißt nicht „Dependabot sieht keine BC-Schwachstellen" – CVE-2026-0636 aus derselben Gruppe ist reviewed, hat Paketinformationen und warnt ordnungsgemäß. Unsichtbar sind die 3 critical-Einträge, die in der folgenden Tabelle mit unreviewed markiert sind.

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

Die globale Datenbank registriert für CVE-2026-8763 die Fix-Versionen bcprov-jdk18on / bcprov-jdk15to18 1.85, bcprov-lts8on 2.73.12, bc-fips 1.0.2.7 / 2.0.2 / 2.1.3, was mit der Bewertungstabelle dieses Tools übereinstimmt.

Verwendung

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

Der Pfad kann eine jar-/war-Datei sein (einschließlich Spring Boot Fat-JAR, das automatisch Ebene für Ebene entpackt wird), oder ein Verzeichnis (rekursiv).

Option	Beschreibung
--gav <Koordinaten>	Keine Dateien scannen, sondern direkt eine Koordinate prüfen, z. B. bcprov-lts8on:2.73.5
-d, --detail	Jede gefundene CVE mit dem offiziellen Originaltext auflisten
--json	JSON ausgeben, praktisch für die Pipeline-Anbindung (immer UTF-8)
--utf8 / --gbk	Bei Zeichensalat in der Konsole die Kodierung erzwingen
--no-color	Farbige Ausgabe deaktivieren

Exit-Codes: 0 = kein Treffer; 1 = CVE gefunden; 2 = Fehler bei der Verwendung. Direkt als CI-Gate einsetzbar.

Die Ausgabe sieht so aus

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

Wie es Bouncy Castle findet

BC wird in den allermeisten Fällen nicht von dir selbst eingebunden, sondern über transitive Abhängigkeiten hereingezogen – TLS, Zertifikatsprüfung, JWT, PDF-Signaturen und PGP ziehen es alle herein. Deshalb schaut dieses Tool nicht auf die pom, sondern nur auf die tatsächlichen Artefakte:

1. Bundle-SymbolicName + Bundle-Version aus META-INF/MANIFEST.MF (Hauptpfad)
2. den jar-Dateinamen
3. META-INF/maven/org.bouncycastle/*/pom.properties (in offiziellen jars nicht vorhanden, nur in neu gepackten)
4. Wenn nur Klassen unter org/bouncycastle/ gefunden werden, die Koordinaten aber nicht erkannt werden → UNKNOWN melden und zur manuellen Bestätigung auffordern

Fall 4 ist der Fall, in dem es in den Host-jar geshadet wurde; mvn dependency:tree und SCA sehen es nicht, dieses Tool sagt dir zumindest „hier ist BC, aber ich kann die Version nicht erkennen", statt es stillschweigend zu übersehen.

Wenn der jar umbenannt wurde (bei Neuveröffentlichungen in internen Artefakt-Repositories sehr verbreitet), ist der Dateiname nicht erkennbar, das MANIFEST aber schon.

Woher die Bewertungsgrundlage kommt

Alles stammt aus den 37 einzelnen CVE-Unterseiten von 2026 im offiziellen Wiki github.com/bcgit/bc-java (Originaltext von Issue affecting / Fixed versions), nicht aus zweiter Hand und nicht aus aggregierten Artikeln.

• Primärdaten: tools/data/bc_cves.json
• Die Bewertungstabelle wird von tools/gen_rules.py automatisch als CveTable.java generiert, nicht manuell abgeschrieben
• Im Bericht wird jeweils der offizielle Originaltext beigefügt, sodass du selbst nachprüfen kannst

Neu generieren: python tools/gen_rules.py

🔴 Bewertungsumfang (lies diesen Abschnitt, bevor du ein OK siehst)