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.

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.

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.

In Eclipse Vert.x version 4.3.0 to 4.5.9, the gRPC server does not limit the maximum length of message payload (Maven GAV: io.vertx:vertx-grpc-server and io.vertx:vertx-grpc-client).

This is fixed in the 4.5.10 version.

Note this does not affect the Vert.x gRPC server based grpc-java and Netty libraries (Maven GAV: io.vertx:vertx-grpc)

In Eclipse Vert.x version 4.3.0 to 4.5.9, the gRPC server does not limit the maximum length of message payload (Maven GAV: io.vertx:vertx-grpc-server and io.vertx:vertx-grpc-client).

This is fixed in the 4.5.10 version.

Note this does not affect the Vert.x gRPC server based grpc-java and Netty libraries (Maven GAV: io.vertx:vertx-grpc)

In version from 3.0.0 to 3.5.3 of Eclipse Vert.x, the WebSocket HTTP upgrade implementation buffers the full http request before doing the handshake, holding the entire request body in memory. There should be a reasonnable limit (8192 bytes) above which the WebSocket gets an HTTP response with the 413 status code and the connection gets closed.

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

Vert.x STOMP is a vert.x implementation of the STOMP specification that provides a STOMP server and client. From versions 3.1.0 until 3.9.16 and 4.0.0 until 4.4.2, a Vert.x STOMP server processes client STOMP frames without checking that the client send an initial CONNECT frame replied with a successful CONNECTED frame. The client can subscribe to a destination or publish message without prior authentication. Any Vert.x STOMP server configured with an authentication handler is impacted. The issue is patched in Vert.x 3.9.16 and 4.4.2. There are no trivial workarounds.

Eclipse Vert.x before version 3.5.2 does not properly neutralize CR and LF characters in HTTP request before return responses. A remote attacker could exploit this to inject abritrary HTTP response headers to potentially mount cross-site scripting and cache poisoning attacks.

External Reference:

https://www.compass-security.com/fileadmin/Datein/Research/Advisories/CSNC-2018-021vertx.txt

Upstream Issue:

https://github.com/eclipse/vert.x/issues/2470

Upstream Patch:

https://github.com/eclipse/vert.x/commit/1bb6445226c39a95e7d07ce3caaf56828e8aab72

An XML External Entity vulnerability was found in vertx-web before 3.5.4. The function isValid didn't provide any XXE protection when parsing an XML document.

Upstream issue:

https://github.com/vert-x3/vertx-web/issues/1021

References:

https://bugs.eclipse.org/bugs/showbug.cgi?id=539568

Upstream patches:

https://github.com/vert-x3/vertx-web/pull/1022/commits/d814d22ade14bafec47c4447a4ba9bff090f05e8 https://github.com/vert-x3/vertx-web/pull/1022/commits/26db16c7b32e655b489d1a71605f9a785f788e41

In version from 3.0.0 to 3.5.3 of Eclipse Vert.x, the StaticHandler uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize '\' (forward slashes) sequences that can resolve to a location that is outside of that directory when running on Windows Operating Systems.

In Eclipse Vert.x 3.4.x up to 3.9.4, 4.0.0.milestone1, 4.0.0.milestone2, 4.0.0.milestone3, 4.0.0.milestone4, 4.0.0.milestone5, 4.0.0.Beta1, 4.0.0.Beta2, and 4.0.0.Beta3, StaticHandler doesn't correctly processes back slashes on Windows Operating systems, allowing, escape the webroot folder to the current working directory.

Vert.x-Web framework v4.0 milestone 1-4 does not perform a correct CSRF verification. Instead of comparing the CSRF token in the request with the CSRF token in the cookie, it compares the CSRF token in the cookie against a CSRF token that is stored in the session. An attacker does not even need to provide a CSRF token in the request because the framework does not consider it. The cookies are automatically sent by the browser and the verification will always succeed, leading to a successful CSRF attack.

This release of Red Hat build of Eclipse Vert.x 4.3.7 GA includes security updates. For more information, see the release notes listed in the References section.Security Fix(es): codec-haproxy: HAProxyMessageDecoder Stack Exhaustion DoS (CVE-2022-41881) dev-java-snakeyaml: dev-java/snakeyaml: DoS via stack overflow (CVE-2022-41854) For more details about the security issue(s), including the impact, a CVSS score, acknowledgements, and other related information, refer to the CVE page(s) listed in the References section.

This release of Red Hat build of Eclipse Vert.x 4.3.4 GA includes security updates. For more information, see the release notes listed in the References section.Security Fix(es): snakeyaml: Constructor Deserialization Remote Code Execution (CVE-2022-1471) jackson-databind: deep wrapper array nesting wrt UNWRAPSINGLEVALUEARRAYS (CVE-2022-42003) jackson-databind: use of deeply nested arrays (CVE-2022-42004) For more details about the security issue(s), including the impact, a CVSS score, acknowledgements, and other related information, refer to the CVE page(s) listed in the References section.

