Bump x/crypto to 0.56.0 and grpc to 1.83.1 for three HIGH CVE rows

[ai-collaboration-app]

Clears the three fixable HIGH rows the dev chart scan 34027081656 attributes to this repository, and corrects one exception record that turned out to be factually wrong. Tracked in #509, coordinated from cve-reporter#29.

The bump

CVE	Advisory	Package	From	To
CVE-2026-56855	GO-2026-6355	golang.org/x/crypto	v0.55.0	v0.56.0
CVE-2026-78662	GO-2026-6354	golang.org/x/crypto	v0.55.0	v0.56.0
CVE-2026-84304	GHSA-vp52-pcj8-j9qc	google.golang.org/grpc	v1.82.1	v1.83.1

Both x/crypto defects are DoS-on-deadlocked-channel bugs in golang.org/x/crypto/ssh, both fixed: 0.56.0. The grpc defect is heap exhaustion via HTTP/2 DATA frame fragmentation, vulnerable <= 1.83.0, first patched 1.83.1. Every fixed version was read from the upstream advisory, not taken from the scanner's lead.

Why this is not the two open dependabot PRs

The scan pins both findings to the root module, which is where the shipped binaries come from. Neither open grpc PR touches it:

• Bump google.golang.org/grpc from 1.80.0 to 1.83.2 in /comp/otelcol/otlp/components/statsprocessor #503 bumps comp/otelcol/otlp/components/statsprocessor — absent from go.work and not required by the root go.mod, so it reaches no shipped binary. Same category as datadogconnector and test/integration/serverless/src. It stays valid for its own module and is not duplicated here.
• Bump google.golang.org/grpc from 1.82.1 to 1.83.1 in /test/e2e-framework #504 bumps test/e2e-framework, a test-only module that ships in no image. It is subsumed: go work sync from the root bump already moves that module to grpc v1.83.1, so it can be closed as redundant once this lands.

The thrift PRs #505/#506 are unrelated to this scan — no thrift row is attributed to stackstate-agent; this cycle's thrift advisory (CVE-2026-43871, maven libthrift) belongs to stackgraph.

How it was applied

go get on the root module, then go work sync, then go mod tidy across all 186 workspace modules — what CI's check-mod-tidy reproduces. cel.dev/expr and detectors/gcp move as MVS consequences of grpc 1.83.1.

Four modules stay behind deliberately: statsprocessor, datadogconnector, pkg/dyninst/testprogs/progs and test/integration/serverless/src are all outside the workspace and outside the root build graph, so they reach no shipped binary and tidy would not raise them either.

Verification

Read back with go version -m on binaries built for both published architectures:

Binary	x/crypto	grpc
installer amd64	v0.56.0	v1.83.1
installer arm64	v0.56.0	v1.83.1
cluster-agent amd64	v0.56.0	v1.83.1

No v0.55.0 or v1.82.1 anywhere in the embedded module graphs, and go.sum no longer carries x/crypto v0.55.0 at all. All 186 modules tidy clean with no errors.

Local builds are direct go build of the same main packages, not the full omnibus/branded pipeline — the arm64 cgo cluster-agent and the rtloader-linked agent need the prewarmed CI container, so required CI is the authority for the per-arch shipped artifacts and is being followed to a terminal state. Corroborating detail: go list -deps shows the cluster-agent links neither x/crypto/ssh nor x/crypto/openpgp, which matches the scan attributing the x/crypto rows to the agent image only.

Both GO-2026-5932 exceptions are kept

That advisory is the "openpgp package is unmaintained" report with introduced: 0 and no fixed version in any release, so it applies to v0.56.0 exactly as it did to v0.55.0. Only the pinned purl moves so the record stays truthful. Expiry dates are untouched — those are the owner's call.

Commits two and three: correcting CVE-2026-4360

exceptions/stackstate-k8s-agent/CVE-2026-4360.yaml claimed upstream had published no fixed CPython in any release line. That is wrong.

