CVE-2025-41234

What it actually does

This is a reflected file download weakness in Spring Framework Content-Disposition header generation. Applications are only exposed when they build a Content-Disposition header with org.springframework.http.ContentDisposition, use ContentDisposition.Builder#filename(String, Charset) with a non-ASCII charset, derive the filename from unsanitized user input, and return attacker-influenced response content. In that combination, improper handling of the filename value can let an attacker craft a response that a browser saves as a misleading or executable file, enabling command execution only if the victim later opens or runs the downloaded file. The issue requires user interaction and specific application behavior; it is not a general unauthenticated remote code execution flaw in Spring itself.

Why it matters to the business

The main business risk is user compromise through trusted application download flows: an attacker may abuse a legitimate application endpoint to trick users into downloading and executing a malicious file that appears to come from the organization. Consequences can include endpoint compromise, credential theft, malware execution, data exposure through the compromised user session, and loss of trust in customer-facing download features. The current exploitation signal is low: EPSS is 0.00532, no known CISA KEV listing is present, no ransomware association is indicated, and exploit maturity is listed as none; however, Spring Framework is widely deployed, so affected applications should still be identified and corrected during normal patch cycles or faster for internet-facing download endpoints.

How an attack unfolds

An attacker first identifies an application endpoint that returns downloadable content and sets a Content-Disposition header using Spring Framework's ContentDisposition builder. The attacker then determines whether the filename parameter can be influenced through a request parameter, path segment, form field, or other user-controlled input, and whether the response body can include attacker-controlled content. If the application uses ContentDisposition.Builder#filename(String, Charset) with a non-ASCII charset and fails to sanitize the filename, the attacker crafts a URL or request that causes the application to emit a malicious Content-Disposition filename and response body. The attacker then sends the crafted link to a victim through phishing, chat, documentation, support workflows, or another social channel. If the victim downloads and opens or executes the resulting file, attacker-supplied commands may run on the victim endpoint. Successful exploitation therefore depends on a vulnerable application pattern, attacker control over filename and content, and victim interaction.

How to fix it

Upgrade affected Spring Framework versions to the fixed release for the active branch: 6.2.x should be upgraded to 6.2.8 or later; 6.1.x should be upgraded to 6.1.21 or later; 6.0.x should be upgraded to 6.0.29 or later where available through commercial support. Affected ranges are Spring Framework 6.2.0 through 6.2.7, 6.1.0 through 6.1.20, and 6.0.5 through 6.0.28. Also review application code that sets Content-Disposition headers. If immediate upgrade is not possible, avoid ContentDisposition.Builder#filename(String, Charset) for user-controlled filenames, use ContentDisposition.Builder#filename(String) or an ASCII-safe filename path, sanitize filenames strictly, remove CR/LF and header separator characters, normalize to a safe allowlist of characters, prevent dangerous file extensions such as .bat, .cmd, .ps1, .vbs, .js, .hta, .lnk, and .scr, set accurate Content-Type values, and add X-Content-Type-Options: nosniff. Ensure attackers cannot inject executable script or command content into downloadable responses.

How to confirm the fix worked

Confirm exposure by inventorying Spring Framework dependencies in SBOMs, build manifests, dependency lock files, container images, and deployed artifacts. Look for org.springframework artifacts in the affected version ranges: 6.2.0-6.2.7, 6.1.0-6.1.20, and 6.0.5-6.0.28. Then perform code review for org.springframework.http.ContentDisposition and ContentDisposition.Builder#filename(String, Charset), especially where the filename argument comes from request parameters, path variables, headers, uploaded metadata, database fields populated by users, or other untrusted sources. After patching, verify the deployed runtime loads Spring Framework 6.2.8+, 6.1.21+, or 6.0.29+ as applicable. Test representative download endpoints with filenames containing non-ASCII characters, quotes, semicolons, percent-encoded characters, CR/LF sequences, path separators, and executable extensions, and confirm the Content-Disposition response is safely encoded and cannot produce a dangerous filename.

Typical attack path

1. Locate a Spring Framework application endpoint that returns file downloads or export responses.
2. Test whether the response includes a Content-Disposition header generated from user-controlled input.
3. Confirm the application uses a non-ASCII charset filename path and does not sanitize dangerous filename characters or extensions.
4. Find a way to inject attacker-controlled content into the downloaded response body.
5. Craft a URL or request that produces a misleading or executable downloaded file.
6. Convince a victim to visit the crafted URL and download the generated file.
7. Rely on the victim opening or executing the file to run attacker-controlled commands.

How to detect it

To determine whether exploitation may already have occurred, focus on applications with download endpoints that set Content-Disposition headers and allow user-influenced filenames. Review reverse proxy, WAF, CDN, application, and access logs for requests to export or download endpoints containing suspicious filename parameters, encoded control characters, executable extensions, or non-ASCII filename manipulation. Look for query strings or path values containing %0d, %0a, CRLF attempts, semicolons, quotes, backslashes, path traversal sequences, or extensions commonly used for command execution such as .bat, .cmd, .ps1, .vbs, .js, .hta, .lnk, and .scr. Correlate suspicious requests with response headers showing Content-Disposition and with downloads followed by endpoint security alerts, new script or shell processes, or user reports of unexpected downloaded files. On endpoints, investigate browser download histories and recently created files with executable extensions that originated from trusted application domains. There are no universally reliable attacker infrastructure indicators for this issue; detection is primarily behavioral and application-specific.

• org.springframework.http.ContentDisposition
• ContentDisposition.Builder#filename
• filename(String, Charset)
• Content-Disposition: attachment
• Content-Disposition: inline
• filename*=
• %0d%0a
• %0D%0A
• %0a
• %0A
• %0d
• %0D
• .bat
• .cmd
• .ps1
• .vbs
• .js
• .hta
• .lnk
• .scr
• X-Content-Type-Options: nosniff

What your security team should do

• Prioritize internet-facing applications that expose export, report, attachment, invoice, archive, or user-named download functionality built on Spring Framework 6.x.
• Upgrade Spring Framework to 6.2.8+, 6.1.21+, or 6.0.29+ depending on the deployed branch.
• Run SCA/SBOM queries across source repositories, CI artifacts, container images, and production deployments for affected Spring Framework versions.
• Ask application teams to search for ContentDisposition.Builder#filename(String, Charset) and verify no unsanitized user input reaches the filename value.
• Add secure filename handling standards: character allowlists, safe extensions, content-type enforcement, and rejection of CR/LF and header separator characters.
• Review web access logs for suspicious download requests using executable extensions, encoded newline characters, semicolon-delimited filename manipulation, or unusual non-ASCII filename payloads.
• Because this is not KEV-listed and has low EPSS, handle as risk-based patching unless a high-value or externally exposed application matches the vulnerable pattern.