Spring Framework and Spring Security do 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 and access Spring MVC static resource URLs.
Affected versions include:
* Spring Security 4.1.0 - 4.1.4, 4.2.0 - 4.2.3 and 5.0
* Spring Framework 4.3.0 - 4.3.14, and 5.0.0 - 5.0.2
Older unmaintained versions of Spring Security and Spring Framework may also be affected.
As a general precaution, users are encouraged to separate public and private resources. For example, separating static resources and mapping them to /resources/public/** and /resources/private/** is preferred to having one common root with mixed public and private resource content underneath.
Created springframework tracking bugs for this issue:
Affects: fedora-all [bug 1540033]
Created springframework-security tracking bugs for this issue:
Affects: fedora-all [bug 1540032]
Jetty container in JBoss Fuse complies with servlet specification and does not return path parameters which is a root cause of this flaw, so JBoss Fuse is not affected.
*** Bug 1541996 has been marked as a duplicate of this bug. ***
For RH OpenStack Platform: Although the spring code contains the flaw, OpenDaylight uses Tomcat which is not vulnerable. "Tomcat follows the guidance previously provided by the Servlet Expert group and strips path parameters from the value returned by getContextPath(), getServletPath() and getPathInfo() ."
 https://www.securityfocus.com/archive/1/archive/1/514517/100/0/threaded <-- 2010.
catalina-22.214.171.124 used in ODL is from 2012 after the fixes. Should be ok.
Fixed upstream in Spring-security 5.0.1, 4.2.4, 4.1.5 via following commits:
Spring Security is not used in Millicore component of RHMAP.
This issue has been addressed in the following products:
Red Hat Fuse Intergration Services 2.0 based on Fuse 6.3 R7
Via RHSA-2018:2405 https://access.redhat.com/errata/RHSA-2018:2405