Vert.x Redis Client CVE-2026-118488

Exploitation requires the Vert.x Redis client to process RESP responses from a server the attacker controls, has compromised, or can MITM - this is the essential precondition, since typical deployments connect to a trusted operator-owned Redis instance. Two concrete triggers are described: (1) a server that keeps streaming bytes on an EOL-terminated line (e.g. a simple string) without ever sending the terminating CRLF, causing unbounded buffer growth because there is no configurable limit on EOL-terminated lines; and (2) a server that sends a bulk string with a missing/corrupt CRLF trailer (e.g. $3\r\nfooXX), forcing the parser into an infinite loop that repeatedly re-parses and re-emits the same response. Both affect default configurations of vulnerable versions (no special client setting is needed), but no authentication is bypassed and only availability is affected; the limiting factor is the need for a malicious or compromised server/connection path. Fixed in 5.2.3 (5.x) and 4.5.36 (4.x); updating is the remediation given by the advisory.

This is a moderate, availability-only denial-of-service issue (CVSS 5.9, CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) - impact is confined to A:H, with no confidentiality or integrity exposure. The AV:N/PR:N/UI:N metrics look alarming in isolation, but the decisive limiting factor is not captured well by the vector: exploitation requires the Vert.x Redis client to receive malicious RESP bytes, i.e. the Redis server it connects to must be attacker-controlled, compromised, or the connection MITM'd. In normal deployments clients talk to a trusted, operator-owned Redis instance, which is why AC:H is justified and why real-world exploitability is narrower than a raw network-unauthenticated reading suggests. No EPSS score and no CISA KEV entry are present in the input, and there is no 'Publicly available (confirmed)' exploit flag; the GHSA advisory contains a conceptual proof-of-concept description rather than verified working exploit code. The vuln.today decision label is 'this_month', consistent with a real but non-emergency DoS that should be patched on a normal cadence rather than treated as active-exploitation firefighting. Net: a genuine bug worth remediating (unbounded heap growth can crash a service), but a measured priority - not a high-CVSS-but-illusory issue, yet also not an emergency.

An attacker who controls or compromises the Redis server a Vert.x application connects to (or who can MITM that connection) returns a crafted RESP response - either a simple string whose bytes never terminate with CRLF, or a bulk string such as $3\r\nfooXX with a corrupted CRLF trailer. The client either grows its read buffer without bound or enters an infinite parse loop re-emitting the same response, exhausting the JVM heap and crashing the application. The advisory documents a conceptual proof-of-concept, but a public working exploit is not confirmed in the available data.