Heap exhaustion via unbounded simple string or bulk string allocation in Vert.x Redis client
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Exploited
- Proof of concept public, per CISA
- Fix
- No fix listed
- Who is exposed
- Not reported
- Exploitation15/40CISA rates a proof of concept as public
- Exposure17/25No login or user action needed per the CVSS vector, reachable over the network without a login · Data gap: No advisory context yet
- Reach?/20Reach: unknown (data gap). No tracked technology or package matched
- Severity5.9/10CVSS 5.9
- No patch5/5No patch listed yet
What would change the score
- Would score about 73 if added to CISA KEV
- Would score about 68 if CISA's SSVC rates exploitation active
- Would score about 48 if advisories confirm default setups are exposed
CVE-2026-118488 is not in CISA's Known Exploited Vulnerabilities (KEV) catalog. No public exploit code is tracked. It is rated CVSS 5.9 (medium) and affects Eclipse Vert.x; no fixed version is listed yet.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- Published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 43/100 · provisional
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: poc
- Automatable: no
- Technical impact: partial
Summary
The Eclipse Vert.x Redis client is affected, specifically its response parser for the Redis protocol (RESP). A malicious or compromised Redis server can send crafted responses that cause the client to consume unbounded memory or loop endlessly, which can lead to heap exhaustion and an out-of-memory crash.
Read the original description
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.
Timeline
- CVE published
- First seen by cve.now
- CISA SSVC assessment
Exploitation: poc · Automatable: no · Technical impact: partial
- Record last updated
Affected versions
- Eclipse Foundation Eclipse Vert.x
From 4.0.0 · through 4.5.35; From 5.0.0 · through 5.2.2
Evidence 2
- Advisory
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-118488
Is CVE-2026-118488 being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. CISA's SSVC assessment notes a proof of concept exists. No public exploit code is tracked.Source: cve.now feed data
Which versions are affected by CVE-2026-118488?
Eclipse Vert.x: from 4.0.0 through 4.5.35; from 5.0.0 through 5.2.2.Source: cve.now feed data