Centrifugo CVE-2026-62963

Exploitation requires that the target run the unidirectional WebSocket transport with uni_websocket.compression explicitly enabled - this is the exact precondition named in the description, and instances with compression disabled are not affected. Given that condition, the attacker needs only network reachability to the /connection/uni_websocket endpoint and no authentication (CVSS PR:N), no user interaction (UI:N), and low complexity (AC:L). Limiting factors: the compression feature must be turned on (a non-guaranteed deployment setting), the endpoint must be network-reachable, and impact is confined to availability (VA:H) with no confidentiality or integrity effect. Versions at or above 6.8.4 cap decompressed output and are not exploitable.

The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H) scores 8.7 and is internally consistent with the description: network-reachable, low complexity, unauthenticated, with a pure availability impact and no confidentiality or integrity loss. This is a genuine DoS, not a data-breach vector, so the 'Information Disclosure' tag in the intelligence feed appears to be a mislabel and should be disregarded. Real-world priority is moderated by one deployment precondition: exploitation only works when uni_websocket.compression is enabled, so instances without WebSocket compression are not affected. No EPSS score was supplied, there is no KEV listing, and no POC is referenced, so this is a high-severity-by-design availability issue rather than a signal of active mass exploitation. For internet-facing Centrifugo instances that expose the uni_websocket endpoint with compression on, the ease of unauthenticated triggering makes it a legitimate patch priority despite the absence of exploitation evidence.

An unauthenticated attacker who can reach a Centrifugo instance's /connection/uni_websocket endpoint negotiates permessage-deflate compression and sends a highly compressible frame (e.g. a few kilobytes of repeated bytes) that stays under message_size_limit on the wire. The server decompresses it via io.ReadAll with no output cap, allocating hundreds of megabytes and burning CPU; repeating this across many connections exhausts server memory and degrades or crashes the service. No POC is currently referenced in the available intelligence.