Search
Search Results (5 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-118489 | 2 Eclipse, Eclipse Foundation | 2 Vert.x, Vert.x | 2026-11-03 | 7.5 High |
| In Eclipse Vert.x versions [4.0.0,4.5.35] or [5.0.0,5.2.2], when one `CachingWebClient` is shared across users — the documented pattern of a per-user `WebClientSession` over a shared caching client — a response that is specific to one user but is cacheable and not marked `private`/`no-store` is stored in the client-level shared cache tier and served to other users requesting the same URL. A later user's session, or an anonymous caller through the same client, can receive an earlier user's response. Depending on the response this discloses authenticated content or a session cookie, the latter enabling session fixation or hijacking. | ||||
| CVE-2026-118488 | 2 Eclipse, Eclipse Foundation | 2 Vert.x, Vert.x | 2026-11-03 | 5.9 Medium |
| In Eclipse Vert.x versions [4.0.0, 4.5.35] or [5.0.0, 5.2.2], when a malicious server keeps sending bytes on an EOL-terminated line (not length-prefixed, for example a simple string [1]), we'll keep growing the buffer without bounds, eventually leading to an OOM. We need to have a configurable limit for EOL-terminated lines. If a malicious server sends a specially crafted RESP response (for example a bulk string [2] with missing CRLF trailer), the parser enters an infinite loop where it keeps parsing the same buffer and pushing the same response to the caller, which may lead e.g. to an OOM if the consumer just buffers the responses. We must fix the parser to avoid this infinite looping. | ||||
| CVE-2026-118487 | 2 Eclipse, Eclipse Foundation | 2 Vert.x, Vert.x | 2026-11-03 | 7.5 High |
| In Eclipse Vert.x versions [4.0.0, 4.5.35] or [5.0.0, 5.2.2], the `FrameParser` in vertx-stomp creates a `RecordParser` without setting `maxRecordSize`, so any peer that streams bytes continuously without a newline character causes the parser to accumulate data indefinitely. Both the STOMP server and the STOMP client are affected: a malicious server can exploit this against a connecting client, and a malicious client can exploit this against a server before or after authentication. Sustained byte streaming exhausts JVM heap memory, crashing the affected process and causing a complete denial of service. | ||||
| CVE-2026-1002 | 2 Eclipse, Eclipse Foundation | 4 Vert.x, Vert.x-web, Vert.x Core and 1 more | 2026-04-18 | 5.3 Medium |
| 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); | ||||
| CVE-2024-8391 | 3 Eclipse, Eclipse Foundation, Redhat | 6 Vert.x, Vert.x, Camel Quarkus and 3 more | 2024-09-12 | 7.5 High |
| 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) | ||||
Page 1 of 1.