Eclipse Vert.x EUVD-2026-101929

The target must run an affected Vert.x version (4.0.0-4.5.34, 5.0.0-5.0.12, 5.1.0-5.1.9, or 5.2.0) using the io.vertx:vertx-core WebSocket server/client, AND must have WebSocket frame/message compression (permessage-deflate) in effect so that attacker-supplied compressed frames are decompressed; the flaw is the absence of any maximum byte-allocation limit during that decompression. No authentication or user interaction is required (PR:N/UI:N), and default remote reachability applies. The practical limiting factor is that exploitation depends on compression being negotiated/enabled and only results in availability loss (service disruption / memory exhaustion), not code execution or data exposure.

This is a genuine availability/denial-of-service issue, not a confidentiality one. The provided CVSS 4.0 vector (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, base 8.7) is internally consistent with the description: network-reachable (AV:N), low complexity (AC:L), no authentication (PR:N) and no user interaction (UI:N), with impact confined entirely to availability (VA:H) and zero confidentiality or integrity impact (VC:N/VI:N). Note that the input Tag 'Information Disclosure' directly contradicts this vector - there is no confidentiality impact (VC:N), so that label appears mislabeled and should be treated as DoS/resource-exhaustion, not disclosure. No EPSS score, KEV listing, or POC indicator was supplied in the intelligence, so this is: no public exploit identified at time of analysis. The 8.7 score is driven by easy, unauthenticated remote reachability combined with a high availability impact; real-world priority is moderated by the fact that exploitation requires the target to have WebSocket permessage-deflate compression enabled, and the outcome is service disruption rather than code execution or data theft. Treat as a high-priority patch for internet-facing Vert.x services that accept compressed WebSocket traffic, but not a system-compromise emergency.

An unauthenticated remote attacker opens a WebSocket connection to a Vert.x-based service that negotiates permessage-deflate compression, then sends a small, highly compressed 'zip bomb' frame. Because the implementation sets no maximum byte allocation during decompression, the frame expands to consume excessive heap/memory, exhausting resources and denying service to legitimate users. No public exploit was identified in the provided data, though the technique (compression-ratio amplification) is well understood and trivial to reproduce.