https://github.com/eclipse-vertx/vert.x/security/advisories/GHSA-ch7p-g5pm-3gqx advises: Vert.x HTTP/1.x decoder does not correctly handle canonicalized headers leading to request smuggling

vietj published GHSA-ch7p-g5pm-3gqx 3 weeks ago

Package: io.vertx:vertx-core (Maven) Affected versions: >= 5.0.0, <= 5.1.8 5.2.0 Patched versions: 5.1.10 5.2.1

Description -----------

Vert.x HTTP/1.x decoder uses a canonicalization for well known HTTP headers, the canonicalization process interprets well crafted headers as headers of this list, allowing for instance Content-Xength to be interpeted as Content-Length.

This can be exploited for request smuggling purpose.

Severity: High 7.5 / 10 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N CVE ID: CVE-2026-102479 Credits: @Michael-JRead Reporter https://research.jfrog.com/post/byte-debt-vertx-header-typo-session-fixation/ explores how this can be exploited and says that "vertx-core has around 2,100 Maven dependents and north of 300 million cumulative downloads, but those figures span the entire history of the project. The actual exposure window is narrow: three minor release branches shipped over a few months (5.0.0–5.0.12, 5.1.0–5.1.9, and 5.2.0), patched in 5.1.10 and 5.2.1. The takeaway isn't that Vert.x as a whole is broken, it is that if you deployed the modern 5.x line during that window, you are potentially vulnerable." and that "Our team was able to POC this vulnerability on several popular open source projects that use Vert.x webserver in the vulnerable version, in certain setups behind a frontend proxies such as: TechEmpower/FrameworkBenchmarks, strimzi/strimzi-kafka-bridge (0.33.0), apache/camel-quarkus".

In Eclipse Vert.x versions [4.0.0, 4.5.34] or [5.0.0,5.0.12] or [5.1.0,5.1.9] or [5.2.0, 5.2.0], the WebSocket implementation does not define a maximum number of bytes allocation when decompressing frames or messages. This can be used to implement DDOS attacks with a zip bomb.

The impacted component is io.vertx:vertx-core.

In Eclipse Vert.x versions [5.0.0,5.0.12] or [5.1.0,5.1.9] or [5.2.0, 5.2.0], the Vert.x HTTP/1.x decoder uses a canonicalization for well known HTTP headers, the canonicalization process interprets well crafted headers as headers of this list, allowing for instance Content-Xength to be interpeted as Content-Length.

This can be exploited for request smuggling purpose.

The impacted component is io.vertx:vertx-core.

In Eclipse Vert.x versions [5.0.0,5.0.12] or [5.1.0,5.1.9] or [5.2.0, 5.2.0], the Vert.x HTTP client relies on an SSL context for efficiency purpose, the key of this cache should reflect entirely the SSL semantics of the desired SSL properties. It is possible for a client to ask for an SSL context and obtain an SSL context with weaker properties, for instance a context with hostname validation and obtain a context ignoring hostname validation.

The impacted component is io.vertx:vertx-core.

In Eclipse Vert.x versions [4.0.0, 4.5.21] and [5.0.0, 5.0.4], a StaticHandler configuration for restricting access to hidden files fails to restrict access to hidden directories, allowing unauthorized users to retrieve files within them (e.g. '.git/config').

In Eclipse Vert.x versions [4.0.0, 4.5.21] and [5.0.0, 5.0.4], when "directory listing" is enabled, file and directory names are inserted into generated HTML without proper escaping in the href, title, and link attributes. An attacker who can create or rename files or directories within a served path can craft filenames containing malicious script or HTML content, leading to stored cross-site scripting (XSS) that executes in the context of users viewing the affected directory listing.

Since Vert.x 4.3.4 that leads to a memory leak when a TCP server is configured with TLS and SNI support: when such server processes an unknown SNI server name, that is a server name that would be assigned the default certificate instead of a server name mapped certificate, the SSL context will be cached in the server name map. This map should only contain server names for which the configuration provides a valid certificate. As a consequence, this can be exploited by client sending TLS client hello message with the server name extension indicating spurious server names and eventually trigger a JVM out of memory error.

This affects only TLS servers with SNI enabled https://vertx.io/docs/vertx-core/java/#servernameindicationsni.

It affects the maven artifact io.vertx:vertx-core versions 4.3.4,4.3.5,4.3.6,4.3.7,4.3.8,4.4.0,4.4.1,4.4.2,4.4.3,4.4.4,4.4.5,4.4.6,4.4.7,4.5.0,4.5.1,4.5.2

https://github.com/eclipse-vertx/vert.x/pull/5101 [Master] https://github.com/eclipse-vertx/vert.x/pull/5100 [4.x] https://github.com/eclipse-vertx/vert.x/pull/5099 [4.3]

There is a regression in Vert.x 4.4 branch that leads to a memory leak due to the use of Netty FastThreadLocal data structures.

As a consequence, when the Vert.x HTTP client connects to a different host, it does make the leak progress furthermore, there might be other cases leading to the same effect but exhibiting one seems enough to demonstrate the feasability.

Thus, this can be exploited with intimate knowledge of the runtime to accelerate the memory leak, e.g. a server accepting arbitrary internet addresses for which it will connect to could be fed with addresses as an attack vector.

This affects the maven artifact io.vertx:vertx-core versions 4.4.5, 4.4.6, 4.5.0, 4.5.1

https://github.com/eclipse-vertx/vert.x/issues/5078 https://github.com/eclipse-vertx/vert.x/pull/5082 https://github.com/eclipse-vertx/vert.x/pull/5080