CVE-2026-59083: Tomcat RewriteValve URL Encoding Bypass and Security Constraint Risk

CVE-2026-59083 is an Apache Tomcat RewriteValve vulnerability caused by incorrect handling of a literal plus sign in rewritten URIs. In affected releases, the RewriteValve could decode + as a space after processing a rewrite rule. That representation change could undermine a security control when routing, path restrictions, tenant boundaries, or access decisions depended on the rewritten URI remaining unchanged.

The vulnerability is real, remotely reachable in relevant deployments, and fixed in current Tomcat releases. It is not, however, a universal Tomcat authentication bypass. Apache describes the issue as a security-control bypass affecting “some configurations,” rates it Low, and does not characterize it as remote code execution. Practical exposure requires more than an affected version number: RewriteValve must be active, the relevant request must pass through the vulnerable code path, and the configuration must attach security meaning to a URI whose interpretation changes when + becomes a space. (SecLists)(SecLists)t configuration dependence is also why CVE-2026-59083 is easy to mishandle. A vulnerability scanner may report a high numerical score and create an urgent ticket without proving that RewriteValve is present. Another team may see Apache’s Low rating and postpone an upgrade even though its own rewrite rules protect an administrative route or tenant namespace. Neither response is sufficient. The correct decision comes from combining version inventory, RewriteValve configuration review, path-semantics analysis, safe behavioral testing, and prompt patching.

CVE-2026-59083 at a Glance

Campo	Verified information	Significado operacional
Vulnerabilidade	Improper handling of URL encoding in Apache Tomcat RewriteValve	A rewritten URI could be interpreted differently from the URI the rule intended to produce
Specific behavior	A literal + could be decoded to a space	Path identity may change after rule processing
CWE	CWE-177, Improper Handling of URL Encoding	The weakness concerns unsafe or incorrect interpretation of encoded characters
Apache severity	Baixa	Apache considers the dangerous configuration set limited
NVD status	No independent NIST CVSS assessment was shown at publication	NVD’s own score should not be inferred from the third-party score displayed on the page
CISA-ADP CVSS on NVD	9.1, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N	A worst-case generic model assumes a reachable configuration with major confidentiality and integrity impact
Public disclosure	July 14, 2026	The issue became public after fixed releases were available
Fixed Tomcat 11 version	11.0.24	Upgrade Tomcat 11 deployments to this release or later
Fixed Tomcat 10.1 version	10.1.57	Upgrade Tomcat 10.1 deployments to this release or later
Fixed Tomcat 9 version	9.0.120	Upgrade Tomcat 9 deployments to this release or later
Tomcat 8.5	8.5.0 through 8.5.100 listed as affected	The branch is end-of-life; migrate to a supported branch
Main exposure condition	RewriteValve and security-relevant rewrite behavior	A vulnerable package alone does not prove an exploitable policy bypass
Direct RCE	Not stated by Apache	Do not promote the issue to RCE without a separate, demonstrated application-specific chain

Apache says the Tomcat security team identified the issue on June 26, 2026, fixed it in the maintained branches, and publicly disclosed it on July 14. Tomcat 11.0.24, 10.1.57, and 9.0.120 contain the branch-specific fixes. The CVE record also lists Tomcat 8.5.0 through 8.5.100 and warns that other unsupported versions may be affected. (Apache Tomcat)(Apache Tomcat)What CVE-2026-59083 Actually Does

Tomcat’s RewriteValve provides URL rewriting behavior similar to Apache HTTP Server’s mod_rewrite. Administrators can install it at the Host level or within an individual web application’s Context. The valve reads a rewrite.config file containing RewriteRule e RewriteCond directives and can transform a request URI before the request reaches its final resource mapping. (Apache Tomcat)(Apache Tomcat)t feature is commonly used for benign purposes: redirecting an old URL, adding a canonical prefix, mapping user-friendly paths to internal routes, or maintaining compatibility after an application migration. It can also acquire security significance. A rule may reject access to an internal prefix, prevent a request from entering a legacy handler, segregate tenant paths, or require a property such as a trusted host before rewriting to a sensitive endpoint.

CVE-2026-59083 appears in the processing after a rewrite has produced a new URI. The affected implementation used Java’s java.net.URLDecoder to decode that rewritten value. URLDecoder is designed around HTML form decoding rules. Its documented behavior converts a plus sign to a space, because application/x-www-form-urlencoded conventionally represents a space as +. (Oracle Docs)(Oracle Docs)t behavior is appropriate when decoding a form field or query parameter produced under those rules. It is not a safe universal assumption for every URI component. A literal plus sign can be a meaningful character in a path segment. Treating it as a form-encoded space changes the identifier.

The Apache fix replaced URLDecoder.decode with Tomcat’s UDecoder.URLDecode in the RewriteValve path. The commit message describes the defect as an unintentional conversion of + to a space during rule processing. Apache also added a regression test using the segment a+b, confirming that preservation of the literal plus sign is central to the fix. (GitHub)(GitHub) essential failure can therefore be expressed without an exploit payload:

Rewrite rule intends:  /tenant/a+b/dashboard
Vulnerable decoding:   /tenant/a b/dashboard
Expected decoding:     /tenant/a+b/dashboard

Whether that difference becomes a security issue depends on what each representation means to the surrounding system. If neither path exists and no policy relies on the distinction, the request may simply fail. If one representation is public and the other resolves to a protected or different resource, the same decoding error can become an authorization problem.

What the Vulnerability Does Not Prove

An affected Tomcat version does not establish that an attacker can bypass authentication. It establishes that the installation contains vulnerable RewriteValve code.

A public Tomcat banner does not establish that RewriteValve is configured. The valve is an optional component. Many applications never enable it.

The presence of rewrite.config does not establish that a security control is bypassable. The rules may only issue harmless redirects or normalize public paths.

A literal plus sign in a request does not establish exploitation. Plus signs are legitimate in path segments, search terms, identifiers, file names, generated slugs, and application data.

A response difference between + e %20 does not automatically prove CVE-2026-59083. Applications may intentionally treat those resources differently, and upstream proxies, frameworks, routers, or custom middleware may perform their own decoding.

