Search
Search Results (9 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-102476 | 2 Eclipse, Eclipse Foundation | 2 Vert.x, Vert.x | 2026-11-10 | N/A |
| 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. | ||||
| CVE-2026-102460 | 2 Eclipse, Eclipse Foundation | 2 Vert.x, Vert.x | 2026-11-10 | 5.9 Medium |
| 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], a scope bypass vulnerability exists in Eclipse Vert.x Web's ChainAuthHandler when used with scope-requiring authentication handlers such as JWTAuthHandler or OAuth2AuthHandler. When a user is already authenticated on the routing context by a preceding handler in the request pipeline, ChainAuthHandler skips all scope validation configured via withScope() or withScopes(). This affects both any() and all() chain modes. The root cause is that postAuthentication() relies on internal state that is only set during the authenticate() phase, which is skipped entirely for pre-authenticated users. In any() mode, the absence of this state causes the method to fall through without delegating scope checks to any handler. In all() mode, scope checks are unconditionally skipped. This allows a user with a valid token but insufficient scopes to access resources protected by scope requirements, provided they were authenticated by an earlier handler in the pipeline. The most common trigger is overlapping authentication handlers on nested routes, where a parent route authenticates broadly and a child route uses a chain to enforce specific scopes. The impacted component Maven coordinate is io.vertx:vertx-web | ||||
| CVE-2026-102479 | 2 Eclipse, Eclipse Foundation | 2 Vert.x, Vert.x | 2026-11-10 | 5.9 Medium |
| 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. | ||||
| CVE-2026-102471 | 2 Eclipse, Eclipse Foundation | 2 Vert.x, Vert.x | 2026-11-10 | 5.9 Medium |
| 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 vertx-mail-client does not sanitize CR (\r) or LF (\n) characters in user-supplied email header names and values before writing them into the SMTP DATA section. A CR/LF sequence embedded in a name or value passed to MailMessage.addHeader(), MailMessage.setHeaders(), MailAttachment.addHeader(), or MailAttachment.setHeaders() is written verbatim to the wire, allowing an attacker to inject arbitrary headers (e.g. Bcc, Reply-To, Content-Type) or prepend body content to the outgoing message. The same weakness affects MIME part metadata set via MailAttachment.setContentType(), setDisposition(), setDescription(), and setContentId(), which are written directly into MIME part headers without validation. A secondary weakness in Utils.mustEncode(char) additionally allows a bare LF in a From display-name to bypass Q-encoding and reach the wire unchanged. An unauthenticated attacker who can control any header name, header value, or attachment metadata field passed to the mail client (for example via a web form or API that feeds into MailMessage) can exploit this to redirect email copies, spoof headers, or tamper with message structure. The impacted component is io.vertx:vertx-mail-client. | ||||
| 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-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-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.