---
id: "CVE-2026-118488"
kind: "vulnerability"
aliases: ["CVE-2026-118488"]
title: "Eclipse Vert.x: unbounded buffering from malicious server can exhaust memory"
severity: "medium"
cvss: 5.9
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["java", "package", "redis-client", "vert.x"]
not_affected_if: ["trusted-servers-only", "unaffected-version"]
published_at: "2026-11-03T15:17:24+00:00"
first_seen_at: "2026-11-03T15:21:56+00:00"
updated_at: "2026-11-03T15:23:24+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-118488", "first_seen_at": "2026-11-03T15:21:56+00:00"}]
---

# Eclipse Vert.x: unbounded buffering from malicious server can exhaust memory

Eclipse Vert.x's RESP and line-based parsers keep growing a buffer when a malicious server sends bytes without a line terminator, and a malformed RESP bulk string can make the parser loop on the same data. An attacker-controlled server can cause out-of-memory conditions in a client that reads from it.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check the Vert.x version in the project's dependency tree, for example with `mvn dependency:tree` or `gradle dependencies`, and compare it to the affected ranges.
- Look for use of Vert.x Redis or RESP client code connecting to servers you do not fully control.

## Fix

- Eclipse Vert.x 4.x: move to a version after `4.5.35`.
- Eclipse Vert.x 5.x: move to a version after `5.2.2`.

## Timeline

- 2026-11-03T15:21:56+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-118488

## Documents

- [advisory] Vendor advisory: github.com https://github.com/vert-x3/vertx-redis-client/security/advisories/GHSA-7f58-g87w-gx7p

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_