CVE-2026-39825

What it actually does

This flaw affects Go applications that use net/http/httputil ReverseProxy with a Rewrite function, or a Director function that parses query parameters. Go's url.ParseQuery enforces a maximum total query-parameter count controlled by GODEBUG=urlmaxqueryparams=N, but ReverseProxy sanitization does not fully account for that parsing limit. An attacker can send a request with an excessive number of query parameters so that parameters appearing after the parsing limit are not visible to the Rewrite or Director logic, while still being forwarded to the upstream backend. If proxy-side logic uses Rewrite or Director to validate, remove, authorize, route, or audit query parameters, a backend may receive parameters that the proxy code never evaluated.

Why it matters to the business

Applications relying on Go ReverseProxy for request normalization, filtering, authorization decisions, or logging may unintentionally pass attacker-controlled parameters to backend services. The likely impact is limited data exposure or bypass of proxy-side controls, depending on how downstream services interpret query parameters. The CVSS score is moderate and EPSS is low and flat, with no CISA KEV listing or known exploit maturity reported, but organizations with widely deployed Go-based reverse proxies should still treat it as a design-sensitive issue because impact depends heavily on application-specific proxy logic.

How an attack unfolds

An attacker identifies a Go-based reverse proxy endpoint where query parameters influence backend behavior and where the proxy uses Rewrite or Director logic to inspect or remove parameters. The attacker crafts a URL containing a very large number of benign query parameters, exceeding the url.ParseQuery parameter-count limit. They then append a sensitive or disallowed parameter after that limit. When the proxy parses the query for Rewrite or Director handling, the trailing parameter is not visible to that logic. Because ReverseProxy sanitization does not account for the same limit, the request may still be forwarded to the upstream backend with the hidden parameter present. If the backend honors that parameter, the attacker may bypass proxy-enforced filtering or cause unauthorized backend behavior that was not reflected in proxy-side logs or policy checks.

How to fix it

Upgrade Go to a version that includes the vendor fix once an applicable fixed version is available for the affected release line. Because no fixed versions were provided in the advisory input, monitor official Go security releases and rebuild/redeploy all affected Go binaries after updating the toolchain. As an immediate mitigation, reject requests with excessive query-parameter counts before they reach ReverseProxy; configure a conservative maximum query count and maximum request-target length at the edge; normalize and reserialize query strings before forwarding; avoid making security decisions from parsed query parameters if the raw query may still be forwarded; and ensure Rewrite or Director logic explicitly clears or reconstructs the outbound RawQuery from an allowlist of parameters. If GODEBUG=urlmaxqueryparams=N is customized, ensure proxy-side rejection thresholds are lower than or equal to that value.

How to confirm the fix worked

Confirm exposure by reviewing Go services that import or use net/http/httputil.ReverseProxy and implement Rewrite or Director functions that parse, filter, or authorize query parameters. Test in a non-production environment by sending a request containing more query parameters than the configured urlmaxqueryparams limit, followed by a sentinel parameter, and verify that the backend does not receive the sentinel parameter unless it was explicitly allowed by the proxy. Validate mitigations by confirming that oversized query strings receive a 4xx response at the edge or proxy and that outbound requests are built from a canonical allowlist rather than the original raw query. Confirm remediation by rebuilding with a fixed Go release when available and repeating the parameter-overflow test.

Typical attack path

1. Identify an internet-reachable service implemented in Go or fronted by a Go net/http/httputil ReverseProxy.
2. Determine whether query parameters affect backend behavior, routing, authorization, filtering, or data selection.
3. Send test requests with very large numbers of query parameters to infer whether the proxy and backend parse requests differently.
4. Append a target parameter after the query-parameter limit, such as a parameter intended to alter backend output or bypass filtering.
5. Observe whether the backend acts on the hidden parameter even though proxy-side Rewrite or Director logic would not have seen it.
6. Repeat the technique against sensitive endpoints where proxy-side query validation is trusted as a security boundary.

How to detect it

To determine whether exploitation already occurred, analyze raw HTTP access logs from edge load balancers, reverse proxies, application gateways, CDN logs, WAF logs, and backend service logs. Look for requests with extremely long query strings, unusually high counts of ampersands or equals signs, many repeated short parameter names, or query parameter counts near or above the Go urlmaxqueryparams setting, commonly 10000 unless changed. Compare proxy-side logs or security-decision logs with backend logs: suspicious activity may show a backend receiving or acting on a parameter that is absent from proxy parsing, filtering, or audit records. Focus on endpoints where query parameters influence access to data, export/download behavior, debug behavior, tenant or user selection, routing, or filtering. There are no named threat actors, CISA KEV activity, or known mature public exploits in the provided intelligence, so detection should be anomaly- and behavior-based rather than actor-specific.

• regex: \?.*(?:[^&=]{1,64}=[^&]{0,128}&){10000,}[^&=]{1,64}=
• regex: \?.*(?:[A-Za-z][A-Za-z0-9_]{0,8}=x&){1000,}[A-Za-z][A-Za-z0-9_]{0,32}=
• regex: ^.{8000,}\?.*&.*&.*&
• query_parameter_count >= 10000
• GODEBUG=urlmaxqueryparams=

What your security team should do

• Inventory Go applications and reverse proxies using net/http/httputil.ReverseProxy, especially those with custom Rewrite or Director functions.
• Prioritize review of services where query parameters control authorization, data access, backend routing, feature flags, debug modes, export formats, or filtering.
• Add edge or application-level limits for maximum query-string length and maximum number of query parameters; return 400 or 414 for excessive requests.
• Modify proxy code to reconstruct outbound query strings from explicitly approved parameters instead of forwarding the original RawQuery.
• Monitor official Go security advisories for fixed versions and rebuild all affected statically linked Go binaries after upgrading the Go toolchain.
• Search historical logs for requests with unusually high query-parameter counts, very long URLs, or backend-only parameters absent from proxy policy logs.
• Add tests to CI/CD that verify disallowed query parameters are not forwarded when requests exceed parsing limits.