chenyme grok2api EUVD-2026-118382

Requires a valid grok2api client key (PR:L - authenticated), and exploitation targets the voice/STT WebSocket proxy feature (proxyVoiceWebSocket in voice_ws_handler.go) specifically. The concrete trigger per the code evidence is establishing quiet, idle voice WebSocket sessions: because such connections have no in-flight read/write, the server.requestTimeout cancellation is never surfaced, so closeAll previously ran only on a pump transport error, leaving the session, its account lease, and concurrency slot held. Limiting factors: an attacker must be authenticated with a client key, impact is confined to availability (VA:L - no data exposure or integrity impact), and only the voice/STT WebSocket surface is affected. Fixed in 3.1.7.

This is a genuine but moderate-priority availability issue, not a high-impact emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) and the 5.3 score describe a network-reachable, low-complexity flaw that nonetheless requires authentication (PR:L - a valid grok2api client key) and produces only limited availability impact (VA:L; VC:N/VI:N), consistent with the CWE-400 resource-consumption class. The signals are coherent rather than conflicting: the vuln.today decision label is 'this_month' (not act_now/emergency), there is no CISA KEV listing, no EPSS score is supplied in the input, and no public exploit is identified. Exploitation status is therefore 'no public exploit identified at time of analysis.' The code evidence confirms the mechanism is not memory corruption or RCE but unreleased sessions/account leases on idle WebSocket connections, which caps real-world blast radius to availability degradation of the proxy. Net: patch on a normal cadence; the authentication requirement and availability-only impact make this a lower priority than the raw network-vector label might suggest, and the absence of EPSS/KEV/POC data means spread is unverified rather than confirmed low.

An attacker holding a valid client key opens multiple voice/STT WebSocket connections to the proxy and leaves them established but idle. Because a quiet, established WebSocket has no in-flight read or write to surface the server.requestTimeout cancellation of the request context, the sessions and their associated account leases are never torn down, so repeated connections progressively exhaust concurrency slots and account leases. No public exploit is identified at time of analysis.