AI Security Summary
Go's network and cryptographic libraries form the dominant attack surface, spanning HTTP/2, SSH, HTML parsing, and CORS. The recurring coding mistake is trusting unvalidated or loosely parsed protocol inputs — headers, origin strings, SSH callbacks, and IP addresses — without enforcing strict boundary checks.
HTTP/2 and HTTP Protocol Abuse via Stream and Header Manipulation
Covers: CVE-2022-41721 · CVE-2022-41723 · CVE-2023-39325 · CVE-2023-44487 · CVE-2023-45288 Risk: Attackers exploit HTTP/2 stream resets, CONTINUATION frames, and unconsumed request bodies to exhaust server CPU or memory; CVE-2023-44487 is ACTIVELY EXPLOITED.
- ALWAYS set explicit and conservative limits on HTTP/2 header size, concurrent streams, and frame counts at the server configuration layer.
- NEVER rely on MaxBytesHandler alone to fully consume or terminate a request body before handing off the connection for further protocol reads.
- ALWAYS ensure HTTP/2 server handlers drain or cancel streams promptly to prevent rapid-reset abuse from accumulating in-flight work.
- NEVER allow unbounded HPACK decoder processing of attacker-controlled header streams without a hard CPU or allocation budget.
- ALWAYS treat an unusual volume of RST_STREAM or CONTINUATION frames from a single client as a signal to close the connection.
SSH Trust Boundary Violations and Cryptographic Handshake Attacks
Covers: CVE-2017-3204 · CVE-2023-48795 · CVE-2024-45337 · CVE-2025-22869 · CVE-2025-47914 · CVE-2025-58181 Risk: SSH misconfigurations — missing host key verification, unenforced key exchange timeouts, and unbounded GSSAPI or agent message parsing — let attackers hijack sessions, truncate secure channels, or exhaust server memory.
- NEVER leave ClientConfig.HostKeyCallback unset or assigned a no-op; always register an explicit, verified host key check before opening an SSH connection.
- NEVER treat a successful PublicKeyCallback invocation as proof of authentication; always confirm the key was actually used to complete the SSH handshake.
- ALWAYS enforce a strict deadline on SSH key exchange completion to prevent slow or stalled clients from pinning server-side memory indefinitely.
- ALWAYS validate the declared length and count fields in SSH agent and GSSAPI messages before allocating memory or reading further into the message buffer.
- NEVER accept SSH session negotiation that downgrades to cipher modes lacking sequence-number integrity, as these are vulnerable to prefix truncation.
IP Address and Origin String Parsing Bypass
Covers: CVE-2019-25211 · CVE-2024-24790 · CVE-2025-22870 Risk: Flawed parsing of IPv4-mapped IPv6 addresses, wildcard CORS origins, and IPv6 zone IDs lets attackers bypass IP allowlists, SSRF defenses, and proxy exclusion rules.
- NEVER use stdlib IP classification functions to gate SSRF-sensitive operations without independently normalizing and re-validating IPv4-mapped IPv6 representations.
- NEVER treat a wildcard suffix in a CORS origin allowlist as an exact domain anchor; always match the full scheme, host, and port against an explicit allowlist.
- ALWAYS strip or reject IPv6 zone ID components before matching a host against any security-relevant allowlist or proxy bypass rule.
- NEVER conflate loopback/private classification with security authorization; perform an independent, canonical address comparison for every trust decision.
HTML and JWT Token Parsing Leading to XSS and Memory Exhaustion
Covers: CVE-2018-17846 · CVE-2023-3978 · CVE-2023-26125 · CVE-2025-22872 · CVE-2025-30204 Risk: Malformed HTML tokens, unescaped text nodes, and oversized JWT Authorization headers can trigger infinite parsing loops, XSS injection, or server-side memory exhaustion.
- NEVER pass attacker-controlled HTML to a parser without enforcing a maximum input size and a parse-time CPU budget; infinite loops are reachable from crafted tag sequences.
- ALWAYS treat the output of x/net/html tokenization as untrusted until escape status has been independently verified, especially for text nodes outside the HTML namespace.
- NEVER split or allocate from untrusted token strings — such as JWT Authorization headers — without first enforcing a strict maximum length on the raw input.
- ALWAYS validate that self-closing tag interpretation in the HTML tokenizer matches your expected DOM scope, particularly for tags with unquoted solidus-terminated attributes.
HTTP Header Injection and Response Manipulation via Framework Input Handling
Covers: CVE-2023-29401 · CVE-2025-22870 Risk: Unsanitized filename and forwarded-prefix headers in Gin allow attackers to inject arbitrary Content-Disposition values or poison caches through header manipulation.
- NEVER pass user-supplied strings directly into Content-Disposition or other response headers without stripping all control characters, quotes, and semicolons.
- ALWAYS treat X-Forwarded-* and similar hop-by-hop headers as untrusted input that must be validated against an explicit allowlist before use in routing or caching logic.
- NEVER construct header field values by concatenating user input; always use structured header-building APIs that enforce RFC-compliant encoding.
Cross-cutting patterns (all Go projects)
- NEVER assume that a Go stdlib or x/ package function correctly classifies or sanitizes security-sensitive protocol values without independent validation at your application's trust boundary.
- ALWAYS apply an explicit, finite resource budget (time, memory, CPU) to every operation that processes attacker-supplied protocol data before any business logic executes.
- NEVER use default or zero-value configuration for security-critical callback fields such as host key verification or public key authentication; always provide an explicit, rejecting default.
- ALWAYS perform allowlist-based validation on any value that will influence routing, proxy selection, or origin trust, using canonicalized forms rather than raw input strings.