CVE-2024-45258: Go req Package Unintended Request Flaw

CVE-2024-45258 Overview

CVE-2024-45258 affects the req HTTP client package for Go before version 3.43.4. The vulnerability stems from a cleanHost function in http.go that intentionally implements a "garbage in, garbage out" design when processing malformed URLs. As a result, the library may send unintended requests when given malformed host input. This input validation weakness ([CWE-20]) can be abused for HTTP request smuggling, host header injection, or routing requests to unintended destinations.

Critical Impact
A network-reachable attacker who can influence URL or Host header input to an application using req can trigger requests to unintended hosts, enabling request smuggling and SSRF-style attack paths without authentication or user interaction.

Affected Products

github.com/imroc/req/v3 Go module versions prior to 3.43.4
Go applications and services that pass user-influenced URLs or Host values to the req HTTP client
Downstream tools and microservices embedding vulnerable req releases as a transitive dependency

Discovery Timeline

2024-08-25 - CVE-2024-45258 published to NVD
2026-04-15 - Last updated in NVD database

Technical Details for CVE-2024-45258

Vulnerability Analysis

The req package built its request pipeline on a cleanHost helper that stripped characters from a malformed host string instead of rejecting it. When an application supplied a URL containing unexpected characters in the host component, cleanHost returned a sanitized substring that the client then used to issue a request. The downstream server saw a valid-looking request even though the original input was malformed.

This design lets an attacker craft input that the validator parses as one host while req dispatches the request to another. The behavior maps to classic input validation weaknesses tracked under [CWE-20]. Because the flaw lives in the HTTP transport layer of a popular Go library, every consumer that proxies user input into req.Get, req.Post, or related calls inherits the risk.

Root Cause

The root cause is the deliberate cleanHost truncation logic in http.go and transport.go. Historically, the function truncated the Host header at / or space characters to convert irregular inputs into a tolerable form. That truncation silently transforms attacker-controlled input into a usable host value, opening a header smuggling vector.

Attack Vector

An attacker supplies a malformed URL such that the host component contains delimiter characters. The vulnerable cleanHost extracts a host substring that differs from what the application's own validators inspected. The request then reaches an unintended endpoint, potentially exposing internal services or smuggling headers past upstream proxies.

// Patch in transport.go - removes cleanHost and adds strict validation
// is not given, use the host from the request URL.
//
// Clean the host, in case it arrives with unexpected stuff in it.
-host := cleanHost(r.Host)
+host := r.Host
if host == "" {
    if r.URL == nil {
        return errMissingHost
    }
-   host = cleanHost(r.URL.Host)
+   host = r.URL.Host
+}
+host, err = httpguts.PunycodeHostPort(host)
+if err != nil {
+    return err
+}
+
+// Validate that the Host header is a valid header in general,
+// but don't validate the host itself. This is sufficient to avoid
+// header or request smuggling via the Host field.
+if !httpguts.ValidHostHeader(host) {
+    // Historically, we would truncate the Host header after '/' or ' '.
+    // We don't preserve the truncation, because sending an altered
+    // header field opens a smuggling vector.

Source: GitHub Commit 04e3ece

Detection Methods for CVE-2024-45258

Indicators of Compromise

Outbound HTTP requests from Go services to hostnames that do not appear in application configuration or allow-lists
Application logs showing accepted URLs containing whitespace, /, or control characters in the host component
Discrepancies between the host value logged by the application and the host recorded by upstream proxies or egress firewalls

Detection Strategies

Inventory Go modules using go list -m all and flag any project pinned to github.com/imroc/req/v3 below v3.43.4
Scan source repositories and container images with software composition analysis tools that consume Go module metadata
Capture egress traffic from services using req and alert on requests where the SNI or HTTP Host header differs from the URL the application logged

Monitoring Recommendations

Enable verbose request logging in req-based services and forward logs to a SIEM for host-mismatch correlation
Monitor proxy and load balancer logs for malformed Host header values reaching internal endpoints
Track new outbound destinations from application workloads and treat unexpected internal targets as SSRF candidates

How to Mitigate CVE-2024-45258

Immediate Actions Required

Upgrade github.com/imroc/req/v3 to v3.43.4 or later across all Go projects and rebuild dependent binaries
Audit application code for places where user input flows into req request URLs and add explicit host allow-listing
Rotate any secrets that could have leaked through unintended outbound requests if the service handled credentials in headers

Patch Information

The maintainers fixed the issue in commit 04e3ece5b380ecad9da3551c449f1b8a9aa76d3d, released as version v3.43.4. The patch removes the cleanHost truncation and replaces it with httpguts.PunycodeHostPort plus httpguts.ValidHostHeader checks, rejecting malformed hosts instead of silently rewriting them. Review the GitHub Version Comparison for the full diff.

Workarounds

Validate and normalize URLs with net/url before passing them to req, rejecting any host containing whitespace or path separators
Place vulnerable services behind an egress proxy that enforces a strict destination allow-list
Wrap req clients with middleware that re-parses the final request URL and aborts on host mismatch

bash

# Pin the fixed release in go.mod
go get github.com/imroc/req/v3@v3.43.4
go mod tidy
go build ./...