IBM WebSphere Application Server 8.5 and 9.0 could provide weaker than expected security, caused by the improper encoding in a local configuration file. IBM X-Force ID: 258637.

IBM WebSphere Application Server 7.0, 8.0, and 8.5.5 installations using Form Login could allow a remote attacker to conduct spoofing attacks. IBM X-Force ID: 145769.

IBM Business Process Manager (aka BPM) 7.5.x, 8.0.x, and 8.5.x and WebSphere Lombardi Edition (aka WLE) 7.2.x allow remote authenticated users to bypass intended access restrictions on internal service types via vectors involving the executeServiceByName URL.

IBM WebSphere Application Server 8.0, 8.5, and 9.0 could provide weaker than expected security after using the Admin Console to update the web services security bindings settings. IBM X-Force ID: 129576.

IBM WebSphere Application Server 8.0 and 8.5.5 could provide weaker than expected security. A remote attacker could exploit this weakness to obtain sensitive information and gain unauthorized access to the admin console. IBM X-Force ID: 121549.

IBM WebSphere Application Server 8.0, 8.5, 8.5.5, and 9.0 using OpenID Connect (OIDC) configured with a Trust Association Interceptor (TAI) could allow a user to gain elevated privileges on the system. IBM Reference #: 1999293.

IBM WebSphere Application Server 7.0, 8.0, and 9.0 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM Reference #: 1997743

IBM WebSphere Application Server may be vulnerable to a denial of service, caused by allowing serialized objects from untrusted sources to run and cause the consumption of resources.

IBM WebSphere Application Server is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session.

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(), ge…