When a server is configured to support unencrypted HTTP/2

CVE-2026-56853 is a resource-exhaustion flaw in Go's net/http standard library. When a server explicitly enables unencrypted HTTP/2 (h2c) via Server.Protocols.SetUnencryptedHTTP2(true), the server peeks at the first bytes of every inbound connection to detect the HTTP/2 client connection preface. That initial read was not governed by ReadHeaderTimeout, so a malicious client could open a TCP connection, send zero bytes, and hold that connection open forever. Repeat this thousands of times and the server's file-descriptor or goroutine pool is exhausted — classic Slowloris-style denial of service. Affected versions: Go < 1.25.13, Go 1.26.0–1.26.5, and Go 1.27.0-0 pre-releases. Fixed in Go 1.25.13, Go 1.26.6, and Go 1.27.0-rc.3.

The vendor CVSS of 7.5 HIGH is technically correct for the narrow scenario where h2c is enabled and the server is directly reachable — unauthenticated, network-accessible, low complexity, availability-only impact. But it overstates real-world risk significantly. h2c is not enabled by default in Go's net/http; it requires an explicit opt-in added in Go 1.24 (mid-2025). The vast majority of Go HTTP servers in production terminate TLS at the server or sit behind a TLS-terminating reverse proxy, neither of which triggers this code path. Even when h2c *is* enabled — typically behind a load balancer for gRPC backends or Cloud Run — the load balancer itself enforces idle timeouts that cap the Slowloris window. The impact ceiling is service availability disruption, not data compromise or code execution.

1. Disable h2c if not required — If your Go services do not need cleartext HTTP/2, ensure UnencryptedHTTP2 is not set in Server.Protocols. This eliminates the vulnerable code path entirely. No noisgate mitigation SLA applies at MEDIUM — go straight to the 365-day remediation window for the Go upgrade.
2. Enforce idle-connection timeouts at the load balancer — Configure your reverse proxy or load balancer (NGINX, Envoy, HAProxy, cloud LB) to enforce an idle timeout of 60–120 seconds on backend connections. This caps the Slowloris window regardless of the Go bug.
3. Set OS-level connection limits — Use ulimit -n and sysctl net.core.somaxconn to cap the maximum number of open file descriptors per process. This provides a hard ceiling on resource exhaustion and forces connection recycling.
4. Monitor goroutine count — Add alerting on go_goroutines (Prometheus) or runtime.NumGoroutine(). A spike in goroutines with zero active requests is a reliable signal of idle-connection abuse. Alert at 2× your baseline p99.
5. Upgrade Go runtime to 1.25.13 / 1.26.6 / 1.27.0+ — The definitive fix. Rebuild and redeploy your Go binaries against a patched Go toolchain. Under the noisgate remediation SLA for MEDIUM, complete this within 365 days. Prioritize services that directly expose h2c to untrusted networks.

Run on or from any host where the target Go service is reachable. Pass the target's h2c endpoint as an argument: bash check_cve_2026_56853.sh myservice.internal:8080. Requires curl (≥7.86 for --http2-prior-knowledge) and go version if checking locally. No elevated privileges needed.

#!/usr/bin/env bash
# check_cve_2026_56853.sh — Detect CVE-2026-56853 exposure
# Tests whether a Go HTTP server accepts h2c AND holds idle connections
# Usage: bash check_cve_2026_56853.sh <host:port> [timeout_seconds]
# Exit codes: 0=VULNERABLE, 1=PATCHED, 2=UNKNOWN

set -euo pipefail

TARGET="${1:-}"
TIMEOUT="${2:-10}"

if [[ -z "$TARGET" ]]; then
  echo "Usage: $0 <host:port> [timeout_seconds]"
  exit 2
fi

echo "[*] Testing h2c support on $TARGET ..."

# Step 1: Check if the server accepts h2c at all
H2C_CHECK=$(curl -s -o /dev/null -w '%{http_version}' \
  --http2-prior-knowledge \
  --max-time 5 \
  "http://$TARGET/" 2>/dev/null || true)

if [[ "$H2C_CHECK" != "2" ]]; then
  echo "PATCHED — Server does not accept unencrypted HTTP/2 (h2c). Not vulnerable."
  exit 1
fi

echo "[*] Server accepts h2c. Testing idle connection hold ..."

# Step 2: Open a raw TCP connection, send nothing, see if it stays open
# beyond the expected ReadHeaderTimeout window
# We use bash /dev/tcp or nc to hold an idle connection
START=$(date +%s)
if command -v nc &>/dev/null; then
  timeout "$TIMEOUT" nc -w "$TIMEOUT" "${TARGET%%:*}" "${TARGET##*:}" </dev/null >/dev/null 2>&1 &
  NC_PID=$!
  sleep "$TIMEOUT"
  if kill -0 "$NC_PID" 2>/dev/null; then
    kill "$NC_PID" 2>/dev/null || true
    HELD=true
  else
    wait "$NC_PID" 2>/dev/null || true
    HELD=false
  fi
else
  echo "[!] nc (netcat) not found. Install netcat for idle-connection test."
  echo "UNKNOWN — Could not complete idle connection test."
  exit 2
fi

END=$(date +%s)
DURATION=$((END - START))

if [[ "$HELD" == "true" && "$DURATION" -ge "$TIMEOUT" ]]; then
  echo "VULNERABLE — Server held idle h2c connection for ${DURATION}s with no data sent."
  echo "CVE-2026-56853: ReadHeaderTimeout not applied during h2c preface check."
  exit 0
else
  echo "PATCHED — Server closed idle connection within ${DURATION}s. ReadHeaderTimeout appears enforced."
  exit 1
fi

1. Go Security Announcement — Go 1.26.6 / 1.25.13
2. golang/go#80205 — Issue Tracker
3. OSV — BIT-golang-2026-56853
4. KrakenD Security Advisory — CVE-2026-56853
5. Go CL 795540 — Fix Patch
6. OpenCVE — CVE-2026-56853
7. Red Hat RHSA-2026:68335
8. Go h2c Deprecation Discussion — golang/go#72039