Apache Tomcat versions 8.0.0-RC1 through 8.0.0-RC5, 7.0.0 through 7.0.47, and 6.0.0 through 6.0.37 suffer from an information disclosure vulnerability via XXE when running untrusted web applications.
e5038c902c4a597115e468b2cd9304969026597458d6fd3280891c6e2c2d59dfApache Tomcat versions prior to 7.0.8, 8.0.47, 8.5.23, and 9.0.1 (Beta) JSP upload bypass and code execution exploit.
9f631e5a320e03ca0b355844875e6306ba45407ee002501d9bd563bceca5f8a9Apache Tomcat versions prior to 9.0.1 (Beta), 8.5.23, 8.0.47, and 7.0.8 suffer from a jsp upload bypass vulnerability that allows for remote code execution.
7ffd01777edabd0ba5fd2741571567ed01b09949bb47a6972df8972e43c81251While investigating bug 60718, it was noticed that some calls to application listeners 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. Apache Tomcat versions 7.0.0 through 7.0.75, 8.0.0.RC1 through 8.0.41, 8.5.0 through 8.5.11, and 9.0.0.M1 through 9.0.0.M17 are affected.
193ab6114148905ba8825ba1b184c06507caac43be27d616db0d37daee7cc903The refactoring of the HTTP connectors for 8.5.x onwards, introduced a regression in the send file processing. If the send file processing completed quickly, it was possible for the Processor to be added to the processor cache twice. This could result in the same Processor being used for multiple requests which in turn could lead to unexpected errors and/or response mix-up. Apache Tomcat versions 8.5.0 through 8.5.12 and 9.0.0.M1 through 9.0.0.M18 are affected.
9e9a2ed68a0484d3c5eedcf6b96e3c1f556c0d256bfd0937b7b5acc81297e9efApache Tomcat version 7.0.76 suffers from a directory traversal vulnerability.
a1268dc6c01e23eaa3d4d609b9d4371d8072dc5aeae66cfb4b18621936d4b05cApache Tomcat versions 6, 7, 8, and 9 suffer from an information disclosure vulnerability.
731c512de3b9572b0d268461b83f563c6dac151dc2be51647331b04ca2296ad2Apache Tomcat versions 9.0.0.M1 to 9.0.0.M13 and 8.5.0 to 8.5.8 suffer from an information disclosure vulnerability.
87374b922774cdd9500485f33643f484d8f82656445505c941b1905db8a17768Apache Tomcat versions 8, 7, and 6 suffer from a privilege escalation vulnerability on RedHat-based distros.
12ec6d054904816f7a7adc452b470c239ac9e45d1cbea47b206cc70413667d52Apache Tomcat versions 8.0.36-2 and below, 7.0.70-2 and below, and 6.0.45+dfsg-1~deb8ul and below suffer from a local root privilege escalation vulnerability.
893a92e39c86918879337de752d3a9e073dfec764fa778ff27ab1e26ede6e1a3ResourceLinkFactory.setGlobalContext() is a public method and was accessible by web applications running under a security manager without any checks. This allowed a malicious web application to inject a malicious global context that could in turn be used to disrupt other web applications and/or read and write data owned by other web applications. Apache Tomcat versions 7.0.0 through 7.0.67, 8.0.0.RC1 through 8.0.30, and 9.0.0.M1 through 9.0.0.M2 are affected.
ac830c66f4618379f15b9c52065d4800a58e4532b36aa5e987cfc5a7dea7eb16When accessing a directory protected by a security constraint with a URL that did not end in a slash, Tomcat would redirect to the URL with the trailing slash thereby confirming the presence of the directory before processing the security constraint. It was therefore possible for a user to determine if a directory existed or not, even if the user was not permitted to view the directory. The issue also occurred at the root of a web application in which case the presence of the web application was confirmed, even if a user did not have access. Apache Tomcat versions 6.0.0 through 6.0.44, 7.0.0 through 7.0.65, and 8.0.0.RC1 through 8.0.29.
f43d6dbb774b4dfc48b17b117d3cde0c12a7d82fc18efc497696311d683c01f8When accessing resources via the ServletContext methods getResource() getResourceAsStream() and getResourcePaths() the paths should be limited to the current web application. The validation was not correct and paths of the form "/.." were not rejected. Note that paths starting with "/../" were correctly rejected. Apache Tomcat versions 6.0.0 through 6.0.44, 7.0.0 through 7.0.64, and 8.0.0.RC1 through 8.0.26.
b1f753e54e5215e5b5e3807834777c09565ba6a20e0a2b3c9fb5433a181e671aThe index page of the Manager and Host Manager applications included a valid CSRF token when issuing a redirect as a result of an unauthenticated request to the root of the web application. This token could then be used by an attacker to construct a CSRF attack. Apache Tomcat versions 7.0.1 through 7.0.67, 8.0.0.RC1 through 8.0.31, and 9.0.0.M1 are affected.
cac499db9a90243eb7e3a3ae64996e75bfc026156676e4f5e2b513a78ec60214The StatusManagerServlet could be loaded by a web application when a security manager was configured. This servlet would then provide the web application with a list of all deployed applications and a list of the HTTP request lines for all requests currently being processed. This could have exposed sensitive information from other web applications such as session IDs to the web application. Apache Tomcat versions 6.0.0 through 6.0.44, 7.0.0 through 7.0.67, 8.0.0.RC1 through 8.0.30, and 9.0.0.M1 are affected.
881ae95f3222d34f23b6f66acf5f6fe6bc505df9c7afff2901307b8b3b3a741fWhen recycling the Request object to use for a new request, the requestedSessionSSL field was not recycled. This meant that a session ID provided in the next request to be processed using the recycled Request object could be used when it should not have been. This gave the client the ability to control the session ID. In theory, this could have been used as part of a session fixation attack but it would have been hard to achieve as the attacker would not have been able to force the victim to use the 'correct' Request object. It was also necessary for at least one web application to be configured to use the SSL session ID as the HTTP session ID. This is not a common configuration. Apache Tomcat versions 7.0.5 through 7.0.65, 8.0.0.RC1 through 8.0.30, and 9.0.0.M1 are affected.
f04a5470641204db89ec17e9b80c496ffce8bd8aae7f2efd4bc0229158a89b21Apache Tomcat provides several session persistence mechanisms. The StandardManager persists session over a restart. The PersistentManager is able to persist sessions to files, a database or a custom Store. The Cluster implementation persists sessions to one or more additional nodes in the cluster. All of these mechanisms could be exploited to bypass a security manager. Session persistence is performed by Tomcat code with the permissions assigned to Tomcat internal code. By placing a carefully crafted object into a session, a malicious web application could trigger the execution of arbitrary code. Apache Tomcat versions 6.0.0 through 6.0.44, 7.0.0 through 7.0.67, 8.0.0.RC1 through 8.0.30, and 9.0.0.M1 are affected.
d8b973e72649ee49a60e92929010021e4dfc8736401a1288bdb928d8309d8597Linux kernel versions 4.4.1 and below REFCOUNT overflow / use-after free keyrings local root exploit.
ff28a80090cf606fd0d4f578152d8d24cafca71bf951cb58596dc39c575c5aaeMalicious web applications could use expression language to bypass the protections of a Security Manager as expressions were evaluated within a privileged code section. This issue only affects installations that run web applications from untrusted sources. Apache Tomcat versions 8.0.0-RC1 to 8.0.15, 7.0.0 to 7.0.57, and 6.0.0 to 6.0.43 are affected.
ae7ea53034ada919480d439f340f0f86e63c7361e273e4d38ea3034409f7672bIn very limited circumstances, it was possible for an attacker to upload a malicious JSP to a Tomcat server and then trigger the execution of that JSP. While Remote Code Execution would normally be viewed as a critical vulnerability, the circumstances under which this is possible are, in the view of the Tomcat security team, sufficiently limited that this vulnerability is viewed as important. Apache Tomcat versions 7.0.0 through 7.0.39 are affected.
b2ea73c8b10cd079ee3352350d5c7fa19457771401cedd12bbf9a02e13493849Apache Tomcat versions 8.0.0-RC1 through 8.0.0-RC5, 7.0.0 through 7.0.47, and 6.0.0 through 6.0.37 suffer from a denial of service vulnerability due to an incomplete fix for CVE-2012-3544.
8ac3ea938f07d2896bed13e92312af0a063d45b0633a23f122e4629acf2c3085Apache Tomcat versions 6.0.33 through 6.0.37 suffer from a session fixation vulnerability.
36ba52ce6c47d3e65da9ef3538ecc03acfbac6781df236369fa3d9cf1cbe32e3Apache Tomcat versions 8.0.0-RC1, 7.0.0 through 7.0.42, and 6.0.0 through 6.0.37 suffer from an information disclosure vulnerability due to an incomplete fix for CVE-2005-2090.
85aca72a0ab50801bdc11f8b35cd76f7c8566b582f96d36c721332941fd2bdccIt is possible to craft a malformed Content-Type header for a multipart request that causes Apache Commons FileUpload to enter an infinite loop. A malicious user could, therefore, craft a malformed request that triggered a denial of service. Affected include Apache Tomcat versions 7.0.0 through 7.0.50, 8.0.0-RC1 through 8.0.1, and Apache Commons FileUpload versions 1.0 through 1.3.
8dfbe0cfb95f092bd86c843cf19490a000e2626be62589af1adf0aa833f36d3cApache Tomcat version 5.5.25 suffers from a cross site request forgery vulnerability.
3b4c8cfd49efc14d10b5b4f7153524eef6ad2a708d0e0998b67b8820bfb36e18There was a scenario where elements of a previous request may be exposed to a current request. This was very difficult to exploit deliberately but fairly likely to happen unexpectedly if an application used AsyncListeners that threw RuntimeExceptions. The issue was fixed by catching the RuntimeExceptions. Apache Tomcat versions 7.0.0 through 7.0.39 are affected.
cde648eb3c646ccc296e6a2d348bb89e68c2c0471e19b83178341c84734cf58f
© 2024 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed