CVE-2025-45286: Reflected Cross-Site Scripting in go-httpbin via Unrestricted Content-Type Headers

The go-httpbin library is a Go-based implementation of the httpbin service, widely utilized by developers for testing HTTP requests, debugging webhooks, and simulating various server responses. Versions of this library prior to v2.18.0 contain a Reflected Cross-Site Scripting (XSS) vulnerability tracked as CVE-2025-45286. The vulnerability specifically affects endpoints designed to echo client data or manipulate response formatting based on query parameters.

The core issue resides in the application's failure to neutralize script-related HTML tags before returning them in HTTP responses. This weakness is formally classified as CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page. The application inherently trusts client-provided input to define critical response headers, bypassing standard security boundaries established by modern web browsers.

When deployed in environments where the go-httpbin service shares an origin with sensitive applications, or when used in targeted phishing campaigns, this vulnerability exposes clients to script execution attacks. The vulnerability carries a CVSS 3.1 base score of 6.1, reflecting a medium severity rating due to the requirement for user interaction prior to exploitation.

The vulnerability manifests due to a confluence of two distinct design choices in the go-httpbin application. First, specific endpoints permit the client to arbitrarily define the Content-Type header of the HTTP response via query parameters. Second, these same endpoints reflect user-controlled data directly into the HTTP response body without applying appropriate output encoding or sanitization.

The /response-headers endpoint serves as a primary example of this mechanical failure. The endpoint is designed to take query parameters and echo them back as HTTP response headers, while simultaneously returning a JSON representation of those headers in the response body. If an attacker supplies a Content-Type query parameter with the value text/html, the application sets the corresponding response header directly.

The application then constructs a JSON object containing the echoed parameters and writes it to the response stream. Because the response header dictates a text/html MIME type, the receiving web browser parses the JSON body as an HTML document. If the JSON payload contains HTML tags or JavaScript, the browser executes those instructions within the origin's context.

The /base64 endpoint presents a similar architectural flaw. This endpoint accepts a base64-encoded string within the URL path, decodes it, and returns the raw bytes. The endpoint also accepts a content-type query parameter to dictate the response MIME type. By encoding a malicious payload and forcing an HTML content type, an attacker guarantees script execution upon URL visitation.

The remediation applied in version v2.18.0 fundamentally alters the trust model for dynamic response generation. The patch, introduced in commit 0decfd1a2e88d85ca6bfb8a92421653f647cbc04, transitions the application from a permissive model to a default-deny architecture. This architecture evaluates requested content types against a strict whitelist before trusting the output formatting.

// Conceptual representation of the patch logic applied in v2.18.0
func handleResponse(w http.ResponseWriter, requestedType string, body string) {
    safeTypes := map[string]bool{
        "text/plain": true,
        "application/json": true,
        "application/octet-stream": true,
    }
 
    if safeTypes[requestedType] {
        w.Header().Set("Content-Type", requestedType)
        w.Write([]byte(body))
        return
    }
 
    // Fallback for dangerous or unknown content types
    w.Header().Set("Content-Type", "text/html; charset=utf-8")
    safeBody := html.EscapeString(body)
    w.Write([]byte(safeBody))
}

The developers implemented an explicit whitelist containing only intrinsically safe MIME types: text/plain, application/json, and application/octet-stream. When a client requests a Content-Type that falls outside this predefined list, the application intercepts the response construction phase. The application subsequently processes the reflected output through the Go standard library's html.EscapeString() function.

This sanitization function replaces sensitive HTML characters with their corresponding safe HTML entities. For example, the < character becomes <, neutralizing any attempt to initiate an HTML tag. To maintain backward compatibility for specialized testing scenarios, the maintainers introduced the UNSAFE_ALLOW_DANGEROUS_RESPONSES environment variable. When explicitly enabled, this flag bypasses the whitelist and sanitization routines, restoring the legacy vulnerable behavior.

Exploiting CVE-2025-45286 requires the attacker to construct a specialized URL and deliver it to a target user. The attack methodology relies on social engineering or secondary injection vectors to coerce the victim's browser into initiating an HTTP GET request to the vulnerable go-httpbin instance. No authentication is required to interact with the vulnerable endpoints.

For the /response-headers endpoint, the attacker constructs a query string containing the target Content-Type and a secondary parameter carrying the malicious payload. The following proof-of-concept demonstrates this specific vector.

GET /response-headers?Content-Type=text/html&xss=<script>alert('CVE-2025-45286')</script>

Upon receiving this request, the server responds with a Content-Type: text/html header. The response body contains the JSON representation of the query parameters, including the unescaped script tag. The browser processes the entire JSON string as HTML, locates the script tags, and executes the contained JavaScript code.

The /base64 endpoint requires an encoding step prior to payload delivery. The attacker generates an HTML payload, such as <img src=x onerror=alert(1)>, and encodes it to PGltZyBzcmM9eCBvbmVycm9yPWFsZXJ0KDEpPg==. The attacker appends this encoded string to the URL path and specifies the content type via query parameters.

GET /base64/PGltZyBzcmM9eCBvbmVycm9yPWFsZXJ0KDEpPg==?content-type=text/html

The execution of arbitrary JavaScript within the victim's browser session constitutes the primary security impact of this vulnerability. The script executes within the context of the domain hosting the go-httpbin application. If the application is hosted on a shared domain alongside sensitive administrative interfaces or internal services, the attacker gains the ability to interact with those services under the guise of the authenticated victim.

The attacker leverages this execution context to exfiltrate session tokens, manipulate client-side application states, or force the user's browser to issue unauthorized API requests. This technique, commonly documented as Cross-Site Request Forgery via XSS, circumvents standard anti-CSRF protections because the attacker's script operates from within the trusted origin.

The Common Vulnerability Scoring System (CVSS) v3.1 vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N, yielding a base score of 6.1. The Exploit Prediction Scoring System (EPSS) indicates a score of 0.00016, translating to a 3.96% percentile. This metric suggests a low probability of broad automated exploitation in the wild, largely constrained by the bespoke nature of the application and the firm requirement for targeted victim interaction.

Organizations utilizing the go-httpbin package must update their dependencies to version v2.18.0 or later. This update inherently resolves the vulnerability by enforcing the secure-by-default response handling architecture. Dependency managers such as Go modules handle this upgrade via the standard go get command specifying the patched version.

System administrators must audit their deployment configurations to ensure the UNSAFE_ALLOW_DANGEROUS_RESPONSES environment variable remains undefined or explicitly set to false. Enabling this variable in a production environment entirely negates the security benefits introduced in the v2.18.0 patch and reintroduces the cross-site scripting attack vector.

For environments where immediate patching is procedurally restricted, administrators implement Web Application Firewall (WAF) rules to mitigate the attack surface. These rules inspect HTTP GET requests targeting the /response-headers and /base64 paths. The WAF drops requests containing common HTML tags or JavaScript event handlers when combined with content-type manipulation parameters.