Eclipse Foundation vulnerabilities
228 vulnerabilities
Known vulnerabilities in Eclipse Foundation products, newest first, with CVSS severity, EPSS, KEV listings and ransomware use, across 81 products.
Products
50 of 81- Netx Duo32 vulnerabilities
- Eclipse Vert.X20 vulnerabilities
- Eclipse Jetty15 vulnerabilities
- Threadx14 vulnerabilities
- Eclipse Glassfish12 vulnerabilities
- Eclipse Theia12 vulnerabilities
- Eclipse Milo6 vulnerabilities
- Jetty6 vulnerabilities
- Eclipse Aerios4 vulnerabilities
- Eclipse Ankaios4 vulnerabilities
- Eclipse Ditto4 vulnerabilities
- Eclipse OMR4 vulnerabilities
- Mosquitto4 vulnerabilities
- Openj94 vulnerabilities
- USBX4 vulnerabilities
- Eclipse Connected Services Platform3 vulnerabilities
- Eclipse CSI PIA3 vulnerabilities
- Eclipse Open VSX3 vulnerabilities
- Eclipse Openj93 vulnerabilities
- Eclipse Threadx Netx Duo3 vulnerabilities
- Eclipse Threadx/Netxduo3 vulnerabilities
- Eclipse Arrowhead2 vulnerabilities
- Eclipse Basyx2 vulnerabilities
- Eclipse Che2 vulnerabilities
- Eclipse Kuksa Databroker2 vulnerabilities
- Eclipse Openmq2 vulnerabilities
- Glassfish2 vulnerabilities
- GUIX2 vulnerabilities
- Nextx Duo2 vulnerabilities
- Open J92 vulnerabilities
- Parsson2 vulnerabilities
- Vert.X2 vulnerabilities
- Adoptium Temurin1 vulnerabilities
- Bluechi1 vulnerabilities
- Eclipse 4Diac1 vulnerabilities
- Eclipse Accessibility Tools Framework (Actf)1 vulnerabilities
- Eclipse Basyx Java Server SDK1 vulnerabilities
- Eclipse Basyx AAS Web UI1 vulnerabilities
- Eclipse Basyx Go Components1 vulnerabilities
- Eclipse Cyclone DDS1 vulnerabilities
- Eclipse Data Plane Core1 vulnerabilities
- Eclipse Dataspace Components1 vulnerabilities
- Eclipse EDC Connector1 vulnerabilities
- Eclipse Embedded CDT (C/C++ Development Tools)1 vulnerabilities
- Eclipse Iceoryx™1 vulnerabilities
- Eclipse IDE1 vulnerabilities
- Eclipse Jetty EE81 vulnerabilities
- Eclipse Jetty EE91 vulnerabilities
- Eclipse Jgit1 vulnerabilities
- Eclipse Kura1 vulnerabilities
CVE-2026-93649eclipse foundationadoptium temurin
EPSS score0.16%
In the Eclipse Adoptium website (adoptium.net), in every deployment built from commit 0b24ea1 (2025-06-18) up to the fix in commit cbb53cf (2026-09-24), the post-download page /[locale]/download takes a download URL from the "link" query parameter and automatically navigates to it with a meta http-equiv="refresh". The URL is checked against a list of trusted prefixes using String.startsWith() on the raw string, while the browser applies RFC 3986 dot-segment normalisation before navigating, so a value such as https://github.com/adoptium/temurin/../../attacker/malware/releases/download/v1/jdk.exe passes the check but resolves to an attacker-controlled repository. A victim who follows a crafted adoptium.net link is shown the genuine "Thank you for downloading Eclipse Temurin" page while their browser downloads a binary of the attacker's choosingCVE-2026-110724eclipse foundationeclipse connected services platformEPSS score0.27%
In `api-gateway` versions till `1.7.3`, The default rate-limit key resolver, `ClientIpKeyResolver`, derives the per-client bucket key from the leftmost element of the `X-Forwarded-For` request header. That element is supplied by the originating HTTP client and is not validated against any trusted-proxy list. A single attacker can therefore obtain an unlimited number of independent rate-limit buckets — one per unique header value — and completely bypass the gateway's request-rate limiting on every route that uses the shipped default configuration.CVE-2026-110723eclipse foundationeclipse connected services platformEPSS score0.34%
In `api-gateway` versions till `1.7.3`, The default rate-limit key resolver, `ClientIpKeyResolver`, derives the per-client bucket key from the leftmost element of the `X-Forwarded-For` request header. That element is supplied by the originating HTTP client and is not validated against any trusted-proxy list. A single attacker can therefore obtain an unlimited number of independent rate-limit buckets — one per unique header value — and completely bypass the gateway's request-rate limiting on every route that uses the shipped default configuration.CVE-2026-110726eclipse foundationeclipse connected services platformEPSS score0.19%
In `api-gateway` versions till `1.7.3`, The default rate-limit key resolver, `ClientIpKeyResolver`, derives the per-client bucket key from the leftmost element of the `X-Forwarded-For` request header. That element is supplied by the originating HTTP client and is not validated against any trusted-proxy list. A single attacker can therefore obtain an unlimited number of independent rate-limit buckets — one per unique header value — and completely bypass the gateway's request-rate limiting on every route that uses the shipped default configuration.CVE-2026-103224eclipse foundationeclipse vert.xEPSS score0.32%
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 MySQL message decoder aggregates inbound multi-packet payloads into a composite direct-memory buffer without any cumulative size limit. A malicious, compromised, or man-in-the-middle MySQL server can send a continuous stream of packets with the maximum payload length (0xFFFFFF), preventing the end-of-message condition from being reached, causing unbounded direct-memory allocation on the client and leading to an out-of-memory crash. This occurs before authentication completes.
The impacted component is io.vertx:vertx-mysql-client.CVE-2026-103223eclipse foundationeclipse vert.xEPSS score0.32%
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 PostgreSQL message decoder reads the 4-byte message length field from the PostgreSQL wire protocol without any maximum validation. A malicious, compromised, or man-in-the-middle PostgreSQL server can send a message header with the length field set to an extremely large value (up to Integer.MAX_VALUE), causing the decoder to accumulate subsequent TCP data into a composite buffer without bound, leading to unbounded memory allocation on the client and an out-of-memory crash. This occurs before authentication completes.
The impacted component is io.vertx:vertx-pg-client.CVE-2026-102477eclipse foundationeclipse vert.xEPSS score0.32%
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 gRPC endpoint does have a configurable per message maximum size in bytes, however the maximum size applies to the received bytes. When applied to a compressed message, this only applies to the compressed size and not the actual size of the uncompressed content. This can be used to force a gRPC endpoint to allocate more bytes than the value defined by the configuration, making the endpoint vulnerable to compression bomb attacks.
The impacted component is io.vertx:vertx-gprc-server.CVE-2026-102469eclipse foundationeclipse vert.xEPSS score0.42%
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 Vert.x DB2 client (vertx-db2-client) contains DRDA protocol handling code that deserializes User Defined Type (UDT) column data using a bare ObjectInputStream.readObject() call with no ObjectInputFilter or class allowlist.
This code path is triggered when a DRDA server sends a result set with a column tagged as UDT (FDOCA protocol LID 0x50). However, DB2 does not support this type of UDT. The FDOCA 0x50 type is never sent by a legitimate DB2 server.
Nevertheless, a malicious or man-in-the-middle DRDA server could craft a response with a 0x50-tagged column, causing the client to deserialize arbitrary attacker-controlled bytes on the Vert.x event loop before any application code can inspect or reject the data. If a Java deserialization gadget chain is present on the application's classpath, this enables remote code execution. Without a gadget chain, denial of service is possible via crafted object graphs. TLS is disabled by default, making man-in-the-middle exploitation feasible.
The impacted component is io.vertx:vertx-db2-client.CVE-2026-102466eclipse foundationeclipse vert.xEPSS score0.26%
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 Vert.x MySQL client (vertx-mysql-client) pre-allocates an array for column definitions based on a server-declared column count with no upper-bound validation. A malicious or compromised MySQL server, or an attacker with man-in-the-middle positioning, can send a crafted result set packet with an extremely large column count, causing the client to attempt a massive heap allocation. The resulting OutOfMemoryError crashes the Netty event loop thread, causing a complete denial of service for all connections and verticles in the Vert.x application.
The impacted component is io.vertx:vertx-mysql-client.CVE-2026-102464eclipse foundationeclipse vert.xEPSS score0.28%
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 Eclipse Vert.x MQTT (vertx-mqtt) MqttClient stores every inbound QoS 2 PUBLISH message received from the broker in an internal map (qos2inbound) while awaiting the corresponding PUBREL packet to complete the QoS 2 handshake. This map has no size limit; the maxInflightQueue option is enforced only on the outbound publish path and does not constrain inbound message retention.
A malicious or compromised MQTT broker can exploit this by sending QoS 2 PUBLISH messages with distinct packet identifiers and withholding the PUBREL responses. Each incomplete handshake causes the client to retain the full publish message (topic, payload, and metadata) indefinitely, leading to unbounded memory growth in the Vert.x process. This can degrade the MQTT-consuming application or cause out-of-memory termination.
The impacted component is io.vertx:vertx-mqtt.CVE-2026-102463eclipse foundationeclipse vert.xEPSS score0.28%
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 binary array decoder in vertx-pg-client (DataTypeCodec.binaryDecodeArray) allocates a Java array sized by a server-declared 32-bit dimension count with no upper bound. A malicious or compromised PostgreSQL server, or an on-path attacker intercepting an unencrypted connection, can send a crafted DataRow message with an excessively large array dimension value, causing the client to attempt a multi-gigabyte heap allocation and crash with an OutOfMemoryError.
The impacted component is io.vertx:vertx-pg-client.CVE-2026-102462eclipse foundationeclipse vert.xEPSS score0.32%
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 TDS message decoder in the Vert.x MSSQL client (vertx-mssql-client) aggregates inbound TDS packets into a composite direct-memory buffer without any cumulative size limit. A malicious, compromised, or man-in-the-middle SQL Server can send a continuous stream of TDS packets without setting the END_OF_MESSAGE status flag, causing unbounded direct-memory allocation on the client and leading to an out-of-memory crash. This occurs before authentication completes.
The impacted component is io.vertx:vertx-mssql-client.CVE-2026-102461eclipse foundationeclipse vert.xEPSS score0.40%
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 uniqueItems keyword validation uses an O(n²) pairwise comparison loop with no short-circuit or size limit. A remote unauthenticated attacker can submit a moderately-sized JSON array that consumes disproportionate CPU time, leading to denial of service.
The impacted component is io.vertx:vertx-json-schema.
The following Vert.x modules depend on vertx-json-schema and are also affected:
io.vertx:vertx-web-openapi-router io.vertx:vertx-web-validation io.vertx:vertx-openapiCVE-2026-76182debianjetty12+3EPSS score0.27%
In Eclipse Jetty, `TryPathsHandler` and `TryFilesFilter` can be configured to forward requests to template URIs such as `index?p=$path`, where `$path` is the request path in context.
However, URI paths may contain characters that are reserved in URI queries so that a path of `/s&a=1` when applied to the template becomes `index?p=/s&a=1`, which is interpreted as 2 query parameters: `p=/s` and `a=1`, rather than just one query parameter `p` whose value is `/s&a=1`.CVE-2026-77711debianjetty12+3EPSS score0.32%
When Jetty's `HttpClient` make a request to a server through a forward proxy, the server may reply with a 407 (Proxy Authentication Required).
The client mistakenly interprets the 407 as coming from the proxy, so it re-sends the request with the `Proxy-Authentication` header, which arrives to the server, that now has access to the proxy credentials.CVE-2026-76184debianjetty12+3EPSS score0.28%
In Eclipse Jetty, HttpClient may receive a redirect of the form:
```
/secure/../evil
```
If an attacker is able to control the redirects, then HttpClient matches authentication credentials against `/secure` rather than normalizing the path to `/evil`, and will therefore follow the redirect sending the `Authorization` header for `/secure` to `/evil`.
This also mean that the attacker must have an evil application deployed on the same domain as the target.CVE-2026-102475eclipse foundationeclipse vert.xEPSS score0.26%
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 HTTP proxy provides a body transformer interceptor that relies on a max buffered bytes limit to ensure a bounded buffer for each request. This can be used to force a server to indefinitely allocate heap. This vulnerability requires to use an intercepting body transformer.
The impacted component is io.vertx:vertx-http-proxy.CVE-2026-102467eclipse foundationeclipse vert.xEPSS score0.26%
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.CVE-2026-102465eclipse foundationeclipse vert.xEPSS score0.21%
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 Vert.x Redis client RESP parser pre-allocates arrays to a length declared by the server without enforcing an upper bound. A malicious or compromised Redis server, or an attacker in a man-in-the-middle position, can send a crafted RESP response declaring an extremely large array, push, or attribute length, causing the client to attempt a massive heap allocation. The resulting OutOfMemoryError crashes the Vert.x event loop thread, denying service to all connections and verticles sharing that loop.
The impacted component is io.vertx:vertx-mysql-client.CVE-2026-102476eclipse foundationeclipse vert.xEPSS score0.23%
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.