CVE-2026-41844

What it actually does

This vulnerability allows an unauthenticated remote attacker to cause a Spring MVC or Spring WebFlux application to issue an HTTP 302 redirect to an attacker-controlled external host. The issue occurs only in applications that define a catch-all mapping such as "/**" and do not explicitly specify a view name, allowing Spring’s implicit view-name resolution to interpret a crafted request path containing the `redirect:` prefix as a redirect instruction. It does not directly provide code execution or server compromise, but it can be used to abuse a trusted application domain as an open redirector, which may expose users to phishing, credential theft, or token leakage if sensitive parameters are included in redirected links.

Why it matters to the business

The main business risk is trust abuse: attackers can send links that appear to belong to a legitimate application but silently forward users to malicious sites. This can increase the success of phishing, credential-harvesting, malware-delivery, and social-engineering campaigns, especially where users or partners trust links from the affected domain. Operational impact is usually low because availability is not affected, and current exploitation signals are limited: EPSS is very low at 0.00134, flat over 30 days, there is no known CISA KEV listing, no ransomware association, and no reported exploit maturity in the provided data. However, because Spring Framework is widely used in enterprise Java applications, vulnerable routing patterns should still be reviewed across exposed applications.

How an attack unfolds

An attacker first identifies a Spring MVC or Spring WebFlux application that uses a broad catch-all route such as "/**" and relies on implicit view-name resolution rather than explicitly returning a view. The attacker then crafts a URL whose path or encoded path causes the derived view name to begin with `redirect:` and points to an external domain under the attacker’s control. When a user clicks the crafted link, the application processes the request, treats the inferred view name as a redirect target, and responds with an HTTP 302 `Location` header to the attacker-controlled site. The attacker can use the trusted original domain in emails, chats, ads, or support messages to make the link appear legitimate, then host a phishing page or other lure at the destination. Successful exploitation requires user interaction and does not by itself compromise the server.

How to fix it

Upgrade Spring Framework to a version that is not in the affected ranges. The affected ranges are 7.0.0 through 7.0.7, 6.2.0 through 6.2.18, 6.1.0 through 6.1.27, and 5.3.0 through 5.3.48; because exact fixed versions were not provided in the input, use the latest vendor-supported patch release for the active Spring line and verify the advisory from the Spring project or your distribution vendor. In application code, avoid catch-all `/**` mappings that rely on implicit view-name resolution. Explicitly return safe view names, use `@ResponseBody` or `ResponseEntity` where a view is not intended, validate and constrain redirect targets, and prefer server-side allowlists for any legitimate redirects. As a mitigation where immediate upgrade is not possible, block or normalize requests containing `redirect:` or encoded equivalents in paths handled by catch-all routes, and add reverse-proxy or WAF rules to detect outbound 302 responses with external `Location` headers from unexpected endpoints.

How to confirm the fix worked

Confirm dependency versions using build manifests and dependency tooling such as Maven dependency trees, Gradle dependency reports, SBOMs, container image scans, and runtime classpath inspection. Verify that no deployed application uses affected Spring Framework versions in combination with a catch-all `/**` mapping that relies on implicit view-name resolution. Functionally test suspected endpoints by sending benign requests containing `redirect:https://example.invalid` and encoded variants, then confirm the application does not return a 302 redirect to an external host. After remediation, verify that the application either returns a normal application response, a controlled error, or a redirect only to an approved internal path. Review reverse-proxy and application logs to ensure no unexpected external `Location` headers are generated by affected endpoints.

Typical attack path

1. Identify an internet-facing Spring MVC or Spring WebFlux application using Spring Framework 5.3.x, 6.1.x, 6.2.x, or 7.0.x in the affected version ranges.
2. Probe for catch-all routes such as "/**" where no explicit view name is returned.
3. Craft a URL containing a `redirect:`-prefixed path or encoded equivalent that resolves to an attacker-controlled external URL.
4. Deliver the crafted link to a target user through phishing, messaging, advertisements, documentation comments, or another social-engineering channel.
5. The target user clicks the trusted-looking application URL.
6. The application responds with an HTTP 302 redirect to the attacker-controlled host.
7. The attacker uses the destination page to harvest credentials, collect tokens included in URLs, deliver malware, or continue social engineering.

How to detect it

Investigate whether the application has already been abused as an open redirector by reviewing web access logs, reverse-proxy logs, CDN logs, WAF events, and application logs for requests containing `redirect:` or URL-encoded equivalents in the path. Focus on requests that returned HTTP 301, 302, 303, 307, or 308 responses and had a `Location` header pointing to a host different from the legitimate application host. Correlate suspicious redirects with user-agent strings, source IPs, referrers, email-security alerts, and reported phishing messages. Look for bursts of low-volume testing from scanners followed by crafted links sent to users. Because this vulnerability does not normally create files, spawn processes, or execute server-side commands, detection is primarily log-based rather than host-forensic. If full HTTP response headers are logged, search specifically for external `Location` values from endpoints that should not perform redirects. If only request logs are available, search for raw and encoded `redirect:` strings in URL paths and query strings, then pivot on timestamps to determine whether the response status was a redirect.

• redirect:http://
• redirect:https://
• redirect://
• redirect%3Ahttp%3A%2F%2F
• redirect%3Ahttps%3A%2F%2F
• redirect%3A%2F%2F
• redirect%253Ahttp
• redirect%253Ahttps
• GET /redirect:http
• GET /redirect:https
• GET /redirect%3Ahttp
• GET /redirect%3Ahttps
• POST /redirect:http
• POST /redirect:https
• Location: http://
• Location: https://

What your security team should do

• Inventory externally reachable Spring MVC and Spring WebFlux applications and identify those using Spring Framework 7.0.0-7.0.7, 6.2.0-6.2.18, 6.1.0-6.1.27, or 5.3.0-5.3.48.
• Prioritize remediation for public-facing applications, authentication portals, partner portals, and applications whose domains are commonly trusted by users.
• Upgrade to the latest non-affected Spring Framework patch release for the deployed major/minor line after confirming vendor guidance.
• Review application routes for catch-all `/**` mappings and require explicit view names or non-view response types where appropriate.
• Add detection for request paths containing `redirect:` and encoded variants, especially when followed by HTTP 302 responses to external domains.
• Tune WAF or reverse-proxy controls to block suspicious redirect-prefix paths on vulnerable endpoints until code and dependency updates are complete.
• Educate help desk, fraud, and phishing-response teams that trusted application domains may be abused as redirectors even when the application server is not compromised.