Fix encoded path traversal corruption in sub-router handlers - #2900
Merged
Conversation
See vert-x3#2898 When a request with encoded dot-segments (e.g. %2e%2e%2f) hit a handler mounted inside a sub-router via a regex or parameterized route, Utils.pathOffset corrupted the route-relative path because dot-segment resolution had already consumed the mount-point prefix. Fix by running pathOffset on the raw normalizedPath first, then decoding and resolving dot-segments on the result. Also remove the now redundant decodeURIComponent and removeDotSegments calls from StaticHandlerImpl.handle(), since normalizedPath() already decodes unreserved characters and resolves dot-segments, and file path resolution is now fully handled in getFile(). Some portions of this content were created with the assistance of Claude Code. Signed-off-by: Thomas Segismont <tsegismont@gmail.com>
There was a problem hiding this comment.
Pull request overview
Fixes incorrect route-relative path computation for requests containing encoded dot-segments when handlers are mounted in a sub-router (notably for regex/parameterized routes), addressing the normalization/offset ordering described in #2898.
Changes:
- Update
TemplateHandlerImplto applyUtils.pathOffset()before decoding and dot-segment removal. - Refactor
StaticHandlerImplto compute the route offset first and centralize decode/dot-segment removal ingetFile(). - Add regression tests covering StaticHandler and TemplateHandler behavior in sub-routers for wildcard, regex, and path-param routes.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| vertx-web/src/test/java/io/vertx/ext/web/tests/SubRouterTest.java | Adds regression tests ensuring encoded dot-segments don’t corrupt route-relative paths under sub-router mounts. |
| vertx-web/src/main/java/io/vertx/ext/web/handler/impl/TemplateHandlerImpl.java | Reorders path processing so offset is computed before decode/dot-segment resolution. |
| vertx-web/src/main/java/io/vertx/ext/web/handler/impl/StaticHandlerImpl.java | Moves decode/dot-segment resolution to operate on the offset path and simplifies handle() path preparation. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
tsegismont
added a commit
that referenced
this pull request
May 22, 2026
Follows-up on #2900 After moving URI decoding into getFile(), sendStatic() was using context.normalizedPath() (which may still contain percent-encoded characters) as the cache key. Requests for the same file with different encodings (e.g. /foo/%62ar.txt vs /foo/bar.txt) created separate cache entries, wasting slots in the bounded LRU cache. Use the decoded file path from getFile() as the cache key so that encoding-equivalent paths share a single entry. As a side effect, getFile() is now called unconditionally at the top of sendStatic(), which simplifies the code. Previously, it was deferred when includeHidden was true (skipping the dot-segment check), requiring a null guard and a second getFile() call for the localFile computation. Some portions of this content were created with the assistance of Claude Code. Signed-off-by: Thomas Segismont <tsegismont@gmail.com>
tsegismont
added a commit
that referenced
this pull request
May 22, 2026
…2903) See #2898 When a request with encoded dot-segments (e.g. %2e%2e%2f) hit a handler mounted inside a sub-router via a regex or parameterized route, Utils.pathOffset corrupted the route-relative path because dot-segment resolution had already consumed the mount-point prefix. Fix by running pathOffset on the raw normalizedPath first, then decoding and resolving dot-segments on the result. Also remove the now redundant decodeURIComponent and removeDotSegments calls from StaticHandlerImpl.handle(), since normalizedPath() already decodes unreserved characters and resolves dot-segments, and file path resolution is now fully handled in getFile(). Some portions of this content were created with the assistance of Claude Code. Signed-off-by: Thomas Segismont <tsegismont@gmail.com>
tsegismont
added a commit
that referenced
this pull request
May 22, 2026
…2904) See #2898 When a request with encoded dot-segments (e.g. %2e%2e%2f) hit a handler mounted inside a sub-router via a regex or parameterized route, Utils.pathOffset corrupted the route-relative path because dot-segment resolution had already consumed the mount-point prefix. Fix by running pathOffset on the raw normalizedPath first, then decoding and resolving dot-segments on the result. Also remove the now redundant decodeURIComponent and removeDotSegments calls from StaticHandlerImpl.handle(), since normalizedPath() already decodes unreserved characters and resolves dot-segments, and file path resolution is now fully handled in getFile(). Some portions of this content were created with the assistance of Claude Code. Signed-off-by: Thomas Segismont <tsegismont@gmail.com>
tsegismont
added a commit
that referenced
this pull request
May 22, 2026
Follows-up on #2900 After moving URI decoding into getFile(), sendStatic() was using context.normalizedPath() (which may still contain percent-encoded characters) as the cache key. Requests for the same file with different encodings (e.g. /foo/%62ar.txt vs /foo/bar.txt) created separate cache entries, wasting slots in the bounded LRU cache. Use the decoded file path from getFile() as the cache key so that encoding-equivalent paths share a single entry. As a side effect, getFile() is now called unconditionally at the top of sendStatic(), which simplifies the code. Previously, it was deferred when includeHidden was true (skipping the dot-segment check), requiring a null guard and a second getFile() call for the localFile computation. Some portions of this content were created with the assistance of Claude Code. Signed-off-by: Thomas Segismont <tsegismont@gmail.com>
tsegismont
added a commit
that referenced
this pull request
May 22, 2026
Follows-up on #2900 After moving URI decoding into getFile(), sendStatic() was using context.normalizedPath() (which may still contain percent-encoded characters) as the cache key. Requests for the same file with different encodings (e.g. /foo/%62ar.txt vs /foo/bar.txt) created separate cache entries, wasting slots in the bounded LRU cache. Use the decoded file path from getFile() as the cache key so that encoding-equivalent paths share a single entry. As a side effect, getFile() is now called unconditionally at the top of sendStatic(), which simplifies the code. Previously, it was deferred when includeHidden was true (skipping the dot-segment check), requiring a null guard and a second getFile() call for the localFile computation. Some portions of this content were created with the assistance of Claude Code. Signed-off-by: Thomas Segismont <tsegismont@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See #2898
When a request with encoded dot-segments (e.g. %2e%2e%2f) hit a handler mounted inside a sub-router via a regex or parameterized route, Utils.pathOffset corrupted the route-relative path because dot-segment resolution had already consumed the mount-point prefix.
Fix by running pathOffset on the raw normalizedPath first, then decoding and resolving dot-segments on the result.
Also remove the now redundant decodeURIComponent and removeDotSegments calls from StaticHandlerImpl.handle(), since normalizedPath() already decodes unreserved characters and resolves dot-segments, and file path resolution is now fully handled in getFile().
Some portions of this content were created with the assistance of Claude Code.