In Eclipse Vert.x versions up to and including 4.5.29 (4.x branch) and 5.1.4 (5.x branch), DefaultRedirectHandler (vertx-core) propagates all request headers as-is across cross-origin HTTP 30x redirects. Only Content-Length is stripped; no origin comparison (scheme, host, port) is performed before copying headers to the redirect target. As a result, credential headers, including Authorization, Cookie, Proxy-Authorization, and arbitrary custom headers such as X-API-Token, are forwarded to the redirect destination without the caller's knowledge.

An attacker who can cause a Vert.x HttpClient to issue a request that is redirected to an attacker-controlled host (for example, by supplying a URL to a webhook dispatcher, image proxy, or microservice URL fetcher) can capture bearer tokens, basic-auth credentials, session cookies, and API keys attached to the original request.

In versions up to and including 4.5.29 (4.x branch) and 5.1.4 (5.x branch), the WebClientSession component of Eclipse Vert.x Web Client does not validate that the Domain attribute of a Set-Cookie response header matches the originating server's domain, in violation of RFC 6265 section 5.3. An attacker who controls any server that the victim application contacts can inject a cookie scoped to an arbitrary third-party domain; because the session store performs no cross-domain ownership check, it stores and later transmits that cookie to the targeted domain.

When the victim application subsequently sends a request to the targeted domain using the same WebClientSession, it presents the attacker-injected cookie, causing the receiving service to process the request under the attacker's account. Sensitive data included in the victim application's requests, such as payment amounts, card details, or other API payloads, may then be accessible to the attacker through their own account on that service.

A TCP client can perform a TLS handshake and present the server name extension with a server name that is accepted by a server wildcard name, e.g. if the server is configured with a certificate accepting .example.com, any XYZ.example.com where xyz is a valid name can be used.

Description

There is a flaw in the hidden file protection feature of Vert.x Web’s StaticHandler when setIncludeHidden(false) is configured.

In the current implementation, only files whose final path segment (i.e., the file name) begins with a dot (.) are treated as “hidden” and are blocked from being served. However, this logic fails in the following cases:

- Files under hidden directories: For example, /.secret/config.txt — although .secret is a hidden directory, the file config.txt itself does not start with a dot, so it gets served. - Real-world impact: Sensitive files placed in hidden directories like .git, .env, .aws may become publicly accessible.

As a result, the behavior does not meet the expectations set by the includeHidden=false configuration, which should ideally protect all hidden files and directories. This gap may lead to unintended exposure of sensitive information.

Steps to Reproduce

bash 1. Prepare test environment

Create directory structure mkdir -p src/test/resources/webroot/.secret mkdir -p src/test/resources/webroot/.git

Place test files echo "This is a visible file" > src/test/resources/webroot/visible.txt echo "This is a hidden file" > src/test/resources/webroot/.hidden.txt echo "SECRET DATA: APIKEY=abc123" > src/test/resources/webroot/.secret/config.txt echo "Git config data" > src/test/resources/webroot/.git/config

java 2. Implement test server

import io.vertx.core.AbstractVerticle; import io.vertx.core.Vertx; import io.vertx.ext.web.Router; import io.vertx.ext.web.handler.StaticHandler;

public class StaticHandlerTestServer extends AbstractVerticle { @Override public void start() { Router router = Router.router(vertx);

// Configure to not serve hidden files StaticHandler staticHandler = StaticHandler.create("src/test/resources/webroot") .setIncludeHidden(false) .setDirectoryListing(false);

router.route("/").handler(staticHandler);

vertx.createHttpServer() .requestHandler(router) .listen(8082); }

public static void main(String[] args) { Vertx vertx = Vertx.vertx(); vertx.deployVerticle(new StaticHandlerTestServer()); } }

bash 3. Confirm the vulnerability

Normal file (accessible) curl http://localhost:8082/visible.txt Result: 200 OK

Hidden file (correctly blocked) curl http://localhost:8082/.git Result: 404 Not Found

File under hidden directory (vulnerable) curl http://localhost:8082/.git/config Result: 200 OK - Returns contents of Git config

Potential Impact

1. Information Disclosure

Examples of sensitive files that could be exposed:

- .git/config: Git repository settings (e.g., remote URL, credentials) - .env/: Environment variables (API keys, DB credentials) - .aws/credentials: AWS access keys - .ssh/knownhosts: SSH host trust info - .docker/config.json: Docker registry credentials

2. Attack Scenarios

- Attackers can guess common hidden directory names and enumerate filenames under them to access confidential data. - Especially dangerous for .git/HEAD, .git/config, .git/objects/ — which may allow full reconstruction of source code.

3. Affected Scope

- Affected version: Vert.x Web 5.1.0-SNAPSHOT (likely earlier versions as well) - Environments: All OSes (Windows, Linux, macOS) - Configurations: All applications using StaticHandler.setIncludeHidden(false)

Description

- In the StaticHandlerImpl#sendDirectoryListing(...) method under the text/html branch, file and directory names are directly embedded into the href, title, and link text without proper HTML escaping. - As a result, in environments where an attacker can control file names, injecting HTML/JavaScript is possible. Simply accessing the directory listing page will trigger an XSS. - Affected Code: - File: vertx-web/src/main/java/io/vertx/ext/web/handler/impl/StaticHandlerImpl.java - Lines: - 709–713: normalizedDir is constructed without escaping - 714–731: <li><a ...> elements insert file names directly into attributes and body without escaping - 744: parent directory name construction - 746–751: {directory}, {parent}, and {files} are inserted into the HTML template without escaping

Reproduction Steps

1. Prerequisites: - Directory listing is enabled using StaticHandler (e.g., StaticHandler.create("public").setDirectoryListing(true)) - The attacker has the ability to create arbitrary file names under a public directory (e.g., via upload functionality or a shared directory)

2. Create a malicious file name (example for Unix-based OS): - Create an empty file in public/ with one of the following names: - <img src=x onerror=alert('XSS')>.txt - Or attribute injection: evil" onmouseover="alert('XSS')".txt - Example: bash mkdir -p public printf 'test' > "public/<img src=x onerror=alert('XSS')>.txt"

3. Start the server (example): - Routing: router.route("/public/").handler(StaticHandler.create("public").setDirectoryListing(true)); - Server: vertx.createHttpServer().requestHandler(router).listen(8890);

4. Verification request (raw HTTP): GET /public/ HTTP/1.1 Host: 127.0.0.1:8890 Accept: text/html Connection: close

5. Example response excerpt: html <ul id="files"> <li> <a href="/public/<img src=x onerror=alert('XSS')>.txt" title="<img src=x onerror=alert('XSS')>.txt"> <img src=x onerror=alert('XSS')>.txt </a> </li> ... </ul>

- When accessing /public/ in a browser, the unescaped file name is interpreted as HTML, and event handlers such as onerror are executed.

Potential Impact

- Stored XSS - Arbitrary JavaScript executes in the browser context of users viewing the listing page - Possible consequences: - Theft of session tokens, JWTs, localStorage contents, or CSRF tokens - Unauthorized actions with admin privileges (user creation, permission changes, settings modifications) - Watering hole attacks, including malware distribution or malicious script injection to other pages

- Common Conditions That Make Exploitation Easier - Uploaded files are served directly under a publicly accessible directory - Shared/synced directories (e.g., NFS, SMB, WebDAV, or cloud sync) are exposed - ZIP/TAR archives are extracted directly under the webroot and directory listing is enabled in production environments

Similar CVEs Previously Reported

- CVE‑2024‑32966 - CVE‑2019‑15603