CVE-2025-45286: Reflected Cross-Site Scripting (XSS) in go-httpbin via Content-Type Manipulation

The go-httpbin application is a Go-based implementation of the httpbin.org testing and diagnostic service. It provides various HTTP endpoints designed to echo client requests, return specific HTTP status codes, and generate mock data for application testing. Developers deploy this application in internal testing environments and expose it to the internet for broader API utility.

CVE-2025-45286 represents a reflected Cross-Site Scripting (XSS) vulnerability, categorized under CWE-80 (Improper Neutralization of Web-Controllable Input). The flaw resides in the application's handling of specific diagnostic endpoints, notably /response-headers and /base64. These endpoints allow clients to dictate HTTP response headers, including the crucial Content-Type header, through standard URL query parameters.

By supplying a Content-Type value of text/html alongside a malicious payload, an attacker overrides the default response format. The application reflects the provided payload directly into the HTTP response body without applying HTML entity encoding or other neutralization mechanisms. Consequently, a victim's browser interprets the diagnostic output as a standard web page, executing embedded JavaScript within the application's origin context.

The root cause of this vulnerability lies in the intersection of dynamic HTTP header injection and raw input reflection. The /response-headers endpoint accepts arbitrary query parameters and maps them directly into the HTTP response headers. Simultaneously, the application serializes the entire request context, including those same query parameters, into the response body.

The vulnerability manifests because the application trusts the client-provided Content-Type implicitly. When an HTTP client requests a specific content type via the query string (e.g., ?Content-Type=text/html), the Go HTTP handler sets the corresponding header. The standard library HTTP server in Go does not enforce content sniffing protections by default when a Content-Type header is explicitly defined by the application logic.

In the /base64 endpoint, a similar mechanism applies. The endpoint extracts a base64-encoded string from the URL path, decodes it, and writes the raw byte slice directly to the response writer. The endpoint also processes a content-type query parameter, assigning its value to the response header. Because the decoded byte slice remains unsanitized and the content type is fully attacker-controlled, the browser processes the raw bytes as executable HTML or JavaScript.

An examination of the vulnerable implementation reveals a direct pipeline from client input to the HTTP response writer. Prior to version 2.18.0, the handler logic simply iterated over the URL query parameters and invoked w.Header().Set(key, value). Following the header assignment, the application encoded the request data using json.Marshal() or direct byte writing, outputting it directly to the client. The absence of context-aware output encoding permitted the insertion of raw HTML tags.

The remediation introduced in commit 0decfd1a2e88d85ca6bfb8a92421653f647cbc04 implements an explicit allowlist for content types. The patch introduces a helper function, isDangerousContentType, which evaluates the requested Content-Type against a hardcoded list of safe MIME types, specifically application/json, text/plain, and application/octet-stream. If the requested content type deviates from this allowlist, the application categorizes the response as potentially dangerous.

When a dangerous content type is detected, the patched application enforces mandatory HTML escaping on all reflected keys and values using the Go standard library's html.EscapeString function. The developers also introduced a feature flag, -unsafe-allow-dangerous-responses, bound to the UNSAFE_ALLOW_DANGEROUS_RESPONSES environment variable. This flag disables the new safety mechanisms for users who strictly require the legacy behavior, isolating the vulnerable code path behind an explicit opt-in mechanism.

Exploiting CVE-2025-45286 requires the attacker to construct a specialized URL targeting the vulnerable go-httpbin instance. The attack sequence begins with the selection of a susceptible endpoint. The attacker formats an HTTP GET request containing the target Content-Type directive. The parameter injection ensures the server responds with a MIME type that instructs the browser to parse the body as an HTML document.

For the /response-headers endpoint, the attacker appends the payload directly into a secondary query parameter. A functional proof-of-concept URL takes the form: http://<target>/response-headers?Content-Type=text/html&xss=<script>alert('XSS_SUCCESS')</script>. Upon receiving the request, the server sets the Content-Type header to text/html and embeds the <script> tag within the returned JSON-like payload. The browser ignores the structural JSON syntax and executes the script block.

Exploiting the /base64 endpoint involves encoding the payload to bypass superficial input filters or WAF rules. The attacker converts the JavaScript payload <script>alert(1)</script> into its base64 equivalent, PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==. The malicious URL is constructed as http://<target>/base64/PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==?content-type=text/html. The server decodes the base64 string and serves the executable HTML directly to the client.

The successful exploitation of this vulnerability yields a classic reflected XSS condition. Because the injected JavaScript executes within the victim's browser session, the attacker inherits the user's origin context. The injected script gains access to document.cookie, localStorage, and sessionStorage objects associated with the domain hosting the go-httpbin instance. If the service is deployed on a shared internal domain, the impact expands laterally to other applications on that domain.

The CVSS v3.1 vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N accurately reflects the medium-severity nature of the flaw. The attack requires no prior authentication and operates over the network, but it mandates active user interaction. The victim must click a crafted link or visit an attacker-controlled web page that triggers the request. The scope change (S:C) highlights the transition from the vulnerable server to the victim's client environment.

Despite the straightforward exploitation mechanism, the real-world probability of widespread automated exploitation remains low. The EPSS score stands at 0.00013 (2.24th percentile), indicating minimal observed exploitation activity in the wild. Furthermore, go-httpbin primarily functions as an ephemeral testing utility rather than a platform storing sensitive user data. However, the presence of an XSS vulnerability on a trusted subdomain reliably facilitates session hijacking against associated production applications.

The definitive remediation for CVE-2025-45286 requires upgrading the mccutchen/go-httpbin package to version 2.18.0 or later. The update introduces robust output encoding and restricts MIME type manipulation by default. Development teams integrating this package into automated testing pipelines must verify their dependencies and ensure the minimum required version is specified in their go.mod files.

Organizations unable to immediately apply the patch mitigate the risk through infrastructure-level controls. Implementing a Web Application Firewall (WAF) rule to inspect query parameters targeting the /response-headers and /base64 endpoints provides a strong compensating control. The WAF must block requests containing HTML-related MIME types, specifically matching the regular expression pattern (?i)[\?&]content-type=text/html.

Network administrators implement defense-in-depth by restricting access to internal testing utilities. By placing go-httpbin instances behind authenticating proxies or restricting network access via IP allowlists, organizations severely limit the exposure of the vulnerability. Security teams must monitor web server logs for suspicious requests containing <script> tags or base64-encoded HTML elements targeting the specific application paths.

Identifying exploitation attempts for CVE-2025-45286 requires deep packet inspection or rigorous web application firewall logging. Security engineers must focus on the query string parameters interacting with the /response-headers and /base64 application endpoints. The primary detection vector involves identifying the explicit declaration of HTML or script-based MIME types within the HTTP GET request variables.

A Nuclei template reliably identifies vulnerable instances by issuing a benign probe to the target application. The scanner executes an HTTP request to /response-headers?Content-Type=text/html&xss=<script>console.log('vuln_test')</script>. The detection logic confirms two simultaneous conditions: the presence of Content-Type: text/html in the HTTP response headers and the unescaped script tag within the response body.

Network Intrusion Detection Systems (NIDS) implement specific Suricata or Snort rules to capture in-flight attacks. The rule logic monitors inbound HTTP traffic for the specific application paths and applies Perl Compatible Regular Expressions (PCRE) to the URI buffer. A rule triggering on pcre:"/\/(?:response-headers|base64).*?content-type=text\/html/i" provides a high-confidence indicator of compromise for this specific vulnerability vector.