EUVD-2026-101937
GHSA-3f8m-f8fw-9m74
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach gRPC endpoint over network
-
DeliveryCraft tiny highly-compressed message
-
ExploitServer validates compressed size only
-
ExecutionDecompression triggers massive allocation
-
ImpactMemory exhaustion / service crash
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V2 - Validation and Business Logic Compression ratio limits
|
| Exploitation Conditions | Exploitation requires a vertx-grpc-server (io.vertx:vertx-grpc-server) gRPC endpoint that is network-reachable and accepts compressed gRPC messages (standard gRPC gzip/deflate message compression); the per-message maximum-size limit must be relied upon as the defense, since that limit is enforced only against compressed bytes. Affected versions are Eclipse Vert.x [4.0.0,4.5.34], [5.0.0,5.0.12], [5.1.0,5.1.9], and 5.2.0. No authentication is required (PR:N) and no user interaction is needed (UI:N). The main limiting factor is that the target must expose a gRPC server endpoint and permit client-supplied message compression; endpoints that reject compressed requests or are not internet-exposed are not practically affected. |
| Impact | This is a genuine but bounded denial-of-service risk, not a confidentiality/integrity breach. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) shows a remote, unauthenticated, low-complexity attack with no user interaction, and the impact is isolated to availability (VA:H; VC:N/VI:N), consistent with a compression-bomb memory-exhaustion flaw. The 8.7 'High' score is driven entirely by the ease of reaching the endpoint rather than by data exposure. No EPSS score, no CISA KEV listing, and no public exploit were provided in the input, so there is no evidence of active or widespread exploitation at this time - the severity is theoretical/structural rather than observed. Note a conflict in the metadata: the 'Information Disclosure' tag contradicts the CVSS vector, which explicitly sets confidentiality and integrity impact to None; the real impact is availability (resource exhaustion), so the tag should be disregarded. Overall this warrants prompt patching for exposed gRPC services but ranks below actively exploited or RCE-class issues. |
| Exploit ScenarioDerived | An attacker sends a small, highly compressed gRPC message (e.g. gzip-encoded) to a network-reachable vertx-grpc-server endpoint; the configured per-message maximum size is checked against the compressed bytes and passes, but on decompression the payload expands to many times that size, forcing large heap allocation. Repeating this exhausts memory and causes the service to degrade or crash (OutOfMemoryError). No public exploit code was identified at time of analysis, but the technique is trivial and requires no authentication. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 15, 2026
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.
RemediationAI
No vendor-released patch version is specified in the provided data, so the exact fixed releases must be taken from the vendor advisory GHSA-4wvq-75mw-q6cg (https://github.com/eclipse-vertx/vertx-grpc/security/advisories/GHSA-4wvq-75mw-q6cg) and the Eclipse work item https://gitlab.eclipse.org/security/cve-assignment/-/work_items/349; patch availability is not independently confirmed here, so treat 'check the advisory for the patched version' as the first action rather than assuming an existing fix. Until an upgrade is applied, the most effective compensating control is to disable or refuse inbound gRPC message compression on affected endpoints - reject the grpc-encoding header and only serve identity encoding, which removes the amplification primitive entirely at the cost of higher bandwidth for clients that legitimately send large payloads. Second, enforce a decompressed-body size cap outside Vert.x, for example at the reverse proxy, service mesh, or API gateway (nginx client_max_body_size, Envoy max_request_bytes on the decompressed path) so that oversized expansions are dropped before reaching the JVM; note that lowering Vert.x's own maxInboundMessageSize is not sufficient by itself because that limit applies to compressed bytes, though it still bounds the worst case. Third, cap resources so a single connection cannot exhaust the host: set JVM -Xmx and container/cgroup memory limits with restart policies, apply per-connection and per-IP rate limiting plus a maximum concurrent-stream limit, and restrict gRPC listener exposure to trusted networks or authenticated peers (mTLS) to shrink the attacker population. Be aware that aggressive connection/stream throttling can break legitimate high-throughput clients, and that memory capping converts a full outage into a crash-restart cycle rather than preventing the DoS.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
gRPC permits per-message compression, negotiated through the grpc-encoding header (typically gzip or deflate), and Vert.x's gRPC server exposes a configurable maximum inbound message size in bytes. The implementation applies that cap to the bytes received on the wire, i.e. the compressed representation, rather than to the size of the message after decompression, so a tiny compressed frame can expand into an arbitrarily large in-memory buffer during decompression. This is the classic decompression/compression-bomb pattern: small attacker input, disproportionate resource consumption, ending in heap exhaustion, excessive garbage-collection pressure, or OutOfMemoryError that takes down the endpoint and potentially the JVM hosting it. The affected artifact is io.vertx:vertx-grpc-server (the advisory text spells it 'vertx-gprc-server'), tracked under the wildcard CPE cpe:2.3:a:eclipse_foundation:eclipse_vert.x:*:*:*:*:*:*:*:*. No CWE identifier is assigned in the supplied data; the root-cause class maps to uncontrolled resource consumption (CWE-400) and improper handling of highly compressed data (CWE-409). No authentication is required (PR:N) and no user interaction is needed (UI:N), but the attacker must be able to open connections to a gRPC listener and have the compression capability accepted by that listener.
Know when Grpc gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Remote unauthenticated attacker sends a compressed message with no interaction (AV:N/AC:L/PR:N/UI:N); impact is memory-exhaustion DoS only, so C:N/I:N/A:H.
Primary rating from Vendor (eclipse).
CVSS VectorVendor: eclipse
DescriptionCVE.org
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.
Technical POC Analysis
Evidence note: the supplied evidence is the GitHub advisory for GHSA-4wvq-75mw-q6cg plus the CVE-2026-102477 description.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
Eclipse Vert.x deployments that expose the io.vertx:vertx-grpc-server component can be knocked offline by an unauthenticated remote attacker using only small compressed gRPC messages, causing memory exhaustion and an availability-only denial of service. Any internet- or partner-facing gRPC endpoint running an affected Vert.x release is in scope, and because no vendor patch is currently available, exposed services remain at risk until mitigations are applied. Leadership should care because the impact is service downtime for gRPC-dependent applications, not data loss or compromise.
No vendor-released patch identified at time of analysis. Interim mitigations: lower or enforce the per-message maximum size limit, disable client-supplied compression negotiation (gzip/deflate), restrict network reachability of gRPC endpoints to trusted sources, and apply rate limiting, connection caps, JVM heap limits, and memory-pressure monitoring. Apply vendor patch when released.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Denial of service against HTTP/2 server implementations allows remote unauthenticated attackers to exhaust server resour
Google gRPC before 2017-03-29 has an out-of-bounds write caused by a heap-based use-after-free related to the grpc_call_
Unsafe Erlang term deserialization in the elixir-grpc library (versions 0.4.0 through 1.0.0) allows unauthenticated remo
Memory exhaustion in gRPC-Go before version 1.83.1 allows an unauthenticated remote attacker to crash any service built
Unauthenticated denial of service in the elixir-grpc library (versions 0.3.1 up to but not including 1.0.0) allows a sin
Authorization bypass in elixir-grpc (grpc library for Elixir) versions 0.8.0 through 0.x allows authenticated attackers
Authorization bypass in the @grpc/grpc-js-xds package (the xDS/RBAC extension for @grpc/grpc-js) lets a request for one
It's possible for a gRPC client communicating with a HTTP/2 proxy to poison the HPACK table between the proxy and the ba
Google gRPC before 2017-02-22 has an out-of-bounds write caused by a heap-based buffer overflow related to the parse_uni
Google gRPC before 2017-02-22 has an out-of-bounds write related to the gpr_free function in core/lib/support/alloc.c. R
Google gRPC before 2017-04-05 has an out-of-bounds write caused by a heap-based buffer overflow related to core/lib/iomg
The package grpc before 1.24.4; the package @grpc/grpc-js before 1.1.8 are vulnerable to Prototype Pollution via loadPac
Exploit-DB