CVE-2025-55752

What it actually does

This is a relative path traversal and access-control bypass in Apache Tomcat URL rewriting behavior. A regression caused rewritten URLs to be normalized before decoding, allowing specially encoded request URIs to be interpreted differently after rewrite processing. When an application uses rewrite rules that move query parameters into the request path, an attacker may be able to bypass security constraints that should protect internal locations such as /WEB-INF/ and /META-INF/. In the most severe configuration, if HTTP PUT is enabled for a user or endpoint, the attacker may be able to write a server-side file such as a JSP into a reachable application path, which can lead to remote code execution under the Tomcat process account. The issue affects Tomcat 11.0.0-M1 through 11.0.10, 10.1.0-M1 through 10.1.44, 9.0.0.M11 through 9.0.108, and known end-of-life 8.5.6 through 8.5.100 versions.

Why it matters to the business

Successful exploitation can expose protected application resources, bypass intended access controls, allow unauthorized modification of web content, and in high-risk deployments lead to full application server compromise. Because Tomcat commonly hosts business-critical Java applications, compromise could result in data theft, service disruption, credential exposure, lateral movement, or malicious code running inside trusted application infrastructure. The CVSS score is high and the EPSS score is elevated, indicating meaningful exploitation likelihood even though it is not currently listed in CISA KEV and no mature public exploit is indicated. Environments that enable PUT, use URL rewrite rules, or still run end-of-life Tomcat 8.5 should treat this as urgent.

How an attack unfolds

An attacker first identifies a Tomcat instance running an affected version and determines whether the application uses rewrite rules that transform query string values into URL paths. The attacker then sends crafted requests containing encoded traversal or encoded protected path components. Because the vulnerable rewrite flow normalizes the URL before decoding it, the request can resolve after decoding to a path that should have been blocked by Tomcat security constraints, including locations under /WEB-INF/ or /META-INF/. If only read access is possible, the attacker may retrieve protected resources such as configuration files, classpath metadata, or application internals. If PUT is enabled and the attacker has sufficient privileges to use it, the attacker can attempt to upload a malicious file into a web-accessible location and then request that file to execute code in the context of the Tomcat process.

How to fix it

Upgrade Apache Tomcat to a fixed release: 11.0.11 or later for the 11.x branch, 10.1.45 or later for the 10.1.x branch, or 9.0.109 or later for the 9.x branch. Tomcat 8.5 is end-of-life and known affected from 8.5.6 through 8.5.100; migrate to a supported fixed branch rather than relying on 8.5 mitigations. For source-based deployments, ensure the Apache Tomcat code includes the fixing commit 312541e51725cdfe98d8cc6414b31d36d913fdd1 or a later vendor release containing it. Review and reduce use of rewrite rules that place query parameters into URL paths, especially where protected paths or authorization rules depend on the resulting URI. Disable HTTP PUT unless explicitly required; where PUT is required, restrict it to authenticated and authorized principals, narrow allowed paths, and block writes to executable web application locations. Add compensating controls at reverse proxies or WAFs to reject encoded traversal sequences and encoded access to /WEB-INF/ and /META-INF/. For vendor-packaged products, apply vendor-fixed builds where relevant, including the listed Red Hat package fixes such as openshift-console 0:0.0.16-1.el6op and other fixed packages provided by the vendor advisory.

How to confirm the fix worked

Confirm all Tomcat runtimes report fixed versions: 11.0.11+, 10.1.45+, or 9.0.109+. Verify there are no remaining Tomcat 8.5.x deployments unless they have been replaced by a supported fixed branch. Inspect server.xml, web.xml, context configuration, deployed application rewrite configuration, and reverse proxy rewrite rules for patterns that rewrite query parameter values into paths. Confirm HTTP PUT is disabled where unnecessary by testing with an OPTIONS request and by reviewing servlet and proxy configuration. For applications that require PUT, verify authorization is enforced and writes cannot land in executable web roots, /WEB-INF/, /META-INF/, or deployment directories. Perform a safe validation test using encoded traversal and encoded /WEB-INF/ or /META-INF/ path probes and confirm the server returns a denial or not-found response consistently before and after decoding/rewrite handling. Review package inventories and container images to ensure fixed Tomcat artifacts are present and no vulnerable embedded Tomcat libraries remain.

