Nezha EUVD-2026-102565

Exploitation requires an authenticated dashboard account that has been granted file-manager scope (PR:L), and the attacker must reach the dashboard's WebSocket endpoint /api/v1/ws/file/:id and send one oversized binary message that the unbounded fmStream reader buffers. The key limiting factors are: valid credentials are mandatory (not exploitable pre-auth), the account must specifically hold file-manager permissions, and the affected version must be between 1.0.0 and 2.3.15 (fixed in 2.3.15, which caps complete messages at 1 MiB). Impact is confined to availability - the dashboard process is OOM-killed, severing monitoring for all agents - with no data disclosure or modification.

This is a genuine but moderate-priority availability issue, not a critical emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H) scoring 7.1 is internally consistent with the description: network-reachable, low complexity, but requiring low-level privileges (PR:L) - an authenticated account with file-manager scope - and impacting availability only (VA:H), with no confidentiality or integrity impact. The PR:L requirement is the single most important risk-limiter: an attacker must already hold a valid, file-manager-scoped account, so this is not internet-wide pre-auth DoS. No EPSS score was provided, there is no CISA KEV listing, and no public POC is referenced - so no public exploit identified at time of analysis. However, the vendor security advisory (GHSA-7242-982f-83p9) and a confirmed fix commit exist, and the root cause (missing gorilla/websocket SetReadLimit) is trivially understood and reproducible from the patch diff, meaning weaponization effort is very low once an attacker has credentials. There are no conflicting signals: the vector, description, and patch all agree this is an authenticated, network-triggered memory-exhaustion DoS. The realistic priority is elevated for multi-tenant or shared Nezha dashboards where lower-trust users hold file-manager scope, and lower for single-operator self-hosted instances where the only account holders are already trusted admins.

An attacker holding a Nezha dashboard account with file-manager scope (for example, a low-trust team member on a shared instance) opens the file-manager WebSocket at /api/v1/ws/file/:id and sends a single oversized binary message. Because fmStream never sets a read limit, gorilla/websocket buffers the entire attacker-sized frame in memory, triggering an out-of-memory kill of the dashboard process and dropping monitoring for all connected agents. No public exploit code is identified, but the fix commit publicly reveals the exact root cause, making reproduction straightforward.