In Go's crypto/x509, (*x509.Certificate).VerifyHostname used to re-split the same input hostname for every DNS SAN entry it checked. That turns certificate validation into avoidable CPU work when a certificate carries a large DNS SAN list, and the cost lands *before* chain building, so even an otherwise untrusted certificate can trigger it. Supported fixed releases are go1.25.11 and go1.26.4; on supported branches, treat anything earlier than those as affected. Older unsupported branches likely inherited the same code path, but Go's current release stream only documents fixes on 1.25 and 1.26.

There is no vendor CVSS baseline here, so this is ASSESSED AT LOW rather than upgraded or downgraded. The technical trigger is real, but the practical attack surface is narrow: this is mostly a *client-side* outbound TLS problem, the attacker usually needs control of the server certificate on a destination the victim already contacts, and the impact is CPU burn / latency / connection degradation rather than code execution, auth bypass, or data theft.

Why this verdict

• Attacker position pushes this down: this is mostly an *outbound client-side* TLS verification bug, so the attacker generally must control the destination service or otherwise steer the victim to an attacker-controlled TLS endpoint.
• Impact is availability-only: the bug burns CPU during hostname validation; it does not let the attacker forge trust, bypass hostname checks, read data, or run code.
• Reachable population is narrower than Go's install base: Go is widespread, but only the subset doing vulnerable hostname validation against attacker-influenced endpoints is realistically exposed.
• A prior-compromise or influence stage is often implied: internal service discovery poisoning, SSRF, redirect abuse, malicious webhooks, or tricking clients into new outbound destinations are common prerequisites in enterprise reality.
• Modern controls can break the chain early: egress allowlisting, outbound proxy policy, strict destination pinning, and connection timeouts all reduce the exploit path before the stdlib bug matters.
• Detection is poor but exploit economics are mediocre: scanners will miss it, but attackers also get only a bounded CPU tax rather than a durable foothold.

Why not higher?

This is not an unauthenticated internet-facing server RCE, auth bypass, or direct confidentiality event. The attacker usually needs the victim to connect outward to a hostile TLS endpoint, and even then the practical result is performance degradation rather than a clean security boundary break.

Why not lower?

It is still a real security fix, not just a cosmetic optimization: untrusted certificates can trigger the extra work before chain validation finishes. In environments with many Go clients making attacker-influenced outbound TLS connections, repeated handshakes can turn this into measurable operational pain.

1. Clamp outbound destinations — Enforce egress allowlists or proxy-based destination control so Go clients cannot be pointed at arbitrary TLS endpoints. For a LOW verdict there is no SLA clock here, but put this into normal control hardening and apply it during the next routine policy refresh.
2. Bound handshake cost — Set conservative dial, TLS handshake, and request timeouts on Go clients and reverse proxies so certificate-validation stalls cannot pile up into worker exhaustion. For LOW, roll this into standard engineering backlog hygiene rather than an emergency change.
3. Inventory linked Go binaries — Use go version -m or SBOM tooling to identify binaries built with go1.25.10/earlier on the 1.25 line and go1.26.3/earlier on the 1.26 line. This is the fastest way to separate truly exposed assets from noise.
4. Reject absurd host inputs in app code — If your application accepts user-supplied hostnames before making outbound TLS connections, enforce sane hostname length and label-count checks before those values ever reach Go's verifier. That shrinks the worst-case path even before the toolchain update lands.

Run this on the target host or in CI against the actual deployed Go binaries, not just the build runner. Invoke it as ./check-cve-2026-27145.sh /opt/app/bin/service or with multiple binaries; if you pass no arguments it falls back to the locally installed go toolchain. No root is required, but you need read access to the binaries and go in PATH if you want the fallback check.

#!/usr/bin/env bash
# check-cve-2026-27145.sh
# Determine likely exposure to CVE-2026-27145 in Go binaries/toolchains.
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / usage / cannot determine

set -u

