CVE-2026-32285：最终无需补丁的 jsonparser 通告
状态： 无需代码改动，问题已关闭
GitHub Issue： pgsty/silo#26
关联上游提交： c1a49490（CVE-2025-62506）
对 CVE-2026-32285 的初始排查假设仓库可能仍携带未修复的 github.com/buger/jsonparser，团队甚至一度评估过替换依赖或维护独立分支。但在逐一核对通告引用的上游提交、Go 模块实际解析版本以及符号可达性后，结论完全改变：
- 外部漏洞库将
CVE-2026-32285的摘要写成了jsonparser漏洞，但其绑定的修复提交c1a49490实际上是 CVE-2025-62506（Session Policy 权限提升）的上游修复，自RELEASE.2025-12-03T12-00-00Z起已包含在所有 SILO 版本中。 - 针对
github.com/buger/jsonparser本身，当前代码树已解析至包含修复的v1.1.2，且govulncheck未发现任何可达的漏洞符号。
因此，我们没有制造一次形式上的依赖升级，而是完整记录核查证据并关闭了 pgsty/silo#26。
初始假设为什么站不住脚
问题最初被表述为“该依赖尚无可用的修复版本”。如果未核对模块图与提交溯源就直接按该前提改动代码，会带来多重副作用：
- 在没有任何安全收益的情况下变动依赖图；
- 为一个并不存在的漏洞冒着引入 JSON 解析兼容性回归的风险；
- 背上长期维护额外第三方库分支的负担；
- 误导运维人员以为既有的 SILO 发行版曾暴露于该漏洞之下。
当证据表明代码已经安全时，保持代码不变本身就是明确的安全决策。
四层核查过程
本次研判按四层证据逐步收敛：
- 核对提交溯源：检查通告链接的上游提交
c1a49490，确认其为已原样继承的 Session Policy 修复（CVE-2025-62506）。 - 核对模块解析版本：检查
go.mod与go.sum中实际选中的版本，确认github.com/buger/jsonparser已处于包含上游补丁的v1.1.2。 - 符号可达性分析：运行
govulncheck，确认编译后的调用图中不存在可达的漏洞符号。 - 归因外部通告偏差：确认告警源于外部漏洞数据库的条目错配与信息滞后，而非当前源码树遗留漏洞。
评估依赖类安全通告时，必须严格区分四件事：某个历史版本曾被标记受影响、某个包被项目导入、漏洞符号在程序调用图中可达、以及外部不可信输入能通过部署入口真正触发该路径。
为什么不做“预防性盲目升级”
既然当前选中的版本已经包含修复，再随意滚动到其他提交或替换解析库并不会提升安全性。在庞大的 Go 模块依赖图中，无明确目标的依赖变更只会扩大变更面，使后续回归问题更难定位。
最终处置包含四项动作：
- 不提交拼凑出来的“修复提交”；
- 在 pgsty/silo#26 中归档提交溯源、
v1.1.2版本与govulncheck核查证据； - 由 CI 中的版本门禁与
govulncheck持续拦截未来的依赖回退； - 在安全公告台账中将
CVE-2026-32285与CVE-2025-62506对照登记，方便用户核对安全扫描器报告。
验证边界
2026-04-15 的核查证明：SILO 当前模块图（github.com/buger/jsonparser v1.1.2）与继承提交历史（c1a49490）无需为 CVE-2026-32285 修改代码。后续若模块选择或 jsonparser 调用方式发生变化，仍由常规 CI 版本门禁与 govulncheck 重新校验。
工程原则
面对依赖型 CVE，应依次核实四个问题：通告实际指向哪个提交或版本、go.mod 最终解析到哪个版本、漏洞符号是否进入编译调用图、以及运行时入口是否可利用。只有当这些核查证明源码确实存在未闭合路径时，才应当产出代码变更。