CVE-2025-45286: Reflected Cross-Site Scripting in go-httpbin via Unsafe Content-Type Handling

The mccutchen/go-httpbin library is a Go implementation of the popular httpbin service, designed to test HTTP requests and responses. It provides various endpoints that echo back request data, including headers, cookies, and body content. A core feature of httpbin is the ability for the client to dictate the behavior of the server via query parameters, including setting specific response headers.

The vulnerability, tracked as CVE-2025-45286, is a Reflected Cross-Site Scripting (XSS) flaw located in the response generation logic. Specifically, endpoints like /response-headers and /base64 allow a user to define the Content-Type of the HTTP response. In vulnerable versions, the application reflects user input (such as query parameters or decoded path segments) directly into the response body without validation or escaping, even when the user has specified a Content-Type that browsers interpret as executable (e.g., text/html).

This behavior creates a security gap where the server acts as an unwitting host for malicious scripts. Because the response is served from the go-httpbin domain, any script executed via this vector runs within the origin of that domain. This allows attackers to bypass Same-Origin Policy (SOP) protections, potentially accessing sensitive data stored in the browser for that origin.

The root cause of this vulnerability is the lack of context-aware output encoding. The application treats the Content-Type header and the response body as independent variables controlled by the user, without enforcing safety invariants between them.

In a standard XSS scenario, an application accepts input and displays it to the user. If the application fails to escape special characters (like < and >), the browser treats the data as code. go-httpbin is intended to echo data, so strict validation is often counter-productive to its utility as a debugging tool. However, the flaw arises because the application permits the Content-Type to be set to text/html while simultaneously echoing raw JSON or base64-decoded data into the body.

When a browser receives a response with Content-Type: text/html, it parses the body using its HTML parser. If the body contains a JSON object like {"key": "<script>alert(1)</script>"}, the HTML parser encounters the <script> tag and executes it immediately. The application logic did not anticipate that the JSON echo functionality could be weaponized by simply changing the MIME type.

The vulnerability was addressed in commit 0decfd1a2e88d85ca6bfb8a92421653f647cbc04 by introducing a whitelist of safe content types and enforcing HTML escaping for anything else.

Vulnerable Logic (Conceptual): Prior to the patch, the handler for /response-headers simply iterated over the provided query parameters, set them as headers, and then wrote the map to the response body using a JSON encoder.

// Pseudo-code of vulnerable logic
func responseHeaders(w http.ResponseWriter, r *http.Request) {
    // 1. Set headers based on query params
    for k, v := range r.URL.Query() {
        w.Header().Set(k, v[0])
    }
    // 2. Write body directly
    json.NewEncoder(w).Encode(r.URL.Query())
}

Patched Logic: The fix introduces a check mustEscapeResponse(contentType) and a map of safeContentTypes (including application/json, text/plain, etc.). If the requested Content-Type is not in the safe list (e.g., it is text/html), the application now escapes the input before writing it to the body.

// Logic from the fix
var safeContentTypes = map[string]bool{
    "text/plain":               true,
    "application/json":         true,
    "application/octet-string": true,
    // ...
}
 
// In the handler
contentType := w.Header().Get("Content-Type")
if h.mustEscapeResponse(contentType) {
    // Apply HTML escaping to keys and values
    // effectively neutralizing <script> tags into &lt;script&gt;
    encodedKey := html.EscapeString(key)
    encodedVal := html.EscapeString(val)
    // ... write escaped data ...
}

Additionally, the developers added an opt-in flag -unsafe-allow-dangerous-responses for users who rely on the legacy behavior, prioritizing security by default.

Exploiting this vulnerability requires an attacker to trick a victim into visiting a specially crafted URL. The attack vector relies on the reflection of the Content-Type header and the injection of HTML payloads.

Scenario 1: The /response-headers Endpoint The attacker constructs a URL that sets the content type to HTML and injects a script into a dummy parameter.

1. Payload Construction: http://target.com/response-headers?Content-Type=text/html&param=<script>alert(document.domain)</script>
2. Server Processing: The server sets the header Content-Type: text/html. It constructs a JSON body containing the key param and the value <script>alert(document.domain)</script>.
3. Execution: The victim's browser sees the HTML content type, parses the JSON textual representation as HTML, finds the script tag, and executes it.

Scenario 2: The /base64 Endpoint The /base64 endpoint decodes a base64 string from the URL path. This allows for arbitrary binary or text injection.

1. Payload Encoding: The attacker encodes <img src=x onerror=alert(1)> into base64: PGltZyBzcmM9eCBvbmVycm9yPWFsZXJ0KDEpPg==.
2. URL Construction: http://target.com/base64/PGltZyBzcmM9eCBvbmVycm9yPWFsZXJ0KDEpPg==?Content-Type=text/html
3. Execution: The server decodes the base64 string and serves it with the text/html header. The browser renders the image tag and triggers the XSS payload via the onerror event.

The impact of this vulnerability is classified as Medium (CVSS 6.1), primarily because it requires user interaction (UI:R). However, the consequences of successful exploitation in a production environment or an internal development network can be significant.

Confidentiality & Integrity: Since the script executes in the context of the go-httpbin origin, an attacker can access any cookies, local storage, or session tokens associated with that domain. If the httpbin instance is hosted on an internal network (e.g., intranet-tools.corp.local) and accessible without authentication, an attacker could use the victim's browser as a proxy to perform actions on other internal services or exfiltrate internal data.

Scope Change (S:C): The CVSS vector includes Scope: Changed because the vulnerable component (the server) impacts a separate component (the victim's browser/user session). This elevates the severity as the server itself is not the final target, but the vector for attacking client-side trust.