CVE-2025-31651

What it actually does

This vulnerability is an authorization bypass in Apache Tomcat’s rewrite rule handling. In uncommon configurations where Tomcat rewrite rules are used to enforce security controls, a specially crafted HTTP request can cause those rewrite rules to evaluate differently than intended because escape, meta, or control sequences are not neutralized correctly. The result is that a request that should have been blocked, redirected, normalized, or routed to an access-controlled path may bypass the rewrite-based constraint. The issue affects Apache Tomcat 11.0.0-M1 through 11.0.5, 10.1.0-M1 through 10.1.39, and 9.0.0.M1 through 9.0.102.

Why it matters to the business

Organizations that rely on Tomcat rewrite rules as part of access control could unintentionally expose restricted web paths, administrative interfaces, internal application routes, or protected resources. The practical severity depends heavily on configuration: deployments using rewrite rules only for cosmetic redirects or URL normalization are less exposed, while deployments using rewrite rules to enforce authentication, authorization, tenant separation, IP restrictions, or request blocking have higher risk. The issue is not currently listed in CISA KEV and has no known public exploit maturity in the provided data, with a modest EPSS score, but it has been public for a long time and should be remediated during normal patch cycles, faster for internet-facing Tomcat services using RewriteValve or rewrite-based security controls.

How an attack unfolds

An attacker first identifies an application running an affected Apache Tomcat version and looks for behavior suggesting rewrite rules are in use, such as URL redirects, path normalization, blocked paths, or rule-driven routing differences. They then send crafted HTTP requests containing encoded, escaped, meta, or control-sequence-like path components designed to alter how Tomcat’s rewrite processing interprets the request. If the application’s security model depends on rewrite rules to deny access, redirect unauthenticated users, block sensitive paths, or constrain request routing, the crafted request may avoid the intended rule match. Successful exploitation allows the attacker to reach a resource or application route that the rewrite rule was intended to protect. The vulnerability does not by itself provide code execution; impact depends on what the bypassed rewrite rule protected.

How to fix it

Upgrade Apache Tomcat to a fixed version: 9.0.104 or later for the 9.x branch, 10.1.40 or later for the 10.x branch, or 11.0.6 or later for the 11.x branch. For source-based deployments, ensure the Tomcat code includes the fix corresponding to commit f8cfae0a0d1c8dc592099a1430cd08e352430823 or a later release tag. For Red Hat packaged components listed in the advisory, update to the fixed package versions, including rh-dotnet60-aspnetcore-runtime-6.0 0:6.0.24-1.el7_9, rh-dotnet60-dotnet 0:6.0.124-1.el7_9, rh-dotnet60-dotnet-sdk-6.0 0:6.0.124-1.el7_9, and the other fixed 0:6.0.24-1.el7_9 or 0:6.0.124-1.el7_9 package builds as applicable. As a mitigation until patching is complete, review Tomcat RewriteValve and rewrite.config usage and do not rely on rewrite rules as the sole enforcement point for authentication, authorization, or sensitive path protection. Move security enforcement into the application, servlet security constraints, upstream identity-aware proxies, or web server access-control mechanisms that canonicalize requests consistently.

How to confirm the fix worked

Confirm the running Tomcat version is no longer in an affected range: versions should be 9.0.104 or later, 10.1.40 or later, or 11.0.6 or later. Verify packaged installations report the fixed vendor package versions. Review configuration for RewriteValve usage in server.xml, context.xml, or application context configuration, and inspect rewrite.config files to identify whether any rewrite rule acts as a security control. Test representative protected routes with encoded path separators, escaped characters, unusual delimiters, and control-character encodings to confirm blocked or redirected resources remain blocked after upgrade. Validate that authorization is enforced by application or platform security controls even if rewrite rules are disabled or bypassed in a test environment.

Typical attack path

1. Identify an exposed web application or service running an affected Apache Tomcat release.
2. Fingerprint rewrite behavior by testing redirects, blocked URLs, normalized paths, and alternate encodings.
3. Craft requests containing encoded or escaped characters intended to change rewrite rule matching behavior.
4. Send requests to paths protected or transformed by Tomcat rewrite rules.
5. Observe whether the request bypasses an expected deny, redirect, authentication gate, or routing constraint.
6. If successful, access restricted application functionality or data reachable behind the bypassed rule.

How to detect it

Review Tomcat access logs, upstream reverse proxy logs, WAF logs, and application authentication/authorization logs for requests to sensitive or normally restricted paths containing unusual encoded characters, double-encoding, escaped separators, path parameters, or control-character encodings. Focus on requests that should have been denied or redirected but instead returned HTTP 200, 204, 206, 3xx to an internal destination, or application-specific success responses. Compare pre- and post-upgrade behavior for protected routes to identify anomalous successes. Inspect Tomcat configuration for RewriteValve and rewrite.config files to determine whether rewrite rules were used as security controls during the exposure window. Where available, correlate suspicious requests with authentication state, session creation, privilege checks, and downstream application events to determine whether a bypass led to access to restricted resources. There are no named threat actors or KEV/ransomware exploitation signals in the provided data, so detection should be behavior-based rather than actor-specific.

What your security team should do

• Inventory internet-facing and internal Apache Tomcat deployments and identify versions in the affected 9.x, 10.x, and 11.x ranges.
• Prioritize patching Tomcat instances that use RewriteValve or rewrite.config, especially where rewrite rules block sensitive paths, enforce redirects to login, restrict administrative routes, or implement IP/path-based access controls.
• Upgrade to Tomcat 9.0.104, 10.1.40, 11.0.6, or later, and apply fixed vendor packages where Tomcat is bundled or redistributed.
• Review rewrite rules and remove any dependency on rewrite logic as the only authorization boundary.
• Add regression tests for protected URLs using encoded and malformed path variants to ensure access-control decisions are made after consistent canonicalization.
• Search historical access logs for unusual encoded or control-character request paths targeting sensitive endpoints, especially requests that returned 200, 3xx, or application-specific success responses where denial was expected.
• Monitor for repeated probing of URL-encoded path variants, alternate separators, semicolon path parameters, double-encoding, and requests targeting restricted paths.