ALAS-2025-2812

When serving resources from a network location using the NTFS file system, Apache Tomcat versions 10.0.0-M1 to 10.0.0-M9, 9.0.0.M1 to 9.0.39, 8.5.0 to 8.5.59 and 7.0.0 to 7.0.106 were susceptible to JSP source code disclosure in some configurations. The root cause was the unexpected behaviour of the JRE API File.getCanonicalPath() which in turn was caused by the inconsistent behaviour of the Windows API (FindFirstFileW) in some circumstances. (CVE-2021-24122)

Incomplete Cleanup vulnerability in Apache Tomcat. When recycling various internal objects in Apache Tomcat from 11.0.0-M1 through 11.0.0-M11, from 10.1.0-M1 through 10.1.13, from 9.0.0-M1 through 9.0.80 and from 8.5.0 through 8.5.93, an error could cause Tomcat to skip some parts of the recycling process leading to information leaking from the current request/response to the next. Users are recommended to upgrade to version 11.0.0-M12 onwards, 10.1.14 onwards, 9.0.81 onwards or 8.5.94 onwards, which fixes the issue. (CVE-2023-42795)

Path Equivalence: 'file.Name' (Internal Dot) leading to Remote Code Execution and/or Information disclosure and/or malicious content added to uploaded files via write enabled Default Servlet in Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.2, from 10.1.0-M1 through 10.1.34, from 9.0.0.M1 through 9.0.98.

If all of the following were true, a malicious user was able to view security sensitive files and/or inject content into those files:
- writes enabled for the default servlet (disabled by default)
- support for partial PUT (enabled by default)
- a target URL for security sensitive uploads that was a sub-directory of a target URL for public uploads
- attacker knowledge of the names of security sensitive files being uploaded
- the security sensitive files also being uploaded via partial PUT

If all of the following were true, a malicious user was able to perform remote code execution:
- writes enabled for the default servlet (disabled by default)
- support for partial PUT (enabled by default)
- application was using Tomcat's file based session persistence with the default storage location
- application included a library that may be leveraged in a deserialization attack

Users are recommended to upgrade to version 11.0.3, 10.1.35 or 9.0.98, which fixes the issue.

More justification and the patch links are available for all versions here:
[1] https://tomcat.apache.org/security-11.html
[2] https://tomcat.apache.org/security-10.html
[3] https://tomcat.apache.org/security-9.html (CVE-2025-24813)

noarch:
    tomcat-7.0.76-10.amzn2.0.10.noarch
    tomcat-admin-webapps-7.0.76-10.amzn2.0.10.noarch
    tomcat-docs-webapp-7.0.76-10.amzn2.0.10.noarch
    tomcat-javadoc-7.0.76-10.amzn2.0.10.noarch
    tomcat-jsvc-7.0.76-10.amzn2.0.10.noarch
    tomcat-jsp-2.2-api-7.0.76-10.amzn2.0.10.noarch
    tomcat-lib-7.0.76-10.amzn2.0.10.noarch
    tomcat-servlet-3.0-api-7.0.76-10.amzn2.0.10.noarch
    tomcat-el-2.2-api-7.0.76-10.amzn2.0.10.noarch
    tomcat-webapps-7.0.76-10.amzn2.0.10.noarch

src:
    tomcat-7.0.76-10.amzn2.0.10.src