Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
- 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…
Recommended action: Upgrade to 5.0.5 or 4.5.22 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 Potential Impact 1. Information Disclosure Examples of sensitive files that could be…
Recommended action: Upgrade to 5.0.5 or 4.5.22 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 4.3.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own 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.
Recommended action: Upgrade to 3.9.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 4.0.0-milestone5 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 3.5.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In version from 3.0.0 to 3.5.2 of Eclipse Vert.x, the CSRFHandler do not assert that the XSRF Cookie matches the returned XSRF header/form parameter. This allows replay attacks with previously issued tokens which are not expired yet.
Recommended action: Upgrade to 3.5.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.