status=0
saw_unknown=0

extract_go_version() {
  local target="$1"
  local out ver
  out=$(go version -m "$target" 2>/dev/null | head -n1) || return 1
  ver=$(printf '%s\n' "$out" | awk '{print $2}')
  [ -n "$ver" ] || return 1
  printf '%s\n' "$ver"
}

extract_local_toolchain() {
  local out ver
  out=$(go version 2>/dev/null) || return 1
  ver=$(printf '%s\n' "$out" | awk '{print $3}')
  [ -n "$ver" ] || return 1
  printf '%s\n' "$ver"
}

classify_version() {
  local ver="$1"
  local clean major minor patch rest

  clean="${ver#go}"
  clean="${clean%%[- ]*}"

  case "$clean" in
    devel*|tip*)
      echo "UNKNOWN"
      return 0
      ;;
  esac

  IFS='.' read -r major minor patch rest <<EOF
$clean
EOF

  if ! [[ "$major" =~ ^[0-9]+$ && "$minor" =~ ^[0-9]+$ ]]; then
    echo "UNKNOWN"
    return 0
  fi

  if ! [[ "${patch:-}" =~ ^[0-9]+$ ]]; then
    patch=0
  fi

  # Supported fixed releases documented by Go:
  #   1.25.11+
  #   1.26.4+
  # Assume newer branches carry the fix.
  if (( major > 1 )); then
    echo "PATCHED"
    return 0
  fi

  if (( major < 1 )); then
    echo "UNKNOWN"
    return 0
  fi

  if (( minor >= 27 )); then
    echo "PATCHED"
    return 0
  fi

  if (( minor == 26 )); then
    if (( patch >= 4 )); then
      echo "PATCHED"
    else
      echo "VULNERABLE"
    fi
    return 0
  fi

  if (( minor == 25 )); then
    if (( patch >= 11 )); then
      echo "PATCHED"
    else
      echo "VULNERABLE"
    fi
    return 0
  fi

  # Older/EOL lines are not covered by the current supported-branch advisory.
  # They may still contain the bug, but we avoid guessing.
  echo "UNKNOWN"
}

report_one() {
  local label="$1"
  local ver="$2"
  local verdict
  verdict=$(classify_version "$ver")
  printf '%s: %s (%s)\n' "$label" "$verdict" "$ver"

  case "$verdict" in
    VULNERABLE)
      status=1
      ;;
    UNKNOWN)
      saw_unknown=1
      ;;
  esac
}

if [ "$#" -gt 0 ]; then
  if ! command -v go >/dev/null 2>&1; then
    echo "UNKNOWN: 'go' command not found; cannot inspect binaries with go version -m"
    exit 2
  fi

  for bin in "$@"; do
    if [ ! -r "$bin" ]; then
      echo "$bin: UNKNOWN (file not readable)"
      saw_unknown=1
      continue
    fi

    ver=$(extract_go_version "$bin")
    if [ -z "${ver:-}" ]; then
      echo "$bin: UNKNOWN (not a Go binary with embedded build info, or stripped beyond inspection)"
      saw_unknown=1
      continue
    fi

    report_one "$bin" "$ver"
  done
else
  ver=$(extract_local_toolchain)
  if [ -z "${ver:-}" ]; then
    echo "UNKNOWN: local Go toolchain not found"
    exit 2
  fi
  report_one "local-go-toolchain" "$ver"
fi

if [ "$status" -eq 1 ]; then
  exit 1
fi

if [ "$saw_unknown" -eq 1 ]; then
  exit 2
fi

exit 0

Sources

1. Go release history
2. Go issue #79694 - root security issue
3. Go issue #79701 - 1.26 backport
4. Go 1.25.11 cherry-pick issue query
5. Go 1.26.4 cherry-pick issue query
6. Go `crypto/x509` package docs
7. CISA Known Exploited Vulnerabilities Catalog
8. FIRST EPSS data documentation