The Vert.x Web static handler component cache can be manipulated to deny the access to static files served by the handler using specifically crafted request URI.
The issue comes from an improper implementation of the C. rule of section 5.2.4 of RFC3986 and is fixed in Vert.x Core component (used by Vert.x Web): https://github.com/eclipse-vertx/vert.x/pull/5895
Steps to reproduce Given a file served by the static handler, craft an URI that introduces a string like bar%2F..%2F after the last / char to deny the access to the URI with an HTTP 404 response. For example https://example.com/foo/index.html can be denied with https://example.com/foo/bar%2F..%2Findex.html
Mitgation Disabling Static Handler cache fixes the issue.
StaticHandler staticHandler = StaticHandler.create().setCachingEnabled(false);
Summary
When running vertx web applications that serve files using StaticHandler on Windows Operating Systems and Windows File Systems, if the mount point is a wildcard () then an attacker can exfiltrate any class path resource.
Details When computing the relative path to locate the resource, in case of wildcards, the code:
https://github.com/vert-x3/vertx-web/blob/62c0d66fa1c179ae6a4d57344631679a2b97e60f/vertx-web/src/main/java/io/vertx/ext/web/impl/Utils.java#L83
returns the user input (without validation) as the segment to lookup. Even though checks are performed to avoid escaping the sandbox, given that the input was not sanitized \ are not properly handled and an attacker can build a path that is valid within the classpath.
PoC
https://github.com/adrien-aubert-drovio/vertx-statichandler-windows-traversal-path-vulnerability