Most recent entries from all

cnvd-2017-00041

EUVD-2026-88111

fkie_cve-2016-9879

An issue was discovered in Pivotal Spring Security before 3.2.10, 4.1.x before 4.1.4, and 4.2.x before 4.2.1. Spring Security does not consider URL path parameters when processing security constraints. By adding a URL path parameter with an encoded "/" to a request, 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. The unexpected presence of path parameters can cause a constraint to be bypassed. Users of Apache Tomcat (all current versions) are not affected by this vulnerability since Tomcat follows the guidance previously provided by the Servlet Expert group and strips path parameters from the value returned by getContextPath(), getServletPath(), and getPathInfo(). Users of other Servlet containers based on Apache Tomcat may or may not be affected depending on whether or not the handling of path parameters has been modified. Users of IBM WebSphere Application Server 8.5.x are known to be affected. Users of other containers that implement the Servlet specification may be affected.

GHSA-v35c-49j6-q8hq — Security Constraint Bypass in Spring Security

Affected: Maven: org.springframework.security:spring-security-core

Spring Security does not consider URL path parameters when processing security constraints. By adding a URL path parameter with an encoded "/" to a request, 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 (see below). 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. The unexpected presence of path parameters can cause a constraint to be bypassed.

Users of Apache Tomcat (all current versions) are not affected by this vulnerability since Tomcat follows the guidance previously provided by the Servlet Expert group and strips path parameters from the value returned by getContextPath(), getServletPath() and getPathInfo() [1].

Users of other Servlet containers based on Apache Tomcat may or may not be affected depending on whether or not the handling of path parameters has been modified.

Users of IBM WebSphere Application Server 8.5.x are known to be affected.

Users of other containers that implement the Servlet specification may be affected.

[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=25015

## Affected Pivotal Products and Versions Severity is high unless otherwise noted. - Spring Security 3.2.0 - 3.2.9 - Spring Security 4.0.x - 4.1.3 - Spring Security 4.2.0 -…

gsd-2016-9879

RHSA-2017:1832 — Red Hat Security Advisory: Red Hat JBoss Fuse/A-MQ 6.3 R4 security and bug fix update

bouncycastle: Information disclosure in GCMBlockCipher camel-jacksonxml: Unmarshalling operation are vulnerable to RCE Security: Improper handling of path parameters allows bypassing the security constraint hawtio: Proxy is sharing cookies among all the clients hawtio: information Disclosure flaws due to unsafe path traversal cxf: CXF OAuth2 Hawk and JOSE MAC Validation code are vulnerable to timing attacks camel-core: Validation component vulnerable to SSRF via remote DTDs and XXE cxf: CXF JAX-RS XML Security streaming clients do not validate that the service response was signed or encrypted cxf: CXF's STSClient uses a flawed way of caching tokens that are associated with delegation tokens logback: Serialization vulnerability in SocketServer and ServerSocketReceiver XStream: DoS when unmarshalling void type