6.5 CVE-2025-41234
Description
In Spring Framework, versions 6.0.x as of 6.0.5, versions 6.1.x and 6.2.x, an application is vulnerable to a reflected file download (RFD) attack when it sets a “Content-Disposition” header with a non-ASCII charset, where the filename attribute is derived from user-supplied input.
Specifically, an application is vulnerable when all the following are true:
* The header is prepared with org.springframework.http.ContentDisposition.
* The filename is set via ContentDisposition.Builder#filename(String, Charset).
* The value for the filename is derived from user-supplied input.
* The application does not sanitize the user-supplied input.
* The downloaded content of the response is injected with malicious commands by the attacker (see RFD paper reference for details).
An application is not vulnerable if any of the following is true:
* The application does not set a “Content-Disposition” response header.
* The header is not prepared with org.springframework.http.ContentDisposition.
* The filename is set via one of: * ContentDisposition.Builder#filename(String), or
* ContentDisposition.Builder#filename(String, ASCII)
* The filename is not derived from user-supplied input.
* The filename is derived from user-supplied input but sanitized by the application.
* The attacker cannot inject malicious content in the downloaded content of the response.
Affected Spring Products and VersionsSpring Framework:
* 6.2.0 - 6.2.7
* 6.1.0 - 6.1.20
* 6.0.5 - 6.0.28
* Older, unsupported versions are not affected
MitigationUsers of affected versions should upgrade to the corresponding fixed version.
Affected version(s)Fix versionAvailability6.2.x6.2.8OSS6.1.x6.1.21OSS6.0.x6.0.29 Commercial https://enterprise.spring.io/ No further mitigation steps are necessary.
CWE-113 in `Content-Disposition` handling in VMware Spring Framework versions 6.0.5 to 6.2.7 allows remote attackers to launch Reflected File Download (RFD) attacks via unsanitized user input in `ContentDisposition.Builder#filename(String, Charset)` with non-ASCII charsets.
https://nvd.nist.gov/vuln/detail/CVE-2025-41234
Categories
CWE-113 : Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')
The product receives data from an HTTP agent/component (e.g., web server, proxy, browser, etc.), but it does not neutralize or incorrectly neutralizes CR and LF characters before the data is included in outgoing HTTP headers. Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.) Construct HTTP headers very carefully, avoiding the use of non-validated input data. Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component. Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked. Chain: Proxy uses a substring search instead of parsing the Transfer-Encoding header (CWE-697), allowing request splitting (CWE-113) and cache poisoning Scala-based HTTP interface allows request splitting and response splitting through header names, header values, status reasons, and URIs Javascript-based framework allows request splitting through a path option of an HTTP request Application accepts CRLF in an object ID, allowing HTTP response splitting. Shopping cart allows HTTP response splitting to perform HTML injection via CRLF in a parameter for a url Bulletin board allows response splitting via CRLF in parameter. Response splitting via CRLF in PHPSESSID. e-commerce app allows HTTP response splitting using CRLF in object id parameters
References
CPE
REMEDIATION
EXPLOITS
Exploit-db.com
| id |
description |
date |
|
| No known exploits |
POC Github
Other Nist (github, ...)
CAPEC
Common Attack Pattern Enumerations and Classifications
| id |
description |
severity |
| 105 |
HTTP Request Splitting
[Survey network to identify target] The adversary performs network reconnaissance by monitoring relevant traffic to identify the network path and parsing of the HTTP messages with the goal of identifying potential targets. [Identify vulnerabilities in targeted HTTP infrastructure and technologies] The adversary sends a variety of benign/ambiguous HTTP requests to observe responses from HTTP infrastructure in order to identify differences/discrepancies in the interpretation and parsing of HTTP requests by examining supported HTTP protocol versions, HTTP headers, syntax checking and input filtering. [Cause differential HTTP responses by experimenting with identified HTTP Request vulnerabilities] The adversary sends maliciously crafted HTTP requests with custom strings and embedded web scripts and objects in HTTP headers to interfere with the parsing of intermediary and back-end HTTP infrastructure, followed by normal/benign HTTP request from the adversary or a random user. The intended consequences of the malicious HTTP requests will be observed in the HTTP infrastructure response to the normal/benign HTTP request to confirm applicability of identified vulnerabilities in the adversary's plan of attack. [Perform HTTP Request Splitting attack] Using knowledge discovered in the experiment section above, smuggle a message to cause one of the consequences. |
High |
| 31 |
Accessing/Intercepting/Modifying HTTP Cookies
This attack relies on the use of HTTP Cookies to store credentials, state information and other critical data on client systems. There are several different forms of this attack. The first form of this attack involves accessing HTTP Cookies to mine for potentially sensitive data contained therein. The second form involves intercepting this data as it is transmitted from client to server. This intercepted information is then used by the adversary to impersonate the remote user/session. The third form is when the cookie's content is modified by the adversary before it is sent back to the server. Here the adversary seeks to convince the target server to operate on this falsified information. [Obtain copy of cookie] The adversary first needs to obtain a copy of the cookie. The adversary may be a legitimate end user wanting to escalate privilege, or could be somebody sniffing on a network to get a copy of HTTP cookies. [Obtain sensitive information from cookie] The adversary may be able to get sensitive information from the cookie. The web application developers may have assumed that cookies are not accessible by end users, and thus, may have put potentially sensitive information in them. [Modify cookie to subvert security controls.] The adversary may be able to modify or replace cookies to bypass security controls in the application. |
High |
| 34 |
HTTP Response Splitting
[Survey network to identify target] The adversary performs network reconnaissance by monitoring relevant traffic to identify the network path and parsing of the HTTP messages with the goal of identifying potential targets [Identify vulnerabilities in targeted HTTP infrastructure and technologies] The adversary sends a variety of benign/ambiguous HTTP requests to observe responses from HTTP infrastructure in order to identify differences/discrepancies in the interpretation and parsing of HTTP requests by examining supported HTTP protocol versions, HTTP headers, syntax checking and input filtering. [Cause differential HTTP responses by experimenting with identified HTTP Request vulnerabilities] The adversary sends maliciously crafted HTTP request to back-end HTTP infrastructure to inject adversary data (in the form of HTTP headers with custom strings and embedded web scripts and objects) into HTTP responses (intended for intermediary and/or front-end client/victim HTTP agents communicating with back-end HTTP infrastructure) for the purpose of interfering with the parsing of HTTP responses by intermediary and front-end client/victim HTTP agents. The intended consequences of the malicious HTTP request and the subsequent adversary injection and manipulation of HTTP responses to intermediary and front-end client/victim HTTP agents, will be observed to confirm applicability of identified vulnerabilities in the adversary's plan of attack. [Perform HTTP Response Splitting attack] Using knowledge discovered in the experiment section above, smuggle a message to cause one of the consequences. |
High |
| 85 |
AJAX Footprinting
This attack utilizes the frequent client-server roundtrips in Ajax conversation to scan a system. While Ajax does not open up new vulnerabilities per se, it does optimize them from an attacker point of view. A common first step for an attacker is to footprint the target environment to understand what attacks will work. Since footprinting relies on enumeration, the conversational pattern of rapid, multiple requests and responses that are typical in Ajax applications enable an attacker to look for many vulnerabilities, well-known ports, network locations and so on. The knowledge gained through Ajax fingerprinting can be used to support other attacks, such as XSS. [Send request to target webpage and analyze HTML] Using a browser or an automated tool, an adversary sends requests to a webpage and records the received HTML response. Adversaries then analyze the HTML to identify any known underlying JavaScript architectures. This can aid in mappiong publicly known vulnerabilities to the webpage and can also helpo the adversary guess application architecture and the inner workings of a system. |
Low |
MITRE
Techniques
| id |
description |
| T1539 |
Steal Web Session Cookie |
| © 2022 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. |
Mitigations
| id |
description |
| M1017 |
Train users to identify aspects of phishing attempts where they're asked to enter credentials into a site that has the incorrect domain for the application they are logging into. Additionally, train users not to run untrusted JavaScript in their browser, such as by copying and pasting code or dragging and dropping bookmarklets. |
| © 2022 The MITRE Corporation. Esta obra se reproduce y distribuye con el permiso de The MITRE Corporation. |
Cybersecurity needs ?
Strengthen software security from the outset with our DevSecOps expertise
Integrate security right from the start of the software development cycle for more robust applications and greater customer confidence.
Our team of DevSecOps experts can help you secure your APIs, data pipelines, CI/CD chains, Docker containers and Kubernetes deployments.
Discover this offer
