CVE-2026-32285：最终无需补丁的 jsonparser 通告
状态： 无需代码改动，问题已关闭
GitHub Issue： pgsty/minio#26
安全维护不只有“发现漏洞，然后提交补丁”。CVE-2026-32285 的初始判断是：仓库可能仍携带未修复的 jsonparser，甚至一度讨论过替换依赖或维护自己的分支。真正检查 module version 与可达性后，结论却是当前代码已经使用包含修复的 v1.1.2，govulncheck 也没有发现可达的 vulnerable symbol。
最终正确的动作不是制造一个依赖升级，而是把证据记录下来，然后关闭问题。
初始判断为什么有问题
问题最初被理解成“该依赖没有可用的 fixed version”。如果直接按照这个前提行动，很容易出现几种看似积极、实际有害的结果：
- 无意义地改变 dependency graph；
- 为一次并不存在的修复引入新的兼容性回归；
- 增加本地 fork 的长期维护负担；
- 让用户误以为过去的 SILO Release 确实暴露于该漏洞。
安全工作不能用“有没有产生 diff”衡量。没有漏洞时不改代码，本身就是一个需要证据支持的安全决定。
研判过程
这次调查按四层证据逐步收敛：
- 核对当前
go.mod与go.sum中实际解析到的版本； - 检查上游 release，确认
v1.1.2已经包含对应补丁； - 运行并核对
govulncheck，没有发现可达 symbol； - 将 issue 中的差异归因于漏洞数据库或问题信息滞后，而不是当前源码仍然存在漏洞。
这里必须区分四件事：一个版本曾被标记为受影响、一个 package 被导入、漏洞 symbol 在程序中可达、以及远程输入能真正触发利用。这四个结论不能互相替代。
为什么不做“保险升级”
如果当前版本已经包含修复，再随便 bump 到另一个版本并不会让系统“更安全”。它只会扩大变化面，让后续回归更难归因。对一个庞大的 Go module graph 来说，这种无目标滚动尤其危险。
最终决定是：
- 不提交假修复；
- 在 issue 中保留版本与可达性证据；
- 继续让版本 gate 与
govulncheck防止未来依赖回退； - 不把“当前无需改动”写成永久豁免。
验证边界
本事件证明的是：2026-04-15 当时的 checkout 不需要为 CVE-2026-32285 修改代码。 它不代表所有未来分支、依赖图或发布版本永远不受影响。只要依赖发生降级或 module selection 改变，就必须重新做版本与可达性检查。
这篇文章记录的是当时的研判与关闭依据，不声称本次博客整理重新运行了原始 govulncheck。
这次事件留下的原则
安全维护的目标是让风险结论准确，而不是让每个 issue 都产生代码。面对依赖型 CVE，最重要的是依次回答：当前到底解析到哪个版本、漏洞代码是否进入程序、symbol 是否可达、部署入口是否可利用。只有这些问题的答案要求改变源码时，才应该制造 diff。