2026-10-12 更正本文原先写「4 条 CVSS critical 在 GitHub Advisory 里都是unreviewedDependabot 看不见」。其中CVE-2026-8763 已于 2026-09-18 被 GitHub 审核收录并补上了包信息现在 Dependabot 和 OSV 看得见它。仍然看不见的是另外 3 条CVE-2026-58062 / CVE-2026-59650 / CVE-2026-59638。正文讲 Dependabot 的那一节已按 2026-10-12 的实测改过三条产品线各自该升到哪个版本的结论没有变。如果你是搜bouncycastle 1.85、CVE-2026-58062、bcprov-jdk18on 漏洞、bc-fips 升级进来的直接看这张表你要的答案在里面你用的是artifact 形如升到BC 常规版bcprov-jdk18on/bcprov-jdk15to181.85BC-LTSbcprov-lts8on2.73.12BC-FJAFIPSbc-fips1.0.2.7/2.0.2/2.1.3看你在哪条版本线BC-FJAFIPSbctls-fips1.0.24/2.0.24/2.1.24BC-FJAFIPSbcpkix-fips1.0.12/2.0.12/2.1.12BC-FJAFIPSbcpg-fips1.0.13/2.0.13/2.1.13BC-FJAFIPSbcmail-fips/bcjmail-fips1.0.7/2.0.7/2.1.7BC-FJAFIPSbcutil-fips2.0.7/2.1.7⚠️ 这个 artifact 没有 1.0.x 线为什么不是一句「升到 1.85」就完了往下看。Bouncy Castle 2026 年到底出了多少 CVE官方 wiki 口径是37 条其中 4 条 CVSS critical。而官方 release 页写的是「1.85 修了 23 个」——这两个数字不是同一个集合37 条里有一部分的修复版是1.84、1.80.2这类更早的分支版本。所以别拿「23」去对账。官方说 before 1.85为什么我还是判断不了因为三条产品线的版本号根本不在同一条数轴上产品线artifact 形如你看到的版本号修复版BC常规版bcprov-jdk18on1.811.85BC-LTS长期支持版bcprov-lts8on2.73.52.73.12BC-FJAFIPS 认证版bc-fips/bctls-fips…1.0.2.5/2.0.17 个 artifact 各一套拿「before 1.85」去比对2.73.5得到的不是「安全」也不是「不安全」是没有意义。下面四个例子每一个都能让一刀切给出错误结论。CVE-2026-8149它压根不影响 BC 线官方原文Issue affecting: BC-LTS 2.73.0 to 2.73.10修复版2.73.11。它只影响 BC-LTS。盯着「1.85」这个数字的人永远发现不了它。CVE-2026-59650它完全不影响 FIPS 版官方原文只写了BC before 1.85, BC-LTS before 2.73.12—— FIPS 侧一个字都没有。按「before 1.85」去报是一次虚惊。CVE-2026-59638FIPS 侧要查的 artifact 换了它的 FIPS 修复版是bctls-fips1.0.24 / 2.0.24 / 2.1.24—— 从加密核心bcprov换到了 TLS 模块。只盯着bc-fips的人查不到它。漏洞本身JSSE 的 hostname verifier 默认启用了文档里写着「需显式开启」的 CN 回退。同一个版本不同 CVE 不同答案CVEbc-fips官方列出的受影响版本线CVE-2026-580622.0.2和2.1.3——没有 1.0.xCVE-2026-580602.0.2和2.1.3——没有 1.0.xCVE-2026-87631.0.2.7、2.0.2、2.1.3——1.0.x 受影响官方没列出的版本线 不受影响。所以同样是bc-fips 1.0.2.5它受 8763 影响不受 58062 影响。而且不是「全版本受影响」10 条 CVE 带起始受影响版本各不相同 ——from 1.61、from 1.66、from 1.70、from 1.71、from 1.73、from 1.74、from 1.81。4 条老 CVE 的受影响区间是断开的1.74–1.80.11.811.82–1.83修复版对应1.80.2/1.81.1/1.84三个分支版本。1.80.2修了它们但仍然小于1.85照样中着另外一批。假设你已经读完了所有公告、知道了全部答案你依然查不了——因为答案不是一个版本号是一张「产品线 × artifact × CVE」的三维表。为什么 Dependabot 没提醒我4 条 CVSS critical 里有 3 条在 GitHub Advisory 里的状态仍是unreviewed、vulnerabilities是空数组2026-10-12 实测CVE-2026-8763 已于 2026-09-18 转为 reviewedCVEGHSAtype受影响包数CVE-2026-58062GHSA-j295-77c3-9frfunreviewed0CVE-2026-8763GHSA-9pwp-9qqc-pr26reviewed2026-09-18 起6CVE-2026-59650GHSA-ghgq-7g74-28wpunreviewed0CVE-2026-59638GHSA-8rxj-3p7p-rq39unreviewed0没有包名就无法与你的依赖树做匹配。这类条目不会进 OSV而 Dependabot 以及绝大多数 SCA 工具的数据源正是 OSV。自己验证一下2026-10-12 实测gh api advisories/GHSA-j295-77c3-9frf--jq{type, severity, pkgs: (.vulnerabilities|length)}# {type:unreviewed,severity:critical,pkgs:0}curl-s-XPOST https://api.osv.dev/v1/query-HContent-Type: application/json\-d{package:{ecosystem:Maven,name:org.bouncycastle:bcprov-jdk18on},version:1.81}\|jq[.vulns[].aliases[]]# [CVE-2025-14813,CVE-2026-8763,CVE-2026-0636,CVE-2026-13506] ← 8763 现在在里面了另外 3 条 critical 仍然不在⚠️这里要说准确不是「BC 的漏洞 Dependabot 全看不见」。同一批里的CVE-2026-0636就是 reviewed、有包信息、正常告警的 —— 上面那条查询结果里就有它。看不见的是上表里仍标unreviewed的 3 条 critical。怎么查我的项目我写了个离线工具单个 jar、零依赖、不联网、不上传任何数据github.com/xiaoqiMikko/bc-check# 扫 jar / war / 目录Spring Boot fat-JAR 会逐层展开java-jarbc-check.jar ./app.jar# 或者不扫文件直接判一个坐标java-jarbc-check.jar--gavbcprov-lts8on:2.73.5--detail输出长这样[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 条 处置 升级到 2.73.12BC-LTS 线判定依据全部来自官方github.com/bcgit/bc-javawiki 上 37 条 CVE 的逐条子页面原文不是二手转述。一手数据随仓库发布报告里逐条附官方原文你可以自己核对。常见问题Q我升到 1.85 了还需要管别的吗BC 线升到 1.85 就覆盖了 2026 年这批的全部。但 2026 年之前的漏洞不在本文范围内那些 Dependabot 查得到。Q1.85.1比1.85新是不是该升 1.85.1不需要。官方 release notes 原文写明1.85.1是为 Java 5–8 那个包的packaging issue出的和 1.85 同属一次 release不是安全修复。2.73.12.1同理。Q我用的是bcprov-jdk15to18和jdk18on一样吗判定上一样都是 BC 线都升 1.85。Q怎么知道我的项目里到底有没有 BC、是哪个版本它多半不是你自己引的是被传递依赖拖进来的 —— TLS、证书校验、JWT、PDF 签名、PGP 都会引它。可以用上面的工具扫 jar也可以mvn dependency:tree | grep bouncycastle—— 但后者查不到被 shade 进宿主 jar 的那种。