The TIFF decoder can panic when decoding an invalid image with an out-of-bounds strip offset

CVE-2026-46604 is a panic in the TIFF decoder of golang.org/x/image — a supplementary Go imaging package, not the standard library. A crafted TIFF with an out-of-bounds strip offset trips an unchecked slice index inside tiff.Decode, and the goroutine panics with runtime error: slice bounds out of range. The bug affects every release of golang.org/x/image prior to 0.43.0; the fix landed in CL 788421 and ships as GO-2026-5066. Reporter credit: *sorte*.

Vendor severity here is the Go security team's standard CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H — which is mechanically correct (the panic is unauthenticated, network-triggerable in some apps, and is *availability* impact) but practitionally misleading. There is no memory disclosure, no code execution, no integrity impact. The damage ceiling is whatever the panicking process was doing — and in Go, a panic on a per-request goroutine inside an http.Handler is recovered by net/http's default serverHandler. Real-world blast radius is much narrower than 7.5 implies.

Why this verdict

• Availability-only impact: vector explicitly says C:N/I:N/A:H. There is no RCE, no information leak, no privilege escalation — the worst case is a panic.
• net/http panic recovery: the default Go HTTP server recovers per-request panics, so the most common deployment shape (an HTTP handler that decodes uploads) degrades to a logged 500 rather than a process crash.
• Narrow library footprint: golang.org/x/image/tiff is opt-in. Stdlib JPEG/PNG/GIF/WebP decoders are unaffected. Most image-handling Go services never import this package.
• Role multiplier (workstation/dev sandbox): non-applicable — this is a library, not a deployment role. No fleet-scale identity, hypervisor, CI/CD, or kernel-mode amplifier exists.
• Role multiplier (typical app server): panic is contained per-request by net/http recovery; outcome is a single failed request. Floor stays MEDIUM at worst.
• Role multiplier (background worker / gRPC streaming server / queue consumer): chain succeeds — these contexts often lack recover() and a sustained malformed-TIFF stream can crash-loop the worker. Blast radius is host-level service outage, not fleet compromise. Floor remains MEDIUM; does not lift to HIGH because remediation is a single go get and there is no privilege escalation.
• EPSS 0.17% and no KEV listing confirm the realistic-exploit picture: low priority by external telemetry.

Why not higher?

HIGH (7.0+) would require either a real path to RCE, information disclosure, or a deployment role with fleet-scale blast radius. None apply: the bug is a slice-bounds panic, the panic is recoverable, and the affected library is not canonically deployed in identity, hypervisor, CI/CD, backup, or kernel-mode roles. A process crash is real, but it is recoverable in seconds and does not pivot to other assets.

Why not lower?

LOW (≤3.9) would require either no realistic reachability or trivial built-in mitigation. The bug is reachable from unauthenticated network requests on services that accept TIFFs, and not every Go process is wrapped in net/http panic recovery — gRPC servers, queue workers, and CLI batch jobs can be crashed outright. Sustained DoS against a critical ingest pipeline is a real operational risk, so MEDIUM is the honest floor.

1. Run govulncheck across your Go fleet to find binaries that reach tiff.Decode — govulncheck ./... does symbol-level reachability analysis — it tells you which of your services actually import and call the vulnerable function, not just which ones import the module. Prioritize the reachable set. Per noisgate MEDIUM SLA there is no mitigation deadline; complete this inventory within the 365-day remediation window, but front-load it in the first 30 days while triage attention is still on this CVE.
2. Add a TIFF MIME-type denylist at the upload gateway — If your application has no business reason to accept TIFFs (most don't), reject image/tiff, image/tif, and content-sniff for the II*\0 / MM\0* magic bytes at the WAF/API gateway. This is a one-line change in Envoy/Kong/Cloudflare and neutralizes the bug regardless of whether the underlying library is patched. Apply within 30 days as a defensive hygiene step.
3. Wrap decode calls in defer recover() for non-HTTP contexts — gRPC streaming handlers, queue consumers (NATS, Kafka, SQS workers), and CLI batch jobs do not get net/http's automatic panic recovery. Audit every tiff.Decode call site in a non-HTTP context and add a defer func() { if r := recover(); r != nil { ... } }() block. Apply within 30 days as defense-in-depth.
4. Pin and bump golang.org/x/image to ≥ 0.43.0 — The fix is in version 0.43.0. Use go get golang.org/x/[email protected] && go mod tidy, rebuild, and ship. Stage through your normal release pipeline within the noisgate remediation SLA of 365 days for MEDIUM — but most shops will roll this with the next routine dependency bump.

Run on a CI worker or developer workstation with the Go toolchain installed and your project checked out. Invoke from the repo root: bash check-cve-2026-46604.sh ./.... No elevated privileges required. The script uses govulncheck for symbol-level reachability and falls back to go list -m for dependency-graph detection.

#!/usr/bin/env bash
# check-cve-2026-46604.sh — detect vulnerable golang.org/x/image TIFF decoder
# Usage: bash check-cve-2026-46604.sh [go-package-spec, default ./...]
set -u

TARGET="${1:-./...}"
FIXED_VERSION="v0.43.0"
MODULE="golang.org/x/image"

if ! command -v go >/dev/null 2>&1; then
  echo "UNKNOWN: go toolchain not found" >&2
  exit 2
fi

if ! [ -f go.mod ]; then
  echo "UNKNOWN: no go.mod in current directory" >&2
  exit 2
fi

# 1. Check resolved dependency version
VERSION=$(go list -m -f '{{.Version}}' "$MODULE" 2>/dev/null || true)
if [ -z "$VERSION" ]; then
  echo "PATCHED: module $MODULE is not in the dependency graph"
  exit 0
fi

# 2. Numeric compare against fixed version
LOWEST=$(printf '%s\n%s\n' "$VERSION" "$FIXED_VERSION" | sort -V | head -n1)
if [ "$LOWEST" = "$FIXED_VERSION" ] && [ "$VERSION" != "$FIXED_VERSION" ]; then
  STATE="PATCHED"  # version is >= fixed
elif [ "$VERSION" = "$FIXED_VERSION" ]; then
  STATE="PATCHED"
else
  STATE="VULNERABLE"
fi

# 3. Symbol-level reachability via govulncheck (if installed)
if command -v govulncheck >/dev/null 2>&1; then
  if govulncheck "$TARGET" 2>/dev/null | grep -q "GO-2026-5066\|CVE-2026-46604"; then
    echo "VULNERABLE: $MODULE@$VERSION — tiff.Decode is reachable (govulncheck)"
    exit 1
  fi
fi

if [ "$STATE" = "VULNERABLE" ]; then
  echo "VULNERABLE: $MODULE@$VERSION < $FIXED_VERSION (reachability not confirmed; install govulncheck for symbol check)"
  exit 1
fi

echo "PATCHED: $MODULE@$VERSION >= $FIXED_VERSION"
exit 0

Sources

1. Go vulnerability database — GO-2026-5066
2. Go fix commit — CL 788421
3. Go issue tracker — go.dev/issue/80122
4. NVD — CVE-2026-46604
5. CVE record — cve.org
6. ThreatINT CVE summary
7. govulncheck reference
8. golang.org/x/image module