The vulnerability also does not automatically produce remote code execution. Apache’s advisory describes a configuration-dependent security-control bypass, not code execution. A downstream application could theoretically expose a dangerous operation after an authorization failure, but that would be an additional chain requiring separate evidence. (SecLists)(SecLists)s distinction matters because Tomcat has had other RewriteValve vulnerabilities with more specific consequences. CVE-2025-55752, for example, involved normalization before decoding and could bypass protections for /WEB-INF/ e /META-INF/; remote code execution was possible only when additional conditions, including enabled PUT behavior, were present. CVE-2026-59083 is not a new name for that vulnerability and should not inherit its RCE description. (NVD)(NVD)Why +, %2Be %20 Are Not Interchangeable

URI processing becomes dangerous when multiple representations are collapsed without respect for component semantics.

RFC 3986 divides a URI into components such as scheme, authority, path, query, and fragment. It also distinguishes reserved characters, unreserved characters, and percent-encoded octets. The plus sign belongs to the reserved character set. Its meaning depends on the component and the protocol or application using it. RFC 3986 does not establish a global rule that every plus sign in every path is a space. (Editor de RFC)(Editor de RFC)L form encoding adds another convention. In application/x-www-form-urlencoded data, a space is commonly serialized as +, and a literal plus sign is encoded as %2B. Java’s URLDecoder implements that form-decoding model. The class documentation explicitly says that + becomes a space and %xy sequences become decoded bytes. (Oracle Docs)(Oracle Docs)se rules create three distinct inputs:

Input	Typical intended meaning in a URI path	Form-style decoding result
a+b	Literal segment containing a plus sign	a b
a%2Bb	Percent-encoded literal plus sign	a+b
a%20b	Segment containing an encoded space	a b

The first and third values are not generally identical at the path level. A file named a+b is not necessarily a file named a b. A tenant named team+east is not necessarily a tenant named team east. A route /reports/q1+q2 is not necessarily /reports/q1 q2.

The vulnerable RewriteValve behavior could erase that distinction after a rule produced the rewritten URI. This is a canonicalization problem: one part of the system makes a decision about one representation, while a later part acts on another.

Canonicalization defects are especially dangerous in access control because security checks are often exact comparisons. Consider a policy that denies one route and permits another:

Denied:  /internal/team east
Allowed: /public/team+east

If a rewrite operation produces /public/team+east but a later decoder changes the plus to a space, the application no longer receives the identifier evaluated by the rewrite logic. The resulting path may miss a route, reach a fallback route, match a broader pattern, or map to a resource with different authorization requirements.

The direction of impact is configuration-specific. The change might turn an allowed path into a denied one, producing only a functional bug. It might turn a denied logical identity into an allowed one. It might cause a request to reach a default handler. It might alter a cache key or a tenant lookup. The CVE record does not specify a single universal route pattern because the vulnerable outcome depends on the local rewrite and application design. (NVD)(NVD)Where RewriteValve Sits in the Request Path

A simplified Tomcat request flow looks like this:

Client request target
        |
        v
Connector parsing and URI validation
        |
        v
Host and Context selection
        |
        v
RewriteValve rule evaluation
        |
        v
Rewritten URI construction
        |
        v
URI decoding and normalization
        |
        v
Servlet mapping and application routing
        |
        v
Authentication, authorization, and business logic

Real deployments may add a CDN, load balancer, WAF, API gateway, ingress controller, service mesh, reverse proxy, authentication proxy, or framework router. Each layer may log, decode, reject, normalize, or re-encode the URI.

That creates several possible representations of one request:

Raw request target from the client
Proxy-observed request URI
Proxy-normalized path
Tomcat connector request URI
RewriteValve input
RewriteValve replacement output
Decoded rewritten path
Normalized path
Servlet path
Path info
Framework route
Application resource identifier

A secure design does not require every layer to preserve exactly the same string. Decoding and normalization are necessary. It does require each transformation to have defined semantics and to avoid changing the security identity of a request after a control has approved it.

Tomcat’s RewriteValve documentation notes that the URL presented to the valve is aligned with the URL used for request mapping, with literal %, ;e ? characters represented in percent-encoded form. It also instructs rules that insert certain literal special characters to use their encoded forms. These details show that the component already operates at a boundary where encoded and decoded representations must be managed carefully. (Apache Tomcat)(Apache Tomcat) vulnerable code violated that boundary by applying a form-oriented decoder to a rewritten path value. The fix is conceptually small because the correct decoder already existed inside Tomcat. The security significance comes from where the call occurred, not from the number of changed lines.

The Root Cause in the Apache Patch

Apache’s Tomcat 11 fix changed three files: RewriteValve.java, its test class, and the changelog. The security-relevant modification replaced this conceptual operation:

URLDecoder.decode(rewrittenUri, charset)

with Tomcat’s URI-oriented decoder:

UDecoder.URLDecode(rewrittenUri, charset)

The old Java API treats the input as form-encoded data and translates + to a space. Tomcat’s decoder preserves a literal plus sign while handling percent-encoded sequences according to the URI processing behavior expected by the container. The added test passes a+b through the rewrite encoding test path so future changes cannot silently reintroduce the conversion. (GitHub)(GitHub) fix occurs after RewriteValve has assembled the rewritten string and before Tomcat normalizes the resulting path. That placement is important. The rewrite operation may introduce encoded characters, so the implementation needs to decode them before normalizing the path. Removing decoding entirely would not be a sound general fix. The correct repair is to decode with URI semantics rather than form semantics.

The vulnerable sequence can be modeled as:

1. Receive a URI representation.
2. Match RewriteRule and RewriteCond directives.
3. Produce a rewritten URI.
4. Encode or preserve special characters used during rewriting.
5. Decode the rewritten URI.
6. Normalize the decoded path.
7. Continue request mapping.

The defect was in step 5. A character-preservation error at that point changed the input to step 6 and every downstream component.

This pattern is broader than Tomcat. Security failures often appear when developers use a convenient generic utility for a more specific protocol component:

• A form decoder is used for a path.
• A file-system normalizer is used for a URL.
• A query parser is used before signature verification.
• A Unicode case conversion is performed after an allowlist check.
• A proxy decodes once while an origin decodes twice.
• A security filter examines the raw value while a router uses a normalized value.

The resulting code can appear reasonable in isolation. The danger emerges from disagreement between layers.

Versões afetadas e corrigidas

The supported branches have direct upgrade targets.

