Triage CVE-2026-46600: x/net DoS in the bundled terraform binary

[xerhab]

What's failing

A newly-published HIGH is failing turma-agent-image-scan on every PR that rebuilds the agent image (mine, and anything else that touches agent/ or turma/):

usr/local/bin/terraform (gobinary)
Total: 1 (HIGH: 1, CRITICAL: 0)

golang.org/x/net  CVE-2026-46600  HIGH  fixed  v0.55.0 → 0.56.0
  golang.org/x/net/dns/dnsmessage: Denial of Service via invalid DNS record parsing

It appeared between two runs of the same PR — the earlier scan passed, and Trivy's DB is refetched per run — so it is a new advisory against an unchanged pin, not a regression from any diff.

Why it isn't a version bump

Trivy reports exactly one carrier: /usr/local/bin/terraform, TERRAFORM_VERSION=1.15.8, which compiles in golang.org/x/net v0.55.0. x/net is linked into the binary, so it can't be patched independently.

Checked against HashiCorp's release index today:

1.16.0-rc1              2026-08-12
1.17.0-alpha20260812    2026-08-12
1.16.0-beta2            2026-08-05
…
1.15.8                  2026-07-08   <- newest STABLE

1.15.8 is the latest stable release; everything after it is a 1.16.0 rc/alpha, which doesn't belong in a shipped image. TERRAFORM_VERSION has nothing to bump to — the same position as the three terraform entries already in this file (CVE-2026-27145/-42504, GHSA-hrxh-6v49-42gf, CVE-2026-56852).

Why triage is the right route here

.trivyignore's own header sets the bar — "Only REVIEWED, non-actionable findings belong here, each with a reason" — and this meets it: third-party, not independently patchable, nothing to bump to. .claude/rules/release.md says the same ("Non-actionable upstream base-image findings go in the root .trivyignore").

The blast radius is a DoS of a single terraform invocation a session runs by hand. Nothing in this image parses DNS responses from a resolver the operator didn't already choose, and terraform is developer tooling here, not a network-facing runtime surface.

The entry carries exp:2026-10-25, matching the most recent batch, so it re-fails and forces a revisit rather than muting the finding permanently. The first stable terraform built against x/net 0.56+ clears it with a pin bump.

Why this is its own PR

It's blocking every PR in the repo, not just the one I hit it on, and a suppression on a security gate should be reviewable on its own rather than buried in a feature diff. Found while getting XERK-265 (#434) green; that PR needs this to merge first.

Verification

.trivyignore is in turma-agent-image-scan.yml's path filter, so this PR runs the very scan it's fixing — a green scan here is the verification. One line of triage plus its rationale; no code, no runtime surface.