Typical attack path

1. Scan internet-facing or internal web applications for Apache Tomcat version exposure and URL rewrite behavior.
2. Identify applications whose rewrite rules place query parameter values into the request URI path.
3. Send crafted requests with encoded path traversal or encoded protected directory names to test whether /WEB-INF/ or /META-INF/ protections can be bypassed.
4. Retrieve protected application resources if access-control bypass is successful.
5. If HTTP PUT is enabled, upload a server-side payload such as a JSP or modified application resource.
6. Request the uploaded file to execute commands or establish persistence under the Tomcat service account.
7. Use the compromised application server to access application data, credentials, internal services, or adjacent systems.

How to detect it

Check for prior exploitation using Tomcat access logs, reverse proxy logs, WAF logs, application logs, endpoint telemetry, file integrity monitoring, and operating system audit logs. Focus on requests containing encoded traversal sequences, double-encoded characters, or encoded references to protected Tomcat directories such as /WEB-INF/ and /META-INF/. Review all HTTP PUT activity, especially successful PUT responses or PUT requests followed by GET requests to newly created JSP or class resources. Investigate requests where query parameters appear to contain path fragments, encoded slashes, encoded dots, or protected directory names and are processed through application rewrite rules. On hosts, compare deployed application directories against known-good release artifacts and look for newly created or modified JSP, class, JAR, WAR, XML, or properties files. Examine whether the Tomcat Java process spawned shell interpreters or utilities, made unusual outbound connections, or wrote files outside normal deployment workflows. Since no named threat actor or KEV exploitation is currently associated with this CVE, prioritize behavior-based detection over actor-specific indicators.

• %2e%2e
• %252e%252e
• ..%2f
• ..%5c
• %2fWEB-INF%2f
• %2fMETA-INF%2f
• %252fWEB-INF%252f
• %252fMETA-INF%252f
• /WEB-INF/
• /META-INF/
• PUT /
• "PUT
• " 201
• " 204
• .jsp
• /webapps/
• /WEB-INF/web.xml
• /META-INF/MANIFEST.MF
• $CATALINA_BASE/webapps/
• $CATALINA_HOME/webapps/
• localhost_access_log
• java.lang.ProcessBuilder
• Runtime.getRuntime
• /bin/sh
• cmd.exe

What your security team should do

• Immediately inventory externally exposed and business-critical Tomcat servers and identify versions 11.0.0-M1 through 11.0.10, 10.1.0-M1 through 10.1.44, 9.0.0.M11 through 9.0.108, and any 8.5.x deployments.
• Prioritize patching systems with URL rewrite rules, enabled PUT methods, administrative portals, file upload workflows, or internet exposure.
• Upgrade Tomcat to 11.0.11+, 10.1.45+, or 9.0.109+; migrate end-of-life 8.5 deployments to a supported branch.
• Disable or tightly restrict HTTP PUT and ensure uploaded content cannot be executed by the application server.
• Review rewrite rules for query-parameter-to-path transformations and remove or harden risky patterns.
• Deploy temporary WAF or reverse proxy rules to block encoded traversal sequences and encoded references to /WEB-INF/ and /META-INF/ until patching is complete.
• Search historical logs for suspicious encoded path traversal, access to protected directories, and successful PUT requests, especially responses with 200, 201, 204, or 207 status codes.
• Inspect web application directories for recently created JSPs, class files, JARs, or modified deployment artifacts that do not match expected releases.
• Monitor Tomcat process behavior for unusual child processes, outbound network connections, or file writes in application deployment paths.
• Because EPSS is elevated, maintain heightened monitoring even though the CVE is not currently in CISA KEV and no mature exploit is reported.