This release of Red Hat build of Eclipse Vert.x 4.3.3 GA includes security updates. For more information, see the release notes listed in the References section.<br>Security Fix(es):<br><li> graphql-java: DoS by malicious query (CVE-2022-37734)</li> <li> snakeyaml: Denial of Service due missing to nested depth limitation for collections. (CVE-2022-25857)</li> <li> snakeyaml: Uncaught exception in org.yaml.snakeyaml.composer.Composer.composeSequenceNode (CVE-2022-38749)</li> <li> snakeyaml: Uncaught exception in org.yaml.snakeyaml.constructor.BaseConstructor.constructObject (CVE-2022-38750)</li> <li> snakeyaml: Uncaught exception in java.base/java.util.regex.Pattern$Ques.match (CVE-2022-38751)</li> <li> snakeyaml: Uncaught exception in java.base/java.util.ArrayList.hashCode (CVE-2022-38752)</li> For more details about the security issue(s), including the impact, a CVSS score, acknowledgements, and other related information, refer to the CVE page(s) listed in the References section.

This release of Red Hat build of Eclipse Vert.x 4.2.7 GA includes security updates. For more information, see the release notes listed in the References section.Security Fix(es): jackson-databind: denial of service via a large depth of nested objects (CVE-2020-36518) com.google.code.gson-gson: Deserialization of Untrusted Data in com.google.code.gson-gson (CVE-2022-25647) For more details about the security issue(s), including the impact, a CVSS score, acknowledgements, and other related information, refer to the CVE page(s) listed in the References section.

This release of Red Hat build of Eclipse Vert.x 4.2.5 GA includes security updates. For more information, see the release notes listed in the References section.Security Fix(es): kafka: Timing Attack Vulnerability for Apache Kafka Connect and Clients (CVE-2021-38153) For more details about the security issue(s), including the impact, a CVSS score, acknowledgements, and other related information, refer to the CVE page(s) listed in the References section.

This release of Red Hat build of Eclipse Vert.x 4.1.5 SP1 includes security updates. For more information, see the release notes listed in the References section.<br>Security Fix(es):<br><li> log4j-core: Remote code execution in Log4j 2.x when logs contain an attacker-controlled string value (CVE-2021-44228)</li> For more details about the security issues and their impact, the CVSS score, acknowledgements, and other related information, see the CVE pages listed in the References section.

This release of Red Hat build of Eclipse Vert.x 4.1.0 includes security updates, bug fixes, and enhancements. For more information, see the release notes listed in the References section.Security Fix(es): netty: Request smuggling via content-length header (CVE-2021-21409) apache-commons-io: Limited path traversal in Apache Commons IO 2.2 to 2.6 (CVE-2021-29425) For more details about the security issues and their impact, the CVSS score, acknowledgements, and other related information, see the CVE pages listed in the References section.

This release of Red Hat build of Eclipse Vert.x 3.9.1 includes security updates, bug fixes, and enhancements. For more information, see the release notes page listed in the References section.Security Fix(es): log4j: improper validation of certificate with host mismatch in SMTP appender (CVE-2020-9488) For more details about the security issues and their impact, the CVSS score, acknowledgements, and other related information, see the CVE pages listed in the References section.

This release of Red Hat build of Eclipse Vert.x 3.9.0 includes securityupdates, bug fixes, and enhancements. For more information, see the releasenotes page listed in the References section.Security Fix(es): netty: compression/decompression codecs don't enforce limits on buffer allocation sizes (CVE-2020-11612) For more details about the security issues and their impact, the CVSSscore, acknowledgements, and other related information, see the CVE pageslisted in the References section.

This release of Red Hat build of Eclipse Vert.x 3.8.5 includes security updates, bug fixes, and enhancements. For more information, see the release notes page listed in the References section.<br>Security Fix(es):<br><li> netty: HTTP request smuggling (CVE-2019-20444)</li> <li> netty: HttpObjectDecoder.java allows Content-Length header to accompanied by second Content-Length header (CVE-2019-20445)</li> <li> netty: HTTP Request Smuggling due to Transfer-Encoding whitespace mishandling (CVE-2020-7238)</li> For more details about the security issues and their impact, the CVSS score, acknowledgements, and other related information, see the CVE pages listed in the References section.

Red Hat Openshift Application Runtimes provides an application platformthat reduces the complexity of developing and operating applications(monoliths and microservices) for OpenShift as a containerized platform.The RHOAR Eclipse Vert.x 3.5.3 release serves as a replacement for RHOAR Eclipse Vert.x 3.5.1, and includes bug fixes and enhancements. For a detailed list of issues resolved in the community Eclipse Vert.x 3.5.3 release, see the release notes in the References section.Security Fix(es): vertx: Improper neutralization of CRLF sequences allows remote attackers to inject arbitrary HTTP response headers (CVE-2018-12537) vertx-web: Incomplete CSRF validation by CSRFHandler (CVE-2018-12540) For more details about the security issue(s), including the impact, a CVSS score, and other related information, refer to the CVE page(s) listed in the References section.

Red Hat Openshift Application Runtimes provides an application platformthat reduces the complexity of developing and operating applications(monoliths and microservices) for OpenShift as a containerized platform.The RHOAR Eclipse Vert.x 3.5.1 release serves as a replacement for RHOAR Eclipse Vert.x 3.4.2, and includes bug fixes and enhancements. For a detailed list of issues resolved in the community Eclipse Vert.x 3.5.1 release, see the release notes in the References section.Security Fix(es): jackson-databind: incomplete fix for CVE-2017-7525 permits unsafe serialization via c3p0 libraries (CVE-2018-7489) For more details about the security issue(s), including the impact, a CVSSscore, and other related information, refer to the CVE page(s) listed in the References section.