CVE-2026-2102 in wrensec-commons
Summary
by MITRE • 11/02/2026
wrensec-commons contains a reflected cross-site scripting (XSS) vulnerability in the CREST framework's HTTP binding. The HttpUtils.prepareResponse() method used the _mimeType request parameter to set the Content-Type response header without proper sanitization. By sending a GET request with _mimeType=text/html, an attacker could cause the browser to interpret a CREST JSON response as HTML, enabling execution of arbitrary JavaScript in the victim's browser. The vulnerability is exploitable by tricking a user into visiting a crafted URL targeting any deployed CREST endpoint. The issue is fixed in versions 22.6.2 and 23.0.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/02/2026
The wrensec-commons library, which serves as a foundational component for the CREST framework's HTTP binding layer, contains a critical reflected cross-site scripting vulnerability rooted in improper input validation within its response handling mechanisms. This flaw specifically resides in the HttpUtils.prepareResponse() method, which is responsible for constructing and returning HTTP responses to clients interacting with CREST endpoints. The security failure occurs when the application processes the _mimeType request parameter without adequate sanitization or strict type checking before utilizing it to set the Content-Type header of the outgoing response. In a secure implementation, such parameters should be validated against an allowlist of known safe MIME types or strictly enforced as JSON-based formats given that CREST is designed for structured data exchange. Instead, the application blindly trusts user-supplied input, allowing an attacker to manipulate the server's behavior by injecting malicious content type directives into the HTTP response stream.
The technical exploitation of this vulnerability relies on the browser's Content-Type sniffing and rendering engine behaviors. By sending a GET request with the _mimeType parameter set to text/html, an attacker forces the web server to return a response header indicating that the payload is HTML rather than JSON or XML. When a victim user visits a crafted URL containing this malicious parameter, their browser receives the CREST response but interprets it as executable HTML content due to the manipulated Content-Type header. This misinterpretation allows any JavaScript code embedded within the response body to be executed in the context of the vulnerable application's domain. Since the execution occurs within the victim's browser session, the attacker gains the ability to perform actions on behalf of the user, access sensitive data stored in local storage or cookies, and potentially hijack active sessions if proper security headers like SameSite are not sufficiently configured across all endpoints.
From an operational perspective, this reflected XSS vulnerability poses a significant risk to organizations deploying CREST-based services because it requires no authentication for exploitation via URL manipulation, although the impact is limited by the privileges of the victim user who must visit the malicious link. The attack vector primarily involves social engineering or phishing tactics where users are tricked into clicking links that trigger the malformed response generation. Once executed, the arbitrary JavaScript can steal session tokens, exfiltrate sensitive information transmitted through CREST endpoints, or redirect users to malicious sites for further exploitation such as credential harvesting. This aligns with CWE-79, which classifies improper neutralization of input during web page generation, and maps directly to MITRE ATT&CK technique T1059.007, indicating the use of JavaScript for client-side code execution. The lack of output encoding or strict MIME type enforcement represents a fundamental deviation from secure coding standards that prioritize defense-in-depth strategies against injection attacks.
To mitigate this vulnerability, organizations must immediately upgrade to wrensec-commons versions 22.6.2 and 23.0.0, which contain the necessary patches for input validation in the HttpUtils.prepareResponse() method. In addition to upgrading dependencies, developers should implement strict allowlisting for MIME types accepted by the application, ensuring that only expected formats such as application/json are processed without modification of response headers based on user input. Implementing Content Security Policy (CSP) headers can also provide an additional layer of defense by restricting the sources from which scripts can be loaded and executed, thereby mitigating the impact even if a reflected XSS vector is successfully triggered. Regular security audits focusing on HTTP header manipulation and output encoding practices are recommended to prevent similar issues in other parts of the application stack that handle dynamic content generation based on user-supplied parameters.