CVE-2026-59083
This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.
Overview
Apache Tomcat is an open-source web server and servlet container, maintained by the Apache Software Foundation, that implements the Jakarta Servlet, Jakarta Pages (JSP), Jakarta Expression Language, and Jakarta WebSocket specifications and provides a pure-Java HTTP environment for running Java web applications.
An authorization bypass vulnerability (CVE-2026-59083) has been identified in the Apache Tomcat RewriteValve, which allows requests to be mapped and checked against path-based security constraints using a different path than the one an internal rewrite actually produced. After an internal rewrite, the valve decoded the rewritten URI with form-decoding semantics that convert a literal + character into a space, so security controls based on the request path could be bypassed in some configurations.
Per OWASP: Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user's limits.
This issue affects multiple versions of Apache Tomcat below 11.0.24.
Details
Module Info
- Product: Apache Tomcat
- Affected packages: tomcat-catalina, tomcat-embed-core
- Affected versions: >=8.5.0 <=8.5.100, >=9.0.0.M1 <9.0.120, >=10.1.0-M1 <10.1.57, >=11.0.0-M1 <11.0.24
- GitHub repository: https://github.com/apache/tomcat
- Published packages:
- Package manager: Maven
- Fixed in:
- NES for Apache Tomcat 8.5.100-tomcat-8.5.108
- Apache Tomcat 11.0.24, 10.1.57, 9.0.120 (OSS)
Vulnerability Info
This Low-severity vulnerability is found in the tomcat-catalina and tomcat-embed-core packages in Apache Tomcat, in the org.apache.catalina.valves.rewrite rewrite engine. The RewriteValve lets a deployer rewrite, redirect, or block requests using a rewrite.config file modeled on Apache mod_rewrite. When a rule performs an internal rewrite (rather than a redirect), the valve decodes and re-normalizes the rewritten URI so the request can be mapped and processed under its new path.
That decode used java.net.URLDecoder:
// Rewriting may have denormalized the URL and added encoded characters
// Decode then normalize
String urlStringRewriteDecoded = URLDecoder.decode(urlStringRewriteEncoded, uriCharset.name());
java.net.URLDecoder implements application/x-www-form-urlencoded decoding, in which a + character represents a space. Those semantics are correct for query strings and form bodies but not for URI paths, where a literal + is a valid character, and the rewrite engine's default encoding leaves + unescaped in rewritten paths.
As a result, when the rewritten URI contains a literal +, the decoded URI that Tomcat then uses for servlet mapping and security-constraint evaluation contains a space, while the encoded request URI keeps the +. The request is mapped and authorized against a different path than the one the rewrite produced, so path-based security controls involving such segments can be sidestepped or misapplied. Exploitation requires the RewriteValve to be enabled with at least one rule that performs an internal rewrite, and the practical impact depends on the deployer's specific rewrite rules and security-constraint layout, which is why this CVE was assigned a Low severity by the Apache Tomcat security team.
Mitigation
Only recent versions of Apache Tomcat are community-supported. The community support version will not receive any updates to address this issue. For more information, see here.
Users of the affected components should apply one of the following mitigations:
- Upgrade to a patched version of Apache Tomcat.
- Leverage a commercial support partner like HeroDevs for post-EOL security support.
Credits
- Apache Tomcat security team