CVE-2025-46701

What it actually does

CVE-2025-46701 is an authorization bypass in Apache Tomcat’s CGI servlet caused by improper handling of URI path case sensitivity. When applications rely on Tomcat security constraints that apply to the pathInfo portion of a URI mapped to the CGI servlet, an attacker may be able to alter the case of the requested path to avoid matching the intended constraint. The flaw does not inherently provide code execution, but it can allow unauthenticated or underprivileged access to CGI-backed resources that were intended to be protected by web.xml security constraints or equivalent configuration. Affected Tomcat versions are 11.0.0-M1 through 11.0.6, 10.1.0-M1 through 10.1.40, and 9.0.0.M1 through 9.0.104.

Why it matters to the business

Organizations using Apache Tomcat with the CGI servlet enabled and security constraints applied to CGI pathInfo routes could unintentionally expose restricted CGI functionality or sensitive resources. The business risk depends heavily on what the protected CGI endpoint does: exposure could range from information disclosure to unauthorized administrative actions or access to internal tooling. The issue is not currently listed in CISA KEV, has no reported ransomware association, and the provided exploit maturity is none, but it has been public for an extended period and Tomcat is widely deployed, so exposed CGI configurations should still be reviewed and upgraded promptly.

How an attack unfolds

An attacker first identifies a Tomcat instance with the CGI servlet enabled and discovers or guesses a CGI-mapped URI that has security constraints on its pathInfo component. The attacker then sends requests that vary the capitalization of portions of the pathInfo value. Because the vulnerable Tomcat versions mishandle case sensitivity when evaluating these constraints, the modified URI may not match the intended protected path rule while still routing to the CGI servlet. If successful, the server processes the CGI request without enforcing the expected authentication or authorization requirement, giving the attacker access to functionality or data that should have required valid credentials or a higher privilege level.

How to fix it

Upgrade Apache Tomcat to a fixed release: 11.0.7 or later, 10.1.41 or later, or 9.0.105 or later. For source-based deployments, ensure the fix commit 15c524d11651708bc046929139e6b633f2a50fb5 or later is included. If immediate upgrade is not possible, disable the CGI servlet if it is not required, remove or restrict CGI servlet mappings, place affected CGI routes behind an external access control layer, and review security constraints that depend on pathInfo matching. Ensure any compensating controls normalize or strictly validate URI paths before authorization decisions are made.

How to confirm the fix worked

Confirm the running Tomcat version is not in an affected range and is at least 11.0.7, 10.1.41, or 9.0.105 depending on the deployed branch. Review configuration files such as conf/web.xml, application WEB-INF/web.xml files, and context-specific configuration for org.apache.catalina.servlets.CGIServlet or CGI servlet mappings. If CGI is enabled, test representative protected CGI URLs by changing the case of pathInfo components and verifying that the same authentication and authorization decisions are enforced for every case variation. Also verify that expected security constraints still apply after upgrade and that no CGI endpoints are reachable without the intended credentials.

Typical attack path

1. Identify an Apache Tomcat server exposed over HTTP or HTTPS.
2. Determine whether the CGI servlet is enabled and reachable.
3. Find or infer CGI servlet mappings and pathInfo-based protected routes.
4. Send requests to protected CGI paths using alternate letter casing in the pathInfo component.
5. Observe whether authentication prompts, authorization failures, or expected access controls are bypassed.
6. Use the bypassed CGI functionality to access restricted output, invoke scripts, or perform actions available through the CGI endpoint.

How to detect it

To assess possible prior exploitation, review HTTP access logs, reverse proxy logs, WAF logs, and Tomcat localhost/access logs for requests to CGI servlet mappings where the pathInfo portion uses unusual or inconsistent capitalization. Compare mixed-case requests against the canonical protected paths defined in web.xml security constraints and look for successful HTTP 200, 2xx, or 3xx responses where 401 or 403 responses would normally be expected. Focus on externally sourced requests, repeated casing variations against the same CGI path, and sequences where an attacker first receives 401/403 and then receives success after changing case. Also review CGI script execution logs, application logs, and operating system process accounting for unexpected CGI script invocation corresponding to those requests. No named threat actor exploitation or CISA KEV activity was provided for this issue, so detection should focus on behavioral evidence rather than actor-specific indicators.

• org.apache.catalina.servlets.CGIServlet
• /cgi-bin/
• /WEB-INF/cgi/
• 200
• 401
• 403
• GET /cgi
• POST /cgi
• GET /cgi-bin/
• POST /cgi-bin/

What your security team should do

• Inventory Tomcat instances and prioritize those exposed to untrusted networks or the internet.
• Identify deployments with the CGI servlet enabled; systems without CGI servlet usage are unlikely to be practically affected by this flaw.
• Upgrade affected Tomcat branches to 11.0.7+, 10.1.41+, or 9.0.105+ as appropriate.
• Disable the CGI servlet wherever it is not explicitly required.
• Review CGI servlet mappings and security constraints that apply to pathInfo routes for case-sensitive bypass risk.
• Add targeted regression tests for protected CGI paths using mixed-case URI variants.
• Search historical access logs for mixed-case requests to CGI paths, especially requests that returned successful responses where authorization failures were expected.
• Monitor for probing of CGI endpoints and unusual access to scripts or protected resources until patching is complete.