Tomcat branch	Versões afetadas	First fixed version	Ação recomendada
Tomcat 11	11.0.0-M1 through 11.0.23	11.0.24	Upgrade to 11.0.24 or a later supported release
Tomcat 10.1	10.1.0-M1 through 10.1.56	10.1.57	Upgrade to 10.1.57 or a later supported release
Tomcat 9	9.0.0.M1 through 9.0.119	9.0.120	Upgrade to 9.0.120 or a later supported release
Tomcat 8.5	8.5.0 through 8.5.100	No new community release identified for this EOL branch	Migrate to Tomcat 9 or another supported branch
Other EOL branches	Apache says they may also be affected	No general supported fix path	Replace or migrate rather than relying on unsupported code

Apache’s security pages identify the fixed releases independently for Tomcat 11, 10.1, and 9. The project’s version guidance states that Tomcat 8.5 has reached end of life and recommends upgrading to Tomcat 9 or later. (Apache Tomcat)(Apache Tomcat)anizations running vendor-packaged Tomcat builds should not assume the upstream version string tells the whole story. Linux distributions and commercial products sometimes backport security patches without changing to the same upstream version number. In that case, verify the vendor advisory, package changelog, and patch status. Conversely, a product that bundles a vulnerable upstream JAR may remain exposed even if the host operating system is fully patched.

The deployment artifact matters more than the development dependency file. A Maven or Gradle lockfile can show one version while the running image contains another. A container base image can include Tomcat independently of the application build. A platform team may upgrade a template without replacing already-running pods. The version check must reach the runtime.

Useful local checks include:

"$CATALINA_HOME/bin/version.sh"

On Windows:

%CATALINA_HOME%\bin\version.bat

For a container:

docker exec <container-name> /usr/local/tomcat/bin/version.sh

For Kubernetes:

kubectl exec -n <namespace> <pod-name> -- \
  /usr/local/tomcat/bin/version.sh

Paths vary by image and package. Record the command output, image digest, deployment name, and time of collection. A screenshot of a package manifest is weaker evidence than runtime output tied to the actual workload.

Why Apache Says Low While CISA-ADP Scores It 9.1

CVE-2026-59083 presents an unusually sharp severity contrast.

Apache rates the issue Low. NVD’s page did not show an independent NIST assessment at publication, but it displayed a CISA-ADP CVSS 3.1 base score of 9.1 with the vector:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

The NVD change history also recorded CISA-ADP SSVC values of exploitation: none, automatable: yese technicalImpact: total at that point in time. (NVD)(NVD) two ratings are not necessarily based on the same operational question.

A generic CVSS vector asks what impact is possible if a vulnerable configuration is reachable and the flaw is successfully used. Under a worst-case deployment, a security-constraint bypass could expose highly confidential data or permit high-impact unauthorized changes. That assumption produces a high score.

Apache’s project severity incorporates how likely the dangerous configuration is across the installed base. The official wording repeatedly narrows the issue to “some configurations,” and the RewriteValve is optional. The most defensible interpretation is that Apache considers the preconditions uncommon enough to reduce the project-level severity. Apache does not publish a detailed exploitability rationale in the short advisory, so teams should not invent a more specific explanation. (SecLists)(SecLists) correct local priority is therefore not “9.1 always” or “Low always.” It is a contextual decision.

Local environment	Likely operational priority	Reason
RewriteValve is not enabled anywhere	Normal accelerated patch cycle	The vulnerable code is present but the known trigger component is absent
RewriteValve only redirects public legacy URLs	Moderado	Direct authorization impact appears limited, but the component still requires patching
RewriteValve rewrites identifiers used by the application	High until tested	Character conversion may change resource identity
RewriteValve blocks internal or administrative paths	Alta	Rewrite behavior is acting as an access-control boundary
RewriteValve provides tenant isolation	High or critical	A path identity mismatch may cross data-ownership boundaries
Multiple proxies normalize URIs differently	High investigation priority	Cross-layer interpretation increases bypass risk
EOL Tomcat 8.5 is exposed to untrusted traffic	High remediation priority	No supported community branch fix is available
Sensitive action is also protected inside the application	Reduced exploitability, not zero	Defense in depth may prevent impact even if rewriting behaves incorrectly

CVSS is useful for queueing work. It cannot determine whether a local rule turns team+east em team east, whether those names map to different customers, or whether application authorization catches the mismatch.

Conditions Required for Practical Exposure

A realistic CVE-2026-59083 assessment should answer five questions.

Is an affected Tomcat version running?

If the deployment is already on Tomcat 11.0.24, 10.1.57, 9.0.120, or later in the respective branch, the upstream defect is fixed. Confirm that every node, pod, VM, and failover instance is updated.

Is RewriteValve enabled?

Search Host and Context configuration for:

org.apache.catalina.valves.rewrite.RewriteValve

A Linux-oriented configuration search might use:

grep -R --line-number \
  --include='*.xml' \
  'org\.apache\.catalina\.valves\.rewrite\.RewriteValve' \
  "$CATALINA_BASE/conf" \
  "$CATALINA_BASE/webapps" 2>/dev/null

Then locate rewrite files:

find "$CATALINA_BASE" -type f -name 'rewrite.config' -print

RewriteValve can be configured at different scopes. A search that checks only the global server.xml may miss a web-application-level valve in context.xml or a deployed application.

Can the rules process a URI containing a literal or encoded plus sign?

Review regular expressions, backreferences, substitutions, and query-to-path transformations. Search for obvious indicators:

grep -R --line-number -E \
  '\+|%2[Bb]|RewriteRule|RewriteCond|\$[0-9]|%[0-9]' \
  "$CATALINA_BASE" 2>/dev/null

The absence of a literal + in the rule file does not eliminate exposure. A capture group may accept arbitrary user-controlled text and insert it into the rewritten URI.

Por exemplo:

RewriteRule ^/profile/(.*)$ /internal/users/$1 [L]

A client-controlled segment containing + can pass through $1 even though the rule does not contain a plus sign.

Do the rules carry security meaning?

Security-relevant rules often contain concepts such as:

admin
internal
private
tenant
account
role
deny
forbidden
trusted
host
origin
legacy
management

Those words are only search hints. A rule that looks like a cosmetic redirect may still change which application handler receives the request. A rule that appears security-sensitive may be backed by independent authorization and therefore have little exploitable impact.

The reviewer should trace each rule to its destination:

Incoming route
Matching conditions
Replacement path
Final servlet or framework route
Authentication requirement
Authorization check
Resource owner check
Side effect

