CVE-2017-5648
CriticalSummary
In Apache Tomcat versions from 9.0.0.M1 to 9.0.0.M17, 8.5.0 to 8.5.11, 8.0.0.RC1 to 8.0.41, and 7.0.0 to 7.0.75, there was an issue with the use of the incorrect facade object in some calls to application listeners. This allowed untrusted applications to retain a reference to the request or response object, potentially accessing or modifying information associated with another web application.
Risk Assessment
The organization may be exposed to attacks where untrusted applications can access data from other applications, leading to information leakage or modification.
Recommendation
It is recommended to update Apache Tomcat to the latest version to mitigate this vulnerability and review the security of applications running in a SecurityManager environment.
Other vulnerabilities in Apache Tomcat
See all- CVE-2026-43513High
The vulnerability related to improper handling of case sensitivity in LockOutRealm in Apache Tomcat may lead to unauthorized access. It affects versions from 11.0.0-M1 to 11.0.21, from 10.1.0-M1 to 10.1.54, from 9.0.0.M1 to 9.0.117, from 8.5.0 to 8.5.100, and from 7.0.0 to 7.0.109.
- CVE-2026-42498High
A vulnerability in Apache Tomcat related to the exposure of the HTTP Authentication Header to unexpected hosts during WebSocket authentication. It affects versions from 11.0.0-M1 to 11.0.21, 10.1.0-M1 to 10.1.54, 9.0.2 to 9.0.117, 8.5.24 to 8.5.100, and 7.0.83 to 7.0.109.
- CVE-2026-41284High
There is a vulnerability in Apache Tomcat related to resource allocation without limits or throttling. This affects versions from 11.0.0-M1 to 11.0.21, from 10.1.0-M1 to 10.1.54, and from 9.0.0.M1 to 9.0.117.
- CVE-2025-48989High
A vulnerability in Apache Tomcat related to improper resource shutdown or release allows for a 'made you reset' attack. This affects versions from 11.0.0-M1 to 11.0.9, from 10.1.0-M1 to 10.1.43, and from 9.0.0.M1 to 9.0.107.
- CVE-2017-7675High
The HTTP/2 implementation in Apache Tomcat from version 9.0.0.M1 to 9.0.0.M21 and from 8.5.0 to 8.5.15 bypassed several security checks that prevented directory traversal attacks. It was therefore possible to bypass security constraints using a specially crafted URL.
- CVE-2016-6796High
A malicious web application running on Apache Tomcat versions from 6.0.0 to 9.0.0.M9 was able to bypass a configured SecurityManager via manipulation of the configuration parameters for the JSP Servlet.
- CVE-2016-6817High
The HTTP/2 header parser in Apache Tomcat versions 9.0.0.M1 to 9.0.0.M11 and 8.5.0 to 8.5.6 entered an infinite loop if a header larger than the available buffer was received. This made a denial of service attack possible.
- CVE-2016-6797High
The ResourceLinkFactory implementation in Apache Tomcat versions 9.0.0.M1 to 9.0.0.M9, 8.5.0 to 8.5.4, 8.0.0.RC1 to 8.0.36, 7.0.0 to 7.0.70, and 6.0.0 to 6.0.45 did not limit web application access to global JNDI resources to those resources explicitly linked to the web application. Therefore, it was possible for a web application to access any global JNDI resource whether an explicit ResourceLink had been configured or not.
- CVE-2017-5664High
The error page mechanism of the Java Servlet Specification requires that the original request and response be forwarded to the error page. For static files, the expected behavior is to serve the content of the file as if processing a GET request, which was not implemented in Apache Tomcat versions 9.0.0.M1 to 9.0.0.M20, 8.5.0 to 8.5.14, 8.0.0.RC1 to 8.0.43, and 7.0.0 to 7.0.77.
- CVE-2017-5650High
In Apache Tomcat versions 9.0.0.M1 to 9.0.0.M18 and 8.5.0 to 8.5.12, the handling of an HTTP/2 GOAWAY frame did not close streams associated with that connection waiting for a WINDOW_UPDATE, potentially leading to exhaustion of available processing threads.
Original NVD description (English source)
While investigating bug 60718, it was noticed that some calls to application listeners in Apache Tomcat 9.0.0.M1 to 9.0.0.M17, 8.5.0 to 8.5.11, 8.0.0.RC1 to 8.0.41, and 7.0.0 to 7.0.75 did not use the appropriate facade object. When running an untrusted application under a SecurityManager, it was therefore possible for that untrusted application to retain a reference to the request or response object and thereby access and/or modify information associated with another web application.