Upstream fixed it on every maintained branch in June/July 2026. The 3.13 backport is python/cpython@eee3ddf0, and comparing eee3ddf0...v3.13.15 gives behind_by: 0 — the commit is an ancestor of the v3.13.15 tag. The embedded interpreter is pinned to 3.13.15, so this image already carries the fix and the row reflects vulnerability-data quality, not exposure. The scanner reports "no fixed version" for a traceable reason, not merely an odd one: the PSF advisory expresses the fix only as git commits with no version ranges, and the first commit it lists — python/cpython@c37a4fdf — is the 2012-04-06 "bump to 3.1.5 final" release commit that the lightweight v3.1.5 tag points at. A deriver resolving that commit to its nearest tag yields "fixed in 3.1.5", which is exactly the single < 3.1.5 CPE range NVD carries, roughly fourteen years before this advisory was published.

The third commit (c22f7cbd) exists because review caught a factual error in the second: the file had said "16 years", but Python 3.1.5 is dated 2012, making the gap about fourteen years. That commit fixes the number and replaces the earlier hand-wave ("obvious data-entry artifact") with the traceable cause above.

Left as under_investigation on purpose: retiring the file turns the row unmanaged, and asserting not_affected belongs in a reviewed vexhub statement. No .trivyignore entry and no new suppression was added anywhere in this PR.

Not addressed here — needs a human decision

Nine rows have no adoptable fix, and one more is already fixed in the shipped build but misreported by the scanner. Keeping those apart matters — counting all ten as "no fix" would contradict the correction this PR makes. All are recorded as deferred on #509 with evidence, owner @StackVista/observability-team:

• krb5 1.21.3 — CVE-2026-40355 and CVE-2026-40356 are true positives with no released fix (upstream committed it, but 1.22.3 is unreleased and 1.22.2 is still in range, so even a bump to latest would not clear them). CVE-2007-3149 and CVE-2007-5894 look like versionless-CPE mismatches: the first is a sudo defect and the second is vendor-disputed gssftp ftpd, neither of which is the shipped libkrb5.so.3.3.
• python 3.13.15, no adoptable fix (five rows) — CVE-2025-15367, CVE-2026-15806, CVE-2026-17084, CVE-2026-19672, CVE-2026-15310 are fixed only in unreleased 3.15/3.16.
• python 3.13.15, already fixed (one row) — CVE-2026-4360 is not in the no-fix group: the installed 3.13.15 interpreter carries the fix, as shown above. It stays deferred only because the disposition (reviewed vexhub statement versus scoped exception) is the owner's call.

Also flagged on #509: all four exception files expired on 2026-09-04. The fail-closed behaviour #500 established is live, but it lives in image-pipeline (evaluator/evaluate.go), which is why #501 was closed unmerged. Nothing is silently lapsing in a gating sense, but this repo's own image scan is mode: inform, so those dates gate nothing here and need renewing or retiring by their owner.

Test plan

CI was terminal green at 56675787 (30 checks pass, 12 skipped, 0 failed). The third commit c22f7cbd changes one YAML file and no Go source, so the re-run at the new head is expected to match:

• CI success (lint and unit tests) — includes Go module tidiness (go.mod / go.sum), which re-runs go work sync + go mod tidy per module and fails on any diff
• CI success (DEB package build) — omnibus amd64 and arm64, plus branding verification
• CI success (binary builds) — agent and cluster-agent binaries on amd64 and arm64
• Report-only image scans show the three Go rows gone from all four published image variants

Image rescan results from CI's VEX-aware scan-image action (Trivy vuln + Grype, plus a separate Trivy
secret scan at UNKNOWN,LOW,MEDIUM,HIGH,CRITICAL):

Image variant	Trivy vuln	In-scope	Expired	Unmanaged
agent amd64 / arm64	1 UNKNOWN, 0 HIGH	7	3	4
cluster-agent amd64 / arm64	1 UNKNOWN, 0 HIGH	1	1	0

Zero occurrences of CVE-2026-56855, CVE-2026-78662 or CVE-2026-84304 in any scan log, and zero HIGH
rows anywhere. No secrets detected in image. on every variant. The one UNKNOWN row per variant is
GO-2026-5932 reporting against x/crypto v0.56.0 — the kept openpgp exception, correctly tracking the
new version.

• Next complete dev chart scan confirms the rows clear on republished images (closure evidence for [stackstate-agent] Dev scan 34027081656: bump x/crypto to 0.56.0 and grpc to 1.83.1; krb5 and python rows need a human VEX or exception decision #509 — a merged PR is not)

Note for the reviewer: the scans also surface expired: 3 / expired: 1, naming all four exceptions/
files as expired since 2026-09-04. That predates this PR and is flagged on #509 for
@StackVista/observability-team; it is not introduced or masked here.