Does another layer enforce the same policy?

If the application independently checks the authenticated user’s role and resource ownership, a RewriteValve error may produce only an unexpected 404 or 403. If the rewrite rule is the only control preventing access to an internal handler, the risk is much higher.

A healthy architecture treats rewriting as routing and authorization as authorization. Rewrite rules may reduce attack surface, but sensitive operations should still verify identity and permission after routing.

Configuration-Dependent Abuse Scenarios

The following scenarios are conceptual exposure models, not claims that every affected installation implements these exact rules.

Path Denylist and Backend Route Disagreement

Suppose an application has public project identifiers containing plus signs:

/projects/team+east

A rewrite rule maps them to an internal handler:

/internal/projects/team+east

An older RewriteValve changes the rewritten value to:

/internal/projects/team east

If the application treats those identifiers differently, the request can reach a different project, fallback route, or default handler. The outcome depends on the router and data model. The vulnerability does not inherently determine which route is more privileged.

The important test is whether the policy decision is made before or after the character change. A deny rule may evaluate the pre-decoding form while the application receives the altered form.

Tenant Namespace Confusion

Multi-tenant systems often embed tenant identifiers in paths:

/t/team+east/reports
/t/team east/reports

A well-designed system should bind authorization to an immutable tenant ID rather than trusting the path string alone. Legacy applications sometimes derive tenancy directly from a rewritten path segment.

Se team+east e team east are distinct records, an unintended conversion can create a cross-tenant lookup. If the application subsequently checks that the authenticated principal belongs to the resolved tenant, the request should still fail. If it trusts the rewrite layer to guarantee the tenant boundary, the impact can include unauthorized data access.

This scenario illustrates why the CISA-ADP vector can model high confidentiality impact while Apache still calls the vulnerability Low: the high-impact outcome is possible only when several local design choices align.

Rewrite-Based Administrative Gate

A legacy deployment might use RewriteValve to reject requests to a management path unless a request property matches:

