Spring Security (Spring Security 4.1.x before 4.1.5, 4.2.x before 4.2.4, and 5.0.x before 5.0.1; and Spring Framework 4.3.x before 4.3.14 an
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 4.2.4, 5.0.1, 4.3.14, 5.0.3, 4.1.5
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
Spring Security (Spring Security 4.1.x before 4.1.5, 4.2.x before 4.2.4, and 5.0.x before 5.0.1; and Spring Framework 4.3.x before 4.3.14 and 5.0.x before 5.0.3) does not consider URL path parameters when processing security constraints. By adding a URL path parameter with special encodings, an attacker may be able to bypass a security constraint. The root cause of this issue is a lack of clarity regarding the handling of path parameters in the Servlet Specification. Some Servlet containers include path parameters in the value returned for getPathInfo() and some do not. Spring Security uses the value returned by getPathInfo() as part of the process of mapping requests to security constraints. In this particular attack, different character encodings used in path parameters allows secured Spring MVC static resource URLs to be bypassed.
Timeline
- CVE published
- Record last updated
Affected versions
- Dell EMC Spring by Pivotal
Version range not reported
- org.springframework.security:spring-security-coreMaven
From 4.2.0 · fixed in 4.2.4
- org.springframework.security:spring-security-coreMaven
From 5.0.0 · fixed in 5.0.1
- org.springframework:spring-coreMaven
From 4.3.0 · fixed in 4.3.14
- org.springframework:spring-coreMaven
From 5.0.0 · fixed in 5.0.3
- org.springframework.security:spring-security-coreMaven
From 4.1.0 · fixed in 4.1.5