Eclipse Vert X
Monthly
Heap exhaustion in the vertx-stomp module (Eclipse Vert.x) allows any connected peer to crash the affected JVM process, causing a complete denial of service; versions 4.0.0 through 4.5.35 and 5.0.0 through 5.2.2 are affected. Because FrameParser builds its RecordParser without a maxRecordSize limit, a peer that streams bytes without ever sending a newline makes the parser buffer indefinitely until JVM heap is exhausted. Both roles are exposed: a malicious STOMP client can attack a server before or after authentication, and a malicious STOMP server can attack a client that connects to it. No public exploit code was identified at time of analysis, but the flaw is remotely reachable without authentication or user interaction (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5 High) and vendor fixes exist in 4.5.36 and 5.2.3.
Eclipse Vert.x Web Client (maven io.vertx:vertx-web-client) versions 4.0.0 through 4.5.35 and 5.0.0 through 5.2.2 can leak one user's HTTP response to another user or to an anonymous caller when a single CachingWebClient is shared across user principals - the documented pattern of a per-user WebClientSession layered over a shared caching client. A user-specific but cacheable response that the origin did not mark private or no-store is written into the client-level shared cache tier under a key with no per-user marker, so a later session-private miss or an anonymous request for the same URL is served the stored body, disclosing authenticated content or, where the response carries Set-Cookie, a session identifier that can support session fixation or hijacking. The disclosed score of 7.5 reflects unauthenticated network access, but practical exposure is conditional: the shared-client deployment pattern and a permissive origin caching policy must both be present, no public exploit code has been identified at time of analysis, and the affected version ranges are bounded by fixed releases 4.5.36 and 5.2.3.
Unauthenticated remote attackers can exhaust server memory in Eclipse Vert.x deployments that expose the io.vertx:vertx-grpc-server component by sending small, highly compressed gRPC messages whose decompressed payload greatly exceeds the configured per-message maximum size, producing an availability-only denial-of-service condition. The affected ranges are Vert.x 4.0.0 through 4.5.34, 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0, and the flaw is only reachable when a gRPC endpoint is network-reachable and accepts client-supplied message compression (standard gRPC gzip/deflate negotiation). The source reports a CVSS 4.0 base score of 8.7 (AV:N/AC:L/AT:N/PR:N/UI:N/VA:H with no confidentiality or integrity impact); our independent CVSS 3.1 assessment agrees it is availability-only (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), and there is no public exploit code and no CISA KEV listing identified at time of analysis - the practical precondition is simply that the per-message size limit is being relied upon as the sole defense, since that limit is enforced against compressed bytes only.
Unbounded inbound memory retention in the Eclipse Vert.x MQTT client (io.vertx:vertx-mqtt) allows a malicious or compromised MQTT broker to drive the Vert.x process into memory exhaustion and eventual out-of-memory termination. Client-side applications embedded in Vert.x 4.0.0 through 4.5.34, 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0 that subscribe to QoS 2 (exactly-once) topics are affected; the attacker supplies QoS 2 PUBLISH packets with distinct packet identifiers and never sends the matching PUBREL, so each message is retained indefinitely in the client's internal qos2inbound map. The assessed vectors rate this AV:N/AC:H/PR:N with high availability impact only (no confidentiality or integrity impact), reflecting that exploitation requires the attacker to occupy the broker role rather than being an arbitrary remote peer; no confirmed active exploitation (CISA KEV) and no public exploit code were identified at time of analysis, and EPSS data was not provided. Note that the maxInflightQueue option does not mitigate this issue because it constrains only the outbound publish path.
Denial of service in Eclipse Vert.x JSON Schema validation (io.vertx:vertx-json-schema) allows a remote unauthenticated attacker to burn disproportionate CPU by sending a single moderately sized JSON array to any endpoint whose active schema uses the uniqueItems keyword. The affected ranges are 4.0.0 through 4.5.34, 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0, and the defect propagates to the dependent modules vertx-web-openapi-router, vertx-web-validation and vertx-openapi. No public exploit code was identified at time of analysis, yet the issue is rated CVSS 4.0 8.7 (HIGH) entirely on availability impact (VA:H with VC:N/VI:N), and applications that do not use uniqueItems in attacker-reachable schemas or that cap request body/array size upstream are not practically exploitable.
Unbounded direct-memory allocation in Eclipse Vert.x's MySQL client (io.vertx:vertx-mysql-client) versions 4.0.0 through 4.5.34, 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0 allows a malicious, compromised, or man-in-the-middle MySQL server to crash the client with an out-of-memory condition before authentication completes. The attacker sends a continuous stream of maximum-length (0xFFFFFF) MySQL protocol packets, preventing the decoder from reaching the end-of-message boundary. This is a denial-of-service issue; no public exploit code has been identified at time of analysis (not in CISA KEV).
An unbounded-memory denial of service in the Eclipse Vert.x PostgreSQL client (io.vertx:vertx-pg-client) allows a malicious, compromised, or man-in-the-middle PostgreSQL server to crash a client application by sending a wire-protocol message header whose 4-byte length field is set to an extremely large value (up to Integer.MAX_VALUE). The client-side decoder performs no maximum-size validation, so it keeps accumulating TCP data into a composite buffer until the JVM exhausts heap and terminates; the abuse happens during connection startup, before authentication completes, so no valid database credentials are required - the attacker only needs to control the server side of the connection or sit on the client-to-PostgreSQL TCP path. Per the independent assessment this is a genuine but conditional availability risk (CVSS 8.2, AV:N/AC:H, availability-only impact) rather than a mass-exploitation priority: no public exploit code or confirmed active exploitation was identified at time of analysis, and clients that connect exclusively to trusted, authenticated, TLS-verified PostgreSQL servers are not realistically exposed.
Denial of service in the Vert.x MySQL client (io.vertx:vertx-mysql-client) lets an attacker who controls or intercepts the client-to-database path crash a Vert.x application: a crafted MySQL result-set packet declaring an extremely large column count causes the client to attempt an unbounded heap allocation, and the resulting OutOfMemoryError kills the Netty event loop thread, taking down all connections and verticles in the process. Affected builds are 4.0.0 through 4.5.34, 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0, across all platforms where vertx-mysql-client is used. No authentication or user interaction is required once the hostile source or man-in-the-middle position exists (CVSS 4.0 PR:N), but the vendor rates the attack complexity as high (AC:H) because the database endpoint is normally trusted and operator-controlled; there is no public exploit identified at time of analysis, and the CVE is not listed in CISA KEV.
Denial of service in Eclipse Vert.x's vertx-pg-client component allows an attacker controlling the PostgreSQL server or positioned as a man-in-the-middle on an unencrypted connection to crash the client application. The flaw resides in the binary array decoder (DataTypeCodec.binaryDecodeArray), which allocates a Java array based on a server-supplied 32-bit dimension count without upper bound checking, leading to a multi-gigabyte heap allocation and OutOfMemoryError. Affected versions include 4.0.0 through 4.5.34, 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0. Exploitation requires no authentication (PR:N) but does require control of the database server or a MITM position on a non-TLS connection (AC:H), and no public exploit code has been identified at time of analysis.
Eclipse Vert.x DB2 Client versions 4.0.0 through 4.5.34, 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0 can deserialize attacker-controlled DRDA UDT column data, enabling remote code execution if a Java deserialization gadget chain is present on the classpath or denial of service otherwise. The affected component is io.vertx:vertx-db2-client, and exploitation requires an application to connect to a malicious or man-in-the-middle DRDA server that returns a result-set column tagged with FDOCA LID 0x50; legitimate DB2 servers never emit that type, and client-side TLS is disabled by default. The CVSS 4.0 score is 9.2 with PR:N, but practical exploitation requires attacker server-side/MITM position (AC:H) and, for RCE, a classpath gadget chain; no public exploit identified at time of analysis, and the real-world blast radius is narrower than the score alone suggests.
Unbounded direct-memory allocation in Eclipse Vert.x's MSSQL client (io.vertx:vertx-mssql-client) lets a malicious, compromised, or man-in-the-middle SQL Server endpoint crash a connecting client application by streaming TDS packets that never set the END_OF_MESSAGE status flag. Affected versions are [4.0.0, 4.5.34], [5.0.0, 5.0.12], [5.1.0, 5.1.9] and 5.2.0: the TDS message decoder aggregates inbound packets into a composite direct-memory buffer with no cumulative size cap, so the buffer grows until memory is exhausted and the process dies (availability impact only, with no confidentiality or integrity loss, per the assessed CVSS:3.1 vector AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H). The flaw is reachable before authentication completes, meaning no valid server credentials are required, but exploitation is not available to an arbitrary remote attacker - it demands control of, or a man-in-the-middle position on, the server side of the connection, which is why access complexity is rated High. No public exploit code or confirmed active exploitation was identified at time of analysis.
Denial of service in the Eclipse Vert.x Redis client (io.vertx:vertx-redis-client) affects versions 4.0.0 through 4.5.34, 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0: the RESP parser trusts a server-declared array, push, or attribute length and pre-allocates that many elements without an upper bound, so a crafted response triggers a massive heap allocation that terminates the Vert.x event-loop thread with OutOfMemoryError and denies service to every connection and verticle sharing that loop. Exploitation is conditional rather than opportunistic - a remote, unauthenticated attacker qualifies only if they control or have compromised the Redis server the client talks to, or if they can occupy a man-in-the-middle position on the client-to-Redis path; neither user interaction nor prior client authentication is required, which is why the assessed vector is AV:N/PR:N but AC:H, and impact is availability-only (no confidentiality or integrity loss). No public exploit code or confirmed active exploitation was identified at time of analysis, and this is a genuine but conditional DoS issue rather than a top-tier emergency.
Denial of service in Eclipse Vert.x HTTP proxy (io.vertx:vertx-http-proxy) affects versions 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0, allowing remote unauthenticated attackers to cause indefinite heap allocation. Exploitation requires the application to explicitly configure an intercepting body transformer-a non-default, developer-enabled feature-and the flaw lies in the transformer interceptor's reliance on a max buffered bytes limit that fails to keep per-request buffers bounded. No public exploit code has been identified at time of analysis; the CVSS 4.0 score is 8.7 with high availability impact.
Denial-of-service in Eclipse Vert.x allows unauthenticated remote attackers to exhaust server memory by sending compressed WebSocket frames that decompress to massive sizes (a zip bomb), because the WebSocket implementation lacks a maximum byte-allocation limit during decompression. Affected versions include 4.0.0 through 4.5.34, 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0, and exploitation requires WebSocket compression (permessage-deflate) to be negotiated. No public exploit code has been identified at time of analysis, but a vendor advisory (GHSA-h722-h6c2-6j3c) is available; the impact is limited to availability loss.
Cross-origin credential leakage in Eclipse Vert.x vertx-core (4.x through 4.5.29 and 5.x through 5.1.4) occurs because DefaultRedirectHandler copies all original request headers verbatim when the HttpClient follows an HTTP 30x redirect, stripping only Content-Length and never comparing the origin (scheme/host/port). An application that lets untrusted input influence a request URL - webhook dispatchers, image proxies, SSRF-style URL fetchers - can be steered to an attacker-controlled redirect target that then receives Authorization, Cookie, Proxy-Authorization, and custom headers like X-API-Token. No public exploit has been identified at time of analysis, and the flaw is not in CISA KEV.
Cross-domain cookie injection in Eclipse Vert.x Web Client (WebClientSession) lets any server a victim application contacts set a cookie scoped to an unrelated third-party domain, which the client later replays to that domain. Versions up to 4.5.29 (4.x) and 5.1.4 (5.x) fail to enforce the RFC 6265 Domain-attribute ownership check, so an attacker can bind their own session cookie into the victim's WebClientSession and have the victim's later requests to a target service execute under the attacker's account, exposing sensitive request payloads. No public exploit identified at time of analysis and it is not listed in CISA KEV; scored CVSS 4.0 8.2 (High) by Eclipse.
Heap exhaustion in the vertx-stomp module (Eclipse Vert.x) allows any connected peer to crash the affected JVM process, causing a complete denial of service; versions 4.0.0 through 4.5.35 and 5.0.0 through 5.2.2 are affected. Because FrameParser builds its RecordParser without a maxRecordSize limit, a peer that streams bytes without ever sending a newline makes the parser buffer indefinitely until JVM heap is exhausted. Both roles are exposed: a malicious STOMP client can attack a server before or after authentication, and a malicious STOMP server can attack a client that connects to it. No public exploit code was identified at time of analysis, but the flaw is remotely reachable without authentication or user interaction (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5 High) and vendor fixes exist in 4.5.36 and 5.2.3.
Eclipse Vert.x Web Client (maven io.vertx:vertx-web-client) versions 4.0.0 through 4.5.35 and 5.0.0 through 5.2.2 can leak one user's HTTP response to another user or to an anonymous caller when a single CachingWebClient is shared across user principals - the documented pattern of a per-user WebClientSession layered over a shared caching client. A user-specific but cacheable response that the origin did not mark private or no-store is written into the client-level shared cache tier under a key with no per-user marker, so a later session-private miss or an anonymous request for the same URL is served the stored body, disclosing authenticated content or, where the response carries Set-Cookie, a session identifier that can support session fixation or hijacking. The disclosed score of 7.5 reflects unauthenticated network access, but practical exposure is conditional: the shared-client deployment pattern and a permissive origin caching policy must both be present, no public exploit code has been identified at time of analysis, and the affected version ranges are bounded by fixed releases 4.5.36 and 5.2.3.
Unauthenticated remote attackers can exhaust server memory in Eclipse Vert.x deployments that expose the io.vertx:vertx-grpc-server component by sending small, highly compressed gRPC messages whose decompressed payload greatly exceeds the configured per-message maximum size, producing an availability-only denial-of-service condition. The affected ranges are Vert.x 4.0.0 through 4.5.34, 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0, and the flaw is only reachable when a gRPC endpoint is network-reachable and accepts client-supplied message compression (standard gRPC gzip/deflate negotiation). The source reports a CVSS 4.0 base score of 8.7 (AV:N/AC:L/AT:N/PR:N/UI:N/VA:H with no confidentiality or integrity impact); our independent CVSS 3.1 assessment agrees it is availability-only (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), and there is no public exploit code and no CISA KEV listing identified at time of analysis - the practical precondition is simply that the per-message size limit is being relied upon as the sole defense, since that limit is enforced against compressed bytes only.
Unbounded inbound memory retention in the Eclipse Vert.x MQTT client (io.vertx:vertx-mqtt) allows a malicious or compromised MQTT broker to drive the Vert.x process into memory exhaustion and eventual out-of-memory termination. Client-side applications embedded in Vert.x 4.0.0 through 4.5.34, 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0 that subscribe to QoS 2 (exactly-once) topics are affected; the attacker supplies QoS 2 PUBLISH packets with distinct packet identifiers and never sends the matching PUBREL, so each message is retained indefinitely in the client's internal qos2inbound map. The assessed vectors rate this AV:N/AC:H/PR:N with high availability impact only (no confidentiality or integrity impact), reflecting that exploitation requires the attacker to occupy the broker role rather than being an arbitrary remote peer; no confirmed active exploitation (CISA KEV) and no public exploit code were identified at time of analysis, and EPSS data was not provided. Note that the maxInflightQueue option does not mitigate this issue because it constrains only the outbound publish path.
Denial of service in Eclipse Vert.x JSON Schema validation (io.vertx:vertx-json-schema) allows a remote unauthenticated attacker to burn disproportionate CPU by sending a single moderately sized JSON array to any endpoint whose active schema uses the uniqueItems keyword. The affected ranges are 4.0.0 through 4.5.34, 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0, and the defect propagates to the dependent modules vertx-web-openapi-router, vertx-web-validation and vertx-openapi. No public exploit code was identified at time of analysis, yet the issue is rated CVSS 4.0 8.7 (HIGH) entirely on availability impact (VA:H with VC:N/VI:N), and applications that do not use uniqueItems in attacker-reachable schemas or that cap request body/array size upstream are not practically exploitable.
Unbounded direct-memory allocation in Eclipse Vert.x's MySQL client (io.vertx:vertx-mysql-client) versions 4.0.0 through 4.5.34, 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0 allows a malicious, compromised, or man-in-the-middle MySQL server to crash the client with an out-of-memory condition before authentication completes. The attacker sends a continuous stream of maximum-length (0xFFFFFF) MySQL protocol packets, preventing the decoder from reaching the end-of-message boundary. This is a denial-of-service issue; no public exploit code has been identified at time of analysis (not in CISA KEV).
An unbounded-memory denial of service in the Eclipse Vert.x PostgreSQL client (io.vertx:vertx-pg-client) allows a malicious, compromised, or man-in-the-middle PostgreSQL server to crash a client application by sending a wire-protocol message header whose 4-byte length field is set to an extremely large value (up to Integer.MAX_VALUE). The client-side decoder performs no maximum-size validation, so it keeps accumulating TCP data into a composite buffer until the JVM exhausts heap and terminates; the abuse happens during connection startup, before authentication completes, so no valid database credentials are required - the attacker only needs to control the server side of the connection or sit on the client-to-PostgreSQL TCP path. Per the independent assessment this is a genuine but conditional availability risk (CVSS 8.2, AV:N/AC:H, availability-only impact) rather than a mass-exploitation priority: no public exploit code or confirmed active exploitation was identified at time of analysis, and clients that connect exclusively to trusted, authenticated, TLS-verified PostgreSQL servers are not realistically exposed.
Denial of service in the Vert.x MySQL client (io.vertx:vertx-mysql-client) lets an attacker who controls or intercepts the client-to-database path crash a Vert.x application: a crafted MySQL result-set packet declaring an extremely large column count causes the client to attempt an unbounded heap allocation, and the resulting OutOfMemoryError kills the Netty event loop thread, taking down all connections and verticles in the process. Affected builds are 4.0.0 through 4.5.34, 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0, across all platforms where vertx-mysql-client is used. No authentication or user interaction is required once the hostile source or man-in-the-middle position exists (CVSS 4.0 PR:N), but the vendor rates the attack complexity as high (AC:H) because the database endpoint is normally trusted and operator-controlled; there is no public exploit identified at time of analysis, and the CVE is not listed in CISA KEV.
Denial of service in Eclipse Vert.x's vertx-pg-client component allows an attacker controlling the PostgreSQL server or positioned as a man-in-the-middle on an unencrypted connection to crash the client application. The flaw resides in the binary array decoder (DataTypeCodec.binaryDecodeArray), which allocates a Java array based on a server-supplied 32-bit dimension count without upper bound checking, leading to a multi-gigabyte heap allocation and OutOfMemoryError. Affected versions include 4.0.0 through 4.5.34, 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0. Exploitation requires no authentication (PR:N) but does require control of the database server or a MITM position on a non-TLS connection (AC:H), and no public exploit code has been identified at time of analysis.
Eclipse Vert.x DB2 Client versions 4.0.0 through 4.5.34, 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0 can deserialize attacker-controlled DRDA UDT column data, enabling remote code execution if a Java deserialization gadget chain is present on the classpath or denial of service otherwise. The affected component is io.vertx:vertx-db2-client, and exploitation requires an application to connect to a malicious or man-in-the-middle DRDA server that returns a result-set column tagged with FDOCA LID 0x50; legitimate DB2 servers never emit that type, and client-side TLS is disabled by default. The CVSS 4.0 score is 9.2 with PR:N, but practical exploitation requires attacker server-side/MITM position (AC:H) and, for RCE, a classpath gadget chain; no public exploit identified at time of analysis, and the real-world blast radius is narrower than the score alone suggests.
Unbounded direct-memory allocation in Eclipse Vert.x's MSSQL client (io.vertx:vertx-mssql-client) lets a malicious, compromised, or man-in-the-middle SQL Server endpoint crash a connecting client application by streaming TDS packets that never set the END_OF_MESSAGE status flag. Affected versions are [4.0.0, 4.5.34], [5.0.0, 5.0.12], [5.1.0, 5.1.9] and 5.2.0: the TDS message decoder aggregates inbound packets into a composite direct-memory buffer with no cumulative size cap, so the buffer grows until memory is exhausted and the process dies (availability impact only, with no confidentiality or integrity loss, per the assessed CVSS:3.1 vector AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H). The flaw is reachable before authentication completes, meaning no valid server credentials are required, but exploitation is not available to an arbitrary remote attacker - it demands control of, or a man-in-the-middle position on, the server side of the connection, which is why access complexity is rated High. No public exploit code or confirmed active exploitation was identified at time of analysis.
Denial of service in the Eclipse Vert.x Redis client (io.vertx:vertx-redis-client) affects versions 4.0.0 through 4.5.34, 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0: the RESP parser trusts a server-declared array, push, or attribute length and pre-allocates that many elements without an upper bound, so a crafted response triggers a massive heap allocation that terminates the Vert.x event-loop thread with OutOfMemoryError and denies service to every connection and verticle sharing that loop. Exploitation is conditional rather than opportunistic - a remote, unauthenticated attacker qualifies only if they control or have compromised the Redis server the client talks to, or if they can occupy a man-in-the-middle position on the client-to-Redis path; neither user interaction nor prior client authentication is required, which is why the assessed vector is AV:N/PR:N but AC:H, and impact is availability-only (no confidentiality or integrity loss). No public exploit code or confirmed active exploitation was identified at time of analysis, and this is a genuine but conditional DoS issue rather than a top-tier emergency.
Denial of service in Eclipse Vert.x HTTP proxy (io.vertx:vertx-http-proxy) affects versions 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0, allowing remote unauthenticated attackers to cause indefinite heap allocation. Exploitation requires the application to explicitly configure an intercepting body transformer-a non-default, developer-enabled feature-and the flaw lies in the transformer interceptor's reliance on a max buffered bytes limit that fails to keep per-request buffers bounded. No public exploit code has been identified at time of analysis; the CVSS 4.0 score is 8.7 with high availability impact.
Denial-of-service in Eclipse Vert.x allows unauthenticated remote attackers to exhaust server memory by sending compressed WebSocket frames that decompress to massive sizes (a zip bomb), because the WebSocket implementation lacks a maximum byte-allocation limit during decompression. Affected versions include 4.0.0 through 4.5.34, 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0, and exploitation requires WebSocket compression (permessage-deflate) to be negotiated. No public exploit code has been identified at time of analysis, but a vendor advisory (GHSA-h722-h6c2-6j3c) is available; the impact is limited to availability loss.
Cross-origin credential leakage in Eclipse Vert.x vertx-core (4.x through 4.5.29 and 5.x through 5.1.4) occurs because DefaultRedirectHandler copies all original request headers verbatim when the HttpClient follows an HTTP 30x redirect, stripping only Content-Length and never comparing the origin (scheme/host/port). An application that lets untrusted input influence a request URL - webhook dispatchers, image proxies, SSRF-style URL fetchers - can be steered to an attacker-controlled redirect target that then receives Authorization, Cookie, Proxy-Authorization, and custom headers like X-API-Token. No public exploit has been identified at time of analysis, and the flaw is not in CISA KEV.
Cross-domain cookie injection in Eclipse Vert.x Web Client (WebClientSession) lets any server a victim application contacts set a cookie scoped to an unrelated third-party domain, which the client later replays to that domain. Versions up to 4.5.29 (4.x) and 5.1.4 (5.x) fail to enforce the RFC 6265 Domain-attribute ownership check, so an attacker can bind their own session cookie into the victim's WebClientSession and have the victim's later requests to a target service execute under the attacker's account, exposing sensitive request payloads. No public exploit identified at time of analysis and it is not listed in CISA KEV; scored CVSS 4.0 8.2 (High) by Eclipse.