/admin/*

If the rule’s comparison and the final path mapping do not use the same representation, a crafted path may evade the rule and still resolve to an administrative handler.

That does not automatically bypass the handler’s own authentication. Tomcat Manager, a custom administration console, or a framework route may impose separate checks. The assessment must demonstrate the final authorization result, not stop after showing that one rewrite rule behaved differently.

Proxy and Origin Normalization Split

A reverse proxy may treat + as a literal path character while Tomcat’s vulnerable rewrite stage turns it into a space. Alternatively, the proxy may decode %2B para +, after which Tomcat converts the resulting plus sign to a space.

That creates a three-way interpretation problem:

Client sends:          a%2Bb
Proxy forwards:       a+b
RewriteValve produces a+b
Vulnerable decoder:   a b
Application receives: a b

A WAF rule examining the original %2B may approve the request. The application may receive a space. Logs at the edge and origin may appear to describe different requests.

The inverse is also possible: an edge layer may normalize both forms before logging, hiding the distinction needed for investigation. For this reason, incident evidence should preserve the raw request target where the platform allows it, along with the normalized path used for routing.

Query-to-Path Rewriting

Some applications convert query parameters into path segments:

/report?id=team+east

becomes:

/internal/report/team+east

Query parameters often use form-encoding semantics, where + can legitimately represent a space. Paths use different rules. Moving data from a query component into a path component without an explicit encode-decode contract can produce ambiguity even in patched software.

CVE-2026-59083 adds a container-level defect to that already fragile design. The fix corrects the unintentional plus conversion inside RewriteValve, but application owners should still review any rule that moves user-controlled values between URI components.

Cache and Authorization Key Mismatch

A caching layer may key a response on the raw request URI, while the application authorizes the decoded route. If a+b e a b collapse at one layer but not another, data can be cached under one identity and served under another.

CVE-2026-59083 does not itself prove cache poisoning or data leakage. It creates a representation mismatch that can participate in such a chain. Validation must compare cache keys, authorization identities, response ownership, and headers rather than inferring impact from a path difference alone.

Safe Local PoC Demonstrating the Root Cause

The safest useful demonstration does not attack a server. It reproduces the decoder mismatch locally.

The following Java program compares the generic form decoder with Tomcat’s URI decoder. It requires a fixed or affected Tomcat tomcat-util JAR on the local classpath, but it sends no network traffic and accesses no application data.

import java.net.URLDecoder;
import java.nio.charset.StandardCharsets;

import org.apache.tomcat.util.buf.UDecoder;

public final class PlusDecodingDemo {

    private static void compare(String value) {
        String formDecoded =
                URLDecoder.decode(value, StandardCharsets.UTF_8);

        String tomcatUriDecoded =
                UDecoder.URLDecode(value, StandardCharsets.UTF_8);

        System.out.printf(
                "input=%-8s formDecoder=%-8s uriDecoder=%s%n",
                value,
                quote(formDecoded),
                quote(tomcatUriDecoded)
        );
    }

    private static String quote(String value) {
        return "\"" + value + "\"";
    }

    public static void main(String[] args) {
        compare("a+b");
        compare("a%2Bb");
        compare("a%20b");
    }
}

Compile it in an isolated working directory:

javac \
  -cp "$CATALINA_HOME/lib/tomcat-util.jar" \
  PlusDecodingDemo.java

Run it:

java \
  -cp ".:$CATALINA_HOME/lib/tomcat-util.jar" \
  PlusDecodingDemo

On Windows, replace the classpath separator : com ;.

The expected conceptual result is:

input=a+b      formDecoder="a b"    uriDecoder="a+b"
input=a%2Bb    formDecoder="a+b"    uriDecoder="a+b"
input=a%20b    formDecoder="a b"    uriDecoder="a b"

This demonstration is intentionally limited.

• It does not test a remote host.
• It does not bypass authentication.
• It does not identify a sensitive route.
• It does not include a production exploit payload.
• It only proves why using URLDecoder on a rewritten URI can change a literal plus sign.
• It mirrors the behavioral distinction captured by Apache’s regression test. (GitHub)(GitHub) PoC helps defenders understand the root cause, but it cannot determine whether a deployed rewrite.config is exploitable. That requires configuration-specific testing.

Optional Isolated Tomcat Behavior Lab

Teams that need behavioral evidence can build a non-production lab containing:

• One affected Tomcat release
• One fixed release from the same branch
• A loopback-only connector
• A toy web application that echoes request URI values
• A RewriteValve rule that copies a harmless path segment
• No authentication data
• No external connectivity
• No PUT-enabled default servlet
• No management applications
• No production configuration

Bind the connector to loopback:

<Connector
    address="127.0.0.1"
    port="8080"
    protocol="HTTP/1.1"
    connectionTimeout="20000" />

Use an intentionally harmless rule:

RewriteRule ^/source/(.*)$ /target/$1 [L]

The target servlet should only print diagnostic fields such as:

requestURI
servletPath
pathInfo
queryString

Then compare local requests:

curl --path-as-is -i \
  'http://127.0.0.1:8080/lab/source/a+b'

curl --path-as-is -i \
  'http://127.0.0.1:8080/lab/source/a%2Bb'

curl --path-as-is -i \
  'http://127.0.0.1:8080/lab/source/a%20b'

The purpose is to compare representation behavior between the affected and fixed releases. Do not add a protected administrative route merely to make the demonstration look more dramatic. A safe lab should answer one question: does the rewritten URI preserve a literal plus sign after the patch?

A strong test record includes:

Tomcat version
JDK version
Connector configuration
Valve scope
Exact rewrite.config
Exact curl command
Raw response
Application-observed request URI
Application-observed path info
Expected result
Actual result
Timestamp

That evidence is more useful than a scanner screenshot because it shows the relevant code path and the effect of the fix.

A Practical Exposure Review Workflow

Step One: Confirm Every Runtime Version

Inventory all Tomcat processes, not only repositories. Include:

• Internet-facing applications
• Internal applications
• Batch services with embedded Tomcat
• Vendor products bundling Tomcat
• Blue-green environments
• Disaster-recovery systems
• Idle staging deployments
• Kubernetes jobs
• Old VM templates
• Golden images
• Developer environments containing production credentials

Record package provenance. A distribution package may include a backported fix, while an application image may bundle unpatched upstream JARs.

Step Two: Locate RewriteValve at Every Scope

Search:

server.xml
context.xml
conf/Catalina/<host>/
META-INF/context.xml
WEB-INF/
rewrite.config

Tomcat documentation permits RewriteValve configuration at Host or application Context scope. A Host-level valve may affect several applications, while an application-level valve may be hidden inside one deployment artifact. (Apache Tomcat)(Apache Tomcat) WAR files:

find /path/to/apps -name '*.war' -print0 |
while IFS= read -r -d '' war; do
  echo "### $war"
  unzip -l "$war" |
    grep -E 'META-INF/context\.xml|WEB-INF/rewrite\.config'
done

Do not modify production WARs during inspection. Extract copies to a controlled workspace.

Step Three: Classify Rule Purpose

Assign each rule one or more functions:

Rule function	Security relevance
Permanent redirect	Usually low, unless destination or host selection is security-sensitive
Canonical hostname	Can affect trust, cookies, redirects, and virtual hosting
Public route alias	Usually functional, but may change handler selection
Internal route mapping	Potentially high
Path deny rule	High because rewriting is acting as a security filter
Tenant routing	High because resource ownership may depend on the path
Authentication gateway routing	Alta
Query-to-path conversion	High review priority because URI-component semantics change
Legacy compatibility mapping	Variable; old handlers often have weaker authorization
File or static-resource mapping	High when protected directories or write behavior are involved

Step Four: Identify User-Controlled Substitutions

Review capture groups and backreferences:

$0 through $9
%1 through %9

A rule may be exposed even when the literal plus sign does not appear in its source. User input can flow through a regular-expression capture and become part of the replacement URI.

Create a simple data-flow record:

Source:      request path segment 2
Transform:   RewriteRule capture $1
Destination: /internal/customer/$1
Security:    customer ownership checked only by route prefix
Risk:        identifier representation changes after rewrite

Step Five: Compare Security Enforcement Layers

For every sensitive destination, identify all controls:

Edge authentication
Tomcat Realm
web.xml security constraint
Framework role check
Method-level authorization
Object ownership check
Database row filter
Service-to-service authorization
RewriteValve condition

A rewrite rule should not be credited as the only authorization control unless that architecture is explicitly understood and accepted. If removal of the rule would expose a privileged operation without another check, the design already lacks defense in depth.

Step Six: Build an Encoding Test Matrix

Use only an authorized local or staging environment.

Logical test	Example input
Literal plus	a+b
Encoded plus	a%2Bb
Lowercase encoded plus	a%2bb
Encoded space	a%20b
Literal safe control	a-b
Adjacent path delimiters	Test only values accepted by the application
UTF-8 identifier	Use a harmless test account
Repeated encoding	Avoid aggressive fuzzing; test only when the architecture legitimately decodes more than once

For each case, capture:

Edge-observed URI
Origin-observed URI
RewriteValve result
Final route
Authenticated principal
Authorized resource
Status code
Response body hash
Redirect location
Application log entry

The goal is not to generate thousands of payloads. The goal is to determine whether semantically distinct inputs collapse into the same security identity or whether equivalent inputs diverge unexpectedly.

Step Seven: Repeat After Upgrading

Post-patch validation should demonstrate:

• The runtime version is fixed.
• The literal plus sign remains intact through rewriting.
• Existing legitimate routes still work.
• Encoded plus signs resolve consistently.
• Encoded spaces retain their intended meaning.
• Security constraints still reject unauthorized users.
• No proxy layer reintroduces the same ambiguity.
• Every cluster node behaves identically.

A successful package installation without behavioral verification is incomplete evidence when rewrite rules carry security significance.

Detection and Logging

CVE-2026-59083 does not have a universal exploit URI. Detection therefore relies on behavioral and representation signals rather than one signature.

Sinal	Why it may matter	False-positive risk
Requests containing + in path segments	Directly exercises the character involved	High; plus signs are legitimate
Requests containing %2B	May become + before vulnerable processing	Alta
Requests containing %20 near similar routes	May be compared with plus-sign variants	Alta
Same client tests +, %2Be %20 variants rapidly	Suggests normalization probing	Médio
Edge reports one path while application reports another	Indicates cross-layer transformation	Medium; ordinary decoding can explain differences
Authorization result changes across encoding variants	Stronger indicator of security impact	Low to medium, depending on intended route semantics
Unexpected fallback-handler activity	Rewritten path may miss the intended route	Médio
Requests to internal routes following encoded variants	May indicate bypass exploration	Environment-dependent
Repeated 301, 302, 403, and 404 transitions for equivalent-looking paths	Can reveal rule probing	Médio
Access to a different tenant or object after an encoding variant	High-confidence impact	Low if resource identity is verified

Logging must preserve enough context to reconstruct transformations. A single normalized application path is insufficient when the investigation concerns how a path changed.

Where supported, retain:

Raw request target
Decoded request path
Proxy-normalized path
Tomcat request URI
Servlet path
Path info
Matched virtual host
Authenticated principal
Selected application route
Authorization decision
Status code
Response size
Request ID
Upstream request ID

Do not enable highly verbose request logging indefinitely on sensitive production systems without reviewing privacy and credential exposure. URLs may contain account IDs, tokens, search terms, filenames, or confidential business data.

A request containing + should not trigger an incident by itself. Alert logic should combine URI encoding variation with a meaningful result: route changes, authorization changes, protected resource access, or unusual probing behavior.

Patching and Immediate Mitigation

The primary fix is an upgrade.

• Tomcat 11 users should run 11.0.24 or later.
• Tomcat 10.1 users should run 10.1.57 or later.
• Tomcat 9 users should run 9.0.120 or later.
• Tomcat 8.5 users should migrate to a supported branch rather than waiting for a new community release. (Apache Tomcat)(Apache Tomcat)porary mitigations can reduce exposure when an immediate deployment is impossible, but they do not replace patching.

Disable Unnecessary RewriteValve Instances

If a valve exists only for an obsolete redirect or abandoned migration rule, remove it through a controlled change process. Test all dependent routes before production deployment.

Do not delete rules blindly. Rewrite logic often accumulates undocumented compatibility behavior. Removing it may break authentication callbacks, static assets, API clients, or canonical redirects.

Remove Security Responsibility From Rewrite Rules

Move sensitive access decisions into:

• Servlet security constraints
• Framework authorization
• Method-level authorization
• Service-layer permission checks
• Object-level ownership checks

A simplified web.xml constraint might look like:

<security-constraint>
    <web-resource-collection>
        <web-resource-name>Administrative API</web-resource-name>
        <url-pattern>/admin/*</url-pattern>
    </web-resource-collection>

    <auth-constraint>
        <role-name>administrator</role-name>
    </auth-constraint>
</security-constraint>

<login-config>
    <auth-method>BASIC</auth-method>
    <realm-name>ApplicationRealm</realm-name>
</login-config>

<security-role>
    <role-name>administrator</role-name>
</security-role>

This example illustrates defense in depth. It is not a complete drop-in configuration and does not eliminate the need to upgrade. Authentication method, transport protection, Realm configuration, application architecture, and role mapping require environment-specific design.

Tomcat’s documentation notes that security constraints from the web application descriptor are processed by the Context and that an appropriate authenticator is configured when required. Tomcat also warns that path-based security constraints require care when part of the URL becomes servlet pathInfo, reinforcing the need to understand the final resource mapping rather than only the visible path. (Apache Tomcat)(Apache Tomcat) Restrict Exposure During the Change Window

For a confirmed high-risk rewrite configuration, temporary controls may include:

• Limiting the affected application to trusted networks
• Disabling the vulnerable route
• Requiring authentication at an upstream gateway
• Blocking write operations not required by the application
• Applying a precise allowlist for known route formats
• Increasing logging for encoding variants
• Shortening the patch window

A WAF rule that blocks every plus sign is rarely appropriate. It can break legitimate identifiers and does not address other representations such as %2B or transformations performed upstream. A control should be based on the actual route grammar and tested against normal traffic.

Hardening RewriteValve Configurations

Keep Rewriting and Authorization Separate

A rule may reject obviously invalid traffic, but sensitive handlers should still perform authorization. Treat the rewrite result as untrusted routing input.

Bad security assumption:

The request reached /internal/reports, so RewriteValve must have approved it.

Safer assumption:

The request reached /internal/reports, so the handler must authenticate the user,
resolve the requested object, and verify authorization for that object.

Define a Canonical Representation

Document how the system treats:

+
%2B
%2b
space
%20
Unicode characters
encoded slash
semicolon
dot segments
duplicate slashes

Not every application needs to accept every representation. Rejecting ambiguous input early is often safer than attempting to normalize it repeatedly.

Avoid Moving Raw Values Between URI Components

A query value should not be inserted directly into a path. Encode it for the destination component.

Conceptually unsafe:

?id=<user-input>
        |
        v
/internal/object/<user-input>

Mais seguro:

Parse query value under query semantics
Validate allowed identifier grammar
Convert to an internal immutable ID
Generate the destination path from that ID

Constrain Capture Groups

Broad patterns such as (.*) are easy to write and difficult to reason about. Prefer a grammar matching the intended identifier.

Broad:

RewriteRule ^/tenant/(.*)$ /internal/$1 [L]

Narrower:

RewriteRule ^/tenant/([A-Za-z0-9_-]{1,64})$ /internal/$1 [L]

Do not copy this expression without verifying the real identifier format. Some applications legitimately need plus signs, dots, Unicode, or other characters. The security improvement comes from defining the grammar, not from adopting a particular example.

Test Replacement Values, Not Only Input Matches

A rule can match safely and still produce a dangerous output. Validate:

Input domain
Captured values
Replacement construction
Encoding
Decoding
Normalization
Final route

Keep Rules Under Version Control

A production rewrite.config changed manually on a server is hard to audit. Store rules with:

• Review history
• Tests
• Owner
• Finalidade
• Expected route examples
• Security assumptions
• Rollback plan

Add Regression Tests for Encoding Variants

For every security-relevant route, write tests that compare literal and encoded forms. Assertions should cover the final authorization result, not only the rewritten string.

Example pseudocode:

assertUnauthorized("/admin/team+east");
assertUnauthorized("/admin/team%2Beast");
assertUnauthorized("/admin/team%20east");

assertSameOwner(
    requestAs("alice", "/tenant/team+east/report"),
    "tenant-team-plus-east"
);

The test data should use non-production accounts and resources. A passing 403 is meaningful only when the test confirms that the request reached the expected policy point rather than failing for an unrelated reason.

Common Assessment Mistakes

Treating Version Detection as Exploit Proof

Version detection is evidence of patch exposure, not proof of a bypass. The report should distinguish:

Vulnerable software present
Vulnerable component enabled
Relevant rule reachable
Security behavior affected
Unauthorized impact demonstrated

Each level requires additional evidence.

Ignoring the Vulnerability Because RewriteValve Appears Unused

An affected package still needs maintenance. Configuration may change later, embedded applications may enable the valve, and undocumented rules may exist in deployed artifacts. Absence of current reachability affects priority, not patch eligibility.

Testing Only Browser-Normalized URLs

Browsers and libraries may modify URLs before transmission. Use a client mode that preserves the intended request target in an isolated environment, and capture what was actually sent.

Looking Only at Status Codes

Two requests can both return 200 while exposing different objects. They can both return 403 for unrelated reasons. Compare:

Object identity
Response body
Authorization decision
Route
Principal
Side effect

Assuming + Always Means Space

That convention belongs to form-encoded data. Applying it to every path is precisely the category of mistake behind CVE-2026-59083. (Oracle Docs)(Oracle Docs) Assuming %2B Always Reaches Tomcat as %2B

A proxy may decode it first. Test the full deployed path, not only direct Tomcat access.

Applying a Global WAF Block

A global block on plus signs or percent encoding can create outages while leaving other normalization paths untouched. Controls should match the application’s accepted route grammar.

Patching One Node

Mixed clusters produce inconsistent behavior. A request may pass on a fixed node and fail or route differently on an old node. Verify image digests and runtime versions across every replica.

Rewriting the Rule Without Preserving Evidence

If a team modifies rewrite.config before collecting the vulnerable behavior, it may lose the ability to prove impact or confirm that the patch fixed the same condition. Preserve a sanitized copy, change record, and local reproduction.

Calling the Finding RCE

A security-constraint bypass can be serious, but RCE requires a demonstrated path to code execution. CVE-2026-59083’s official description does not supply one.

Related Tomcat Rewrite and Security-Constraint CVEs

CVE-2026-59083 belongs to a broader group of Tomcat issues where small differences in URI processing, rule evaluation, or constraint application changed a security decision.

CVE	Component and flaw	Key condition	Direct risk	Lição principal
CVE-2026-59083	RewriteValve converts literal + to space after rewriting	RewriteValve and security-relevant path semantics	Configuration-dependent security-control bypass	Use component-correct decoding and test canonical forms
CVE-2026-53404	RewriteValve incorrectly handles an OR-condition chain	Specific RewriteCond chain structure	Later conditions may be skipped	Control-flow correctness is part of policy enforcement
CVE-2025-31651	Specially crafted requests can bypass some rewrite rules	Uncommon security-relevant rewrite configuration	Rewrite-based security constraints may fail	Rewrite rules should not be the sole authorization layer
CVE-2025-55668	Session fixation through RewriteValve	Valve enabled and victim interaction	Victim may use an attacker-associated session context	Rewriting can affect state, not only routing
CVE-2025-55752	Rewritten URL normalized before decoding	Query-to-path rewriting and additional deployment conditions	Path traversal and possible RCE if PUT is enabled	Decode-normalize order can change protected-resource boundaries
CVE-2026-55956	Default Servlet method constraints ignored configured method logic	Security constraints on the default servlet using method rules	Method-level authorization uncertainty	Declarative policy must be tested against actual container behavior

CVE-2026-53404 was disclosed only weeks before CVE-2026-59083. In that flaw, if the first condition in an OR chain matched, later non-OR conditions could be skipped and the rewrite could succeed. The fixed versions were Tomcat 11.0.23, 10.1.56, and 9.0.119. A deployment that upgraded for CVE-2026-53404 but stopped at exactly those versions still needs the next update for CVE-2026-59083. (NVD)(NVD)-2025-31651 also affected security-relevant rewrite configurations. Apache described specially crafted requests bypassing some rewrite rules when those rules effectively enforced security constraints. The similarity is architectural rather than mechanical: both vulnerabilities expose the risk of treating rewrite behavior as a dependable authorization boundary. (NVD)

CVE-2025-55668 demonstrates that RewriteValve errors can affect session state. Apache described a session-fixation vulnerability requiring victim interaction and fixed it in Tomcat 11.0.8, 10.1.42, and 9.0.106. The issue was not a path-encoding bypass, but it reinforces that a valve can influence security properties beyond simple URL cosmetics. (NVD)

CVE-2025-55752 is the most important comparison when readers encounter unsupported claims that every RewriteValve bug means RCE. That vulnerability involved a different decode-normalize ordering defect. It could expose protected directories, and RCE required additional conditions including enabled PUT behavior. Apache considered that combination unlikely. CVE-2026-59083 has a different root cause and no equivalent official RCE chain. (NVD)

CVE-2026-55956 sits outside RewriteValve but affects the same broader trust boundary: the application believes a declarative security constraint means one thing, while the container enforces something else. It involved HTTP method and method-omission behavior on the default servlet and was fixed in Tomcat 11.0.23, 10.1.56, and 9.0.119. (Penligente)

The pattern does not mean Tomcat rewriting is inherently unsafe. It means URL transformation is security-sensitive infrastructure. Rule evaluation order, character decoding, normalization, method matching, and session handling must all preserve the assumptions made by access controls.

Post-Patch Validation

A good validation plan has three phases.

Phase One: Establish the Baseline

Before upgrading, in an isolated replica:

• Record the affected Tomcat version.
• Capture the relevant Valve configuration.
• Capture the exact rewrite.config.
• Identify a harmless route containing a plus sign or create one in the lab.
• Send literal-plus, encoded-plus, and encoded-space variants.
• Record the URI observed by the application.
• Confirm no sensitive data or real credentials are used.

Do not test a suspected administrative bypass against production merely to establish severity.

Phase Two: Upgrade

Apply the fixed release through the normal deployment system.

For containers:

docker pull <approved-fixed-image>
docker inspect <approved-fixed-image> --format '{{.Id}}'

Update the deployment to a pinned digest where operational policy supports it. Rebuilding from a moving tag without recording the resulting digest weakens traceability.

For package-based installations, preserve:

Package name
Package version
Repository
Vendor advisory
Installation logs
Service restart time
Runtime version output

Phase Three: Repeat the Same Tests

The post-patch test should show that:

a+b remains a+b after RewriteValve processing
a%2B resolves according to the application’s documented policy
a%20 resolves as an encoded space where allowed
authorization results remain correct
legitimate routes do not regress

Do not change the rule and the Tomcat version simultaneously unless operational urgency requires it. Changing two variables makes it difficult to identify which change fixed or broke the behavior.

A complete remediation record should connect:

Affected asset
Affected version
Relevant configuration
Observed vulnerable behavior
Change ticket
Fixed version
Observed fixed behavior
Reviewer
Date
Residual risk

Automation, AI Assistance, and Evidence Quality

Encoding matrices are suitable for automation because the test space is structured. An authorized tool can generate literal and percent-encoded variants, capture responses, group equivalent behaviors, and highlight cases where authorization changes.

Automation also creates risks. A generic scanner may send destructive HTTP methods, touch sensitive routes, test every discovered host, or interpret any response difference as a bypass. A safer workflow constrains:

• Authorized targets
• Allowed routes
• Allowed methods
• Request rate
• Test identities
• Test data
• Expected status codes
• Stop conditions
• Evidence retention

AI can help reviewers compare rules, trace capture groups, propose test matrices, and summarize response differences. It should not be allowed to declare exploitation solely from a version banner or invent a protected route. The final conclusion still requires exact requests, exact configuration, final resource identity, and an authorization result.

For teams already using automated validation, Penligente is one example of an evidence-oriented testing workflow in which version findings can be followed by scoped checks and retained request evidence. Its existing analysis of CVE-2026-53404 and Tomcat RewriteValve condition processing is a relevant companion because it examines another case where a narrow RewriteValve logic error can invalidate a security assumption. Neither automation nor a related CVE article replaces Apache’s fixed release or a local configuration review. (Penligente)

The strongest automated result is not:

Tomcat vulnerable, authentication bypass likely.

It is:

Asset runs Tomcat 10.1.56.
RewriteValve is enabled at Context scope.
Rule 14 copies a user-controlled project identifier into the destination path.
In the authorized staging environment, a literal plus reaches the application
as a space before patching and remains a plus on 10.1.57.
Application-level ownership checks prevent cross-project access.
Residual impact was route confusion and request failure, not unauthorized data access.

That statement separates software exposure, vulnerable behavior, and demonstrated impact.

PERGUNTAS FREQUENTES

What is CVE-2026-59083?

• It is an Apache Tomcat RewriteValve URL-decoding vulnerability.
• A literal + in a rewritten URI could be converted to a space.
• The resulting path change could bypass a security control in some configurations.
• Apache classifies the weakness as Low severity.
• The issue is fixed in Tomcat 11.0.24, 10.1.57, and 9.0.120. (Apache Tomcat)

Is CVE-2026-59083 a remote code execution vulnerability?

• Apache does not describe it as RCE.
• The direct issue is a configuration-dependent security-control bypass.
• A separate application flaw or exposed privileged operation would be required to build a code-execution chain.
• Do not label a finding RCE without proving execution in an authorized environment.
• CVE-2025-55752 had a separate RewriteValve-related RCE path under additional PUT and path-traversal conditions; that description should not be transferred to CVE-2026-59083. (SecLists)

Am I exposed if I do not use RewriteValve?

• The known vulnerable behavior occurs in RewriteValve processing.
• If RewriteValve is not enabled, the documented trigger path is absent.
• You should still upgrade an affected Tomcat release.
• Check application-level and Host-level Context configuration before concluding that the valve is unused.
• Embedded or vendor-packaged applications may enable components outside your central server.xml.

Which Tomcat versions fix CVE-2026-59083?

• Tomcat 11 is fixed in 11.0.24.
• Tomcat 10.1 is fixed in 10.1.57.
• Tomcat 9 is fixed in 9.0.120.
• Tomcat 8.5 is end-of-life and should be migrated to a supported branch.
• Other unsupported releases may also be affected. (NVD)

Why does Apache rate it Low while NVD shows 9.1?

• Apache’s rating reflects the limited set of configurations in which the decoding error becomes a security bypass.
• NVD displayed a CISA-ADP CVSS 3.1 score of 9.1 based on a high-impact worst-case model.
• NVD did not show its own independent NIST base score at publication.
• The correct local priority depends on whether RewriteValve is enabled and whether its rules protect sensitive paths, tenants, or operations.
• Neither score replaces local exposure validation. (NVD)

How can I verify the vulnerability safely?

• Use a local or isolated staging environment.
• Confirm the affected runtime version.
• Reproduce only the character-decoding difference with harmless routes.
• Compare a+b, a%2Bbe a%20b.
• Capture the application-observed URI before and after upgrading.
• Do not probe third-party systems or production administrative routes without explicit authorization.
• Avoid destructive methods and real customer data.

What should Tomcat 8.5 users do?

• Treat the issue as part of a broader end-of-life problem.
• Tomcat 8.5 has no current community maintenance branch.
• Plan migration to Tomcat 9 or a newer supported branch.
• Read the relevant migration documentation and test configuration compatibility.
• Do not depend on an unsupported version remaining safe because a particular public exploit has not been observed. (Apache Tomcat)

Can a WAF replace the Tomcat upgrade?

• No.
• A WAF may temporarily reduce exposure to specific path forms.
• Blocking every + ou %2B can break legitimate traffic.
• Proxies and Tomcat may decode values at different stages.
• A WAF cannot repair the vulnerable decoder inside RewriteValve.
• Upgrade first, then retain precise edge controls as defense in depth.

Closing Assessment

CVE-2026-59083 is a narrow implementation error with potentially broad consequences only when a deployment gives rewritten path text security meaning. The vulnerable code changed a literal plus sign into a space. That sounds minor until the path selects a tenant, protected handler, internal resource, or authorization policy.

The immediate action is straightforward: run Tomcat 11.0.24, 10.1.57, 9.0.120, or a later supported release. Tomcat 8.5 deployments should migrate rather than wait for upstream maintenance that the end-of-life branch no longer receives.

The deeper task is to identify whether RewriteValve has become an undocumented security boundary. Review capture groups, query-to-path transformations, administrative routes, tenant identifiers, proxy normalization, and application authorization. Test literal and encoded forms in an isolated environment, preserve both raw and normalized evidence, and repeat the same tests after patching.

A version match tells you where to start. A changed URI shows the vulnerable behavior. Only a verified authorization outcome establishes the real impact.