| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| org.apache.tomcat:tomcat-catalina | maven | >= 11.0.0-M1, <= 11.0.7 | 11.0.8 |
| org.apache.tomcat:tomcat-catalina | maven | >= 10.1.0-M1, <= 10.1.41 | 10.1.42 |
| org.apache.tomcat:tomcat-catalina | maven | >= 9.0.0.M1, <= 9.0.105 | 9.0.106 |
| org.apache.tomcat.embed:tomcat-embed-core | maven | >= 11.0.0-M1, <= 11.0.7 | 11.0.8 |
| org.apache.tomcat.embed:tomcat-embed-core | maven | >= 10.1.0-M1, <= 10.1.41 | 10.1.42 |
| org.apache.tomcat.embed:tomcat-embed-core | maven | >= 9.0.0.M1, <= 9.0.105 | 9.0.106 |
The vulnerability lies in how Apache Tomcat handled paths for PreResources or PostResources when they were mounted at a location other than the web application's root. Specifically, the path.startsWith(webAppMount) check used in several methods within AbstractArchiveResourceSet and DirResourceSet was too permissive. This allowed an attacker to craft a path that would satisfy this check but would not be a legitimate sub-path of the mounted resource. For example, if a resource was mounted at /app/secure, a request for /app/securedirectory (note the missing trailing slash after 'secure') could be misinterpreted as being part of the /app/secure mount due to the startsWith check. This could lead to bypassing security constraints that were intended to protect resources under /app/secure/. The patch addresses this by introducing a new method, isPathMounted(String path, String webAppMount), in AbstractResourceSet.java. This method performs a more stringent check: it ensures that if path starts with webAppMount, then either path is identical to webAppMount, or the character immediately following webAppMount in path must be a forward slash ('/'). This prevents the aforementioned path confusion. The vulnerable functions are those that previously used the path.startsWith() check and were modified to use the new isPathMounted() method. These functions are involved in listing, retrieving, creating, and writing resources, and their exploitation could lead to an authentication bypass by accessing resources through an unexpected, less-secured path.