Skip to content

CVE-2026-32285: The jsonparser Advisory That Required No Patch

A security investigation that ended without a code change: the referenced upstream commit was already inherited (CVE-2025-62506), the resolved jsonparser dependency already contained the fix, and reachability analysis found no vulnerable path.

Status: Closed without a code change
GitHub issue: pgsty/silo#26
Referenced upstream commit: c1a49490 (CVE-2025-62506)

The initial assessment of CVE-2026-32285 assumed that the repository might still carry a vulnerable version of github.com/buger/jsonparser, and the team briefly considered replacing the package or maintaining a local fork. Checking the advisory’s referenced upstream commit, the resolved Go module version, and actual symbol reachability changed the conclusion:

  1. Public vulnerability feeds mislabeled CVE-2026-32285 as a jsonparser issue while pointing to upstream commit c1a49490, which is the session-policy privilege-escalation fix for CVE-2025-62506 already included in every SILO release since RELEASE.2025-12-03T12-00-00Z.
  2. For github.com/buger/jsonparser itself, the repository already resolved v1.1.2, which contains the upstream jsonparser fixes, and govulncheck found no reachable vulnerable symbol.

Instead of manufacturing a cosmetic dependency bump, we recorded the verification evidence and closed pgsty/silo#26.

What was wrong with the initial assumption

The issue was initially framed around the premise that jsonparser had no fixed upstream version in the tree. Acting on that premise without verifying the module graph and commit provenance would have caused real engineering harm:

  • altering the dependency graph for zero security benefit;
  • risking subtle behavioral regressions in JSON parsing paths for a nonexistent vulnerability;
  • taking on long-term maintenance of an unnecessary dependency fork;
  • misleading operators into believing that prior SILO releases were exposed when they were not.

Leaving already-remediated code unchanged is a deliberate security decision when backed by version and reachability evidence.

Investigation

The investigation verified four distinct layers:

  1. Commit provenance: Checked the commit linked by the CVE feed (c1a49490) and confirmed it is the inherited session-policy fix (CVE-2025-62506).
  2. Resolved module version: Verified go.mod and go.sum to confirm that github.com/buger/jsonparser resolves to v1.1.2, which already includes the upstream jsonparser patch.
  3. Symbol reachability: Ran govulncheck across the tree and confirmed that no vulnerable symbol is reachable.
  4. Feed discrepancy attribution: Traced the remaining alarm to mismatched metadata in external vulnerability feeds rather than unpatched code in the SILO tree.

When evaluating any dependency advisory, four questions must be kept separate: whether a package version was once listed as affected, whether the module is imported, whether a vulnerable symbol is reachable in the compiled call graph, and whether an external entry point can trigger that path with untrusted input.

Why there was no “just in case” upgrade

When the selected version in go.mod already contains the fix, bumping to an arbitrary commit or swapping libraries does not improve security. In a large Go module graph, unmotivated dependency churn expands the regression surface and obscures the cause of later behavioral changes.

We therefore took four concrete steps:

  • closed the issue without a synthetic commit;
  • recorded the commit provenance, v1.1.2 selection, and govulncheck output in pgsty/silo#26;
  • retained automated govulncheck and go.mod version gates in CI to prevent accidental dependency downgrades;
  • indexed CVE-2026-32285 alongside CVE-2025-62506 in the Security Advisories ledger so operators auditing scanner reports can find an authoritative answer.

Verification boundary

The investigation on 2026-04-15 established that SILO’s module graph (github.com/buger/jsonparser v1.1.2) and commit history (c1a49490) required no source change for CVE-2026-32285. Any future change to module selection or jsonparser imports remains subject to the standard CI govulncheck gate.

Engineering principle

For dependency CVEs, verify in order: what commit or version the advisory actually points to, which version go.mod selects, whether any vulnerable symbol enters the call graph, and whether a runtime entry point exposes it. Only when those checks reveal an unpatched or reachable flaw should the investigation produce a code diff.