CVE-2025-41234: Spring Framework RFD Vulnerability

CVE-2025-41234 Overview

A Reflected File Download (RFD) vulnerability exists in VMware Spring Framework affecting versions 6.0.5 through 6.2.7. The vulnerability resides in the Content-Disposition header handling when applications use org.springframework.http.ContentDisposition with a non-ASCII charset in the ContentDisposition.Builder#filename(String, Charset) method. When the filename attribute is derived from unsanitized user-supplied input, attackers can exploit this flaw to deliver malicious files to unsuspecting users, potentially leading to code execution on the victim's system.

Critical Impact

Attackers can leverage this RFD vulnerability to trick users into downloading and executing malicious files disguised as legitimate content, potentially compromising confidentiality and integrity of affected systems.

Affected Products

• Spring Framework 6.2.0 - 6.2.7
• Spring Framework 6.1.0 - 6.1.20
• Spring Framework 6.0.5 - 6.0.28

Discovery Timeline

• June 12, 2025 - CVE-2025-41234 published to NVD
• June 16, 2025 - Last updated in NVD database

Technical Details for CVE-2025-41234

Vulnerability Analysis

This vulnerability is classified under CWE-113 (HTTP Response Splitting), manifesting specifically in how Spring Framework handles Content-Disposition headers with non-ASCII character sets. The flaw enables Reflected File Download attacks, a technique where attackers manipulate server responses to deliver malicious payloads to users.

The vulnerability requires a specific set of conditions to be exploitable: the application must use org.springframework.http.ContentDisposition to prepare headers, utilize the ContentDisposition.Builder#filename(String, Charset) method with a non-ASCII charset, derive the filename from user input without proper sanitization, and the attacker must be able to inject malicious commands into the downloaded response content.

The network-based attack vector requires low privileges and user interaction, with the scope extending beyond the vulnerable component to potentially impact other systems. Successful exploitation can result in high confidentiality impact and low integrity impact, enabling attackers to exfiltrate sensitive data or execute arbitrary commands on victim machines.

Root Cause

The root cause stems from improper input validation in the ContentDisposition.Builder#filename(String, Charset) method when handling non-ASCII character sets. The framework fails to adequately sanitize user-controlled input that flows into the filename attribute of the Content-Disposition header. This allows attackers to inject specially crafted characters that, when combined with malicious response content, can be interpreted as executable files by the victim's browser or operating system.

Attack Vector

The attack exploits the trust relationship between users and the vulnerable application. An attacker crafts a malicious URL containing a specially formatted filename parameter that includes executable extensions (such as .bat, .cmd, or .ps1 on Windows). When a victim clicks the link, the application reflects this attacker-controlled filename in the Content-Disposition header with the non-ASCII charset encoding. The browser then prompts the user to download the file with the malicious extension, and the response body contains attacker-injected commands. If the user executes the downloaded file, the malicious commands run with the user's privileges.

The vulnerability is particularly dangerous because the downloaded file appears to originate from a trusted source—the vulnerable application itself—making users more likely to execute it without suspicion.

Detection Methods for CVE-2025-41234

Indicators of Compromise

• Unusual Content-Disposition headers in HTTP responses containing executable file extensions like .bat, .cmd, .ps1, or .vbs derived from request parameters
• Web server logs showing requests with URL-encoded or specially crafted filename parameters targeting download endpoints
• User reports of unexpected file downloads with suspicious extensions from trusted application URLs

Detection Strategies

• Implement web application firewall (WAF) rules to detect and block requests containing executable file extensions in filename parameters
• Monitor application logs for anomalous patterns in Content-Disposition header generation, particularly those using non-ASCII charsets with user-controlled values
• Deploy intrusion detection signatures that identify RFD attack patterns in HTTP request/response pairs

Monitoring Recommendations

• Enable detailed logging for all endpoints that generate Content-Disposition headers to capture filename parameter sources
• Configure security information and event management (SIEM) alerts for unusual download activity patterns across your Spring Framework applications
• Establish baseline metrics for file download endpoints and alert on deviations that may indicate exploitation attempts

How to Mitigate CVE-2025-41234

Immediate Actions Required

• Upgrade Spring Framework to the fixed versions: 6.2.8 (OSS), 6.1.21 (OSS), or 6.0.29 (Commercial) immediately
• Review all application code that uses ContentDisposition.Builder#filename(String, Charset) with non-ASCII charsets to identify potentially vulnerable endpoints
• Implement input validation and sanitization for any user-supplied values used in filename generation

Patch Information

VMware has released patched versions addressing this vulnerability. Users should upgrade to the following fixed versions based on their current Spring Framework branch:

For detailed patch information, refer to the Spring Security Advisory CVE-2025-41234.

Workarounds

• Avoid using ContentDisposition.Builder#filename(String, Charset) with non-ASCII charsets; instead use ContentDisposition.Builder#filename(String) or ContentDisposition.Builder#filename(String, ASCII) which are not affected
• Implement strict input validation to sanitize all user-supplied values before using them in filename attributes, filtering out dangerous characters and file extensions
• Ensure user-controlled input never directly flows into Content-Disposition header filename values without proper encoding and validation

// Secure filename handling example
// Use ASCII charset instead of non-ASCII to avoid vulnerability
ContentDisposition disposition = ContentDisposition.builder("attachment")
    .filename(sanitizeFilename(userInput))  // Always sanitize user input
    .build();

// Or use the safe method without charset parameter
ContentDisposition safeDis = ContentDisposition.builder("attachment")
    .filename(sanitizedFilename)
    .build();