CVE-2024-8391 Overview
CVE-2024-8391 is a resource exhaustion vulnerability in the Eclipse Vert.x gRPC server. Affected versions 4.3.0 through 4.5.9 do not enforce a maximum length on incoming message payloads. A remote, unauthenticated attacker can send oversized gRPC messages to exhaust server memory and degrade availability. The flaw maps to CWE-770: Allocation of Resources Without Limits or Throttling. The issue is fixed in Vert.x 4.5.10. The vulnerability affects the io.vertx:vertx-grpc-server and io.vertx:vertx-grpc-client artifacts but does not affect the grpc-java/Netty-based io.vertx:vertx-grpc artifact.
Critical Impact
Unauthenticated remote attackers can trigger denial-of-service conditions by sending unbounded gRPC payloads to vulnerable Vert.x services.
Affected Products
- Eclipse Vert.x 4.3.0 through 4.5.9 (io.vertx:vertx-grpc-server)
- Eclipse Vert.x 4.3.0 through 4.5.9 (io.vertx:vertx-grpc-client)
- Not affected: io.vertx:vertx-grpc (grpc-java/Netty-based implementation)
Discovery Timeline
- 2024-09-04 - CVE-2024-8391 published to NVD
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2024-8391
Vulnerability Analysis
The Vert.x gRPC server processes inbound message frames without enforcing an upper bound on payload size. When the server deserializes a gRPC message, it allocates buffers sized to the declared length of the incoming frame. Without a configured limit, an attacker can declare arbitrarily large payloads and force the JVM to allocate memory proportional to attacker-controlled input. This leads to heap pressure, garbage-collection thrashing, and potential OutOfMemoryError conditions that terminate or destabilize the service.
The weakness falls under CWE-770 because the server allocates resources based on untrusted input without throttling. The EPSS probability is 0.58% (percentile 43.16) as of the latest scoring.
Root Cause
The Vert.x-native gRPC implementation in vertx-grpc-server and vertx-grpc-client lacked the equivalent of grpc-java's maxInboundMessageSize enforcement. Incoming message length fields were trusted and used to drive buffer allocation directly. The companion implementation built on grpc-java and Netty (io.vertx:vertx-grpc) inherits the upstream library's default 4 MiB limit and is therefore not affected.
Attack Vector
An attacker reaches a publicly exposed Vert.x gRPC endpoint over the network with no authentication or user interaction required. The attacker sends a crafted gRPC request whose message length header declares a very large payload, or streams a continuous flow of large payloads. The server attempts to buffer each request in memory, consuming available heap until the process becomes unresponsive or crashes. Repeated requests amplify the impact and can take down multiple gRPC service instances behind a load balancer.
No public exploit code or proof-of-concept has been published. See the GitHub issue report for the upstream technical discussion.
Detection Methods for CVE-2024-8391
Indicators of Compromise
- Sudden spikes in JVM heap usage on Vert.x gRPC services followed by OutOfMemoryError entries in application logs.
- gRPC requests with abnormally large Content-Length or framed message length headers from a small set of source IPs.
- Repeated process restarts of Vert.x application containers correlated with inbound HTTP/2 traffic on gRPC ports.
Detection Strategies
- Inventory Java dependencies for io.vertx:vertx-grpc-server or io.vertx:vertx-grpc-client at versions 4.3.0 through 4.5.9 using SBOM tooling or mvn dependency:tree.
- Inspect HTTP/2 traffic to gRPC endpoints for frames exceeding a sane application-defined size threshold (for example, greater than 4 MiB).
- Correlate application-level memory pressure metrics with inbound request volume per source IP to identify amplification patterns.
Monitoring Recommendations
- Alert on JVM heap-usage exceeding 85% sustained for more than one minute on hosts running Vert.x gRPC services.
- Track HTTP/2 DATA frame sizes at the ingress proxy and flag outliers for review.
- Monitor gRPC request error rates, particularly RESOURCE_EXHAUSTED and UNAVAILABLE status codes, as early indicators of abuse.
How to Mitigate CVE-2024-8391
Immediate Actions Required
- Upgrade io.vertx:vertx-grpc-server and io.vertx:vertx-grpc-client to version 4.5.10 or later.
- Place gRPC endpoints behind a reverse proxy or API gateway that enforces request-size limits until patching completes.
- Restrict network exposure of gRPC services so that only trusted clients can reach them during remediation.
Patch Information
Eclipse has released a fix in Vert.x 4.5.10. The patched version introduces a configurable maximum message length for the Vert.x-native gRPC server and client. Refer to the Eclipse GitLab CVE assignment issue and the upstream GitHub issue for fix details. Applications relying on io.vertx:vertx-grpc (grpc-java/Netty-based) do not require this update for this CVE.
Workarounds
- Terminate gRPC traffic at a proxy such as Envoy or NGINX and set an explicit max_request_bytes or equivalent body-size limit.
- Apply per-source rate limiting and connection caps in front of Vert.x services to reduce amplification potential.
- Reduce JVM heap exposure by running Vert.x services with tight memory limits and restart policies so a single instance failure does not cascade.
# Update Maven coordinates to the fixed Vert.x release
# pom.xml
# <dependency>
# <groupId>io.vertx</groupId>
# <artifactId>vertx-grpc-server</artifactId>
# <version>4.5.10</version>
# </dependency>
mvn versions:set-property -Dproperty=vertx.version -DnewVersion=4.5.10
mvn clean verify
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
