Nezha Monitoring EUVD-2026-36601

Exploitation requires a valid Nezha dashboard account at any privilege level (PR:L per CVSS vector) - no administrative role is needed. The attacker must have network access to the Nezha dashboard HTTP(S) service (AV:N). No special non-default configuration is required; the vulnerable endpoints POST /api/v1/terminal and POST /api/v1/file are standard core API routes present in all 1.0.0-2.1.x deployments. Exploitation is bounded by the following limiting factors: (1) unauthenticated users cannot reach the vulnerable handlers, so valid credentials are a hard prerequisite; (2) the speed of memory exhaustion depends on the host's available RAM - well-resourced servers tolerate more sustained abuse before crashing; and (3) streams require a WebSocket upgrade, so the attacker's connection setup overhead slightly slows the flood compared to a pure HTTP request flood.

The CVSS 3.1 score of 6.5 (Medium) with vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H is a fair representation of real-world risk. The low-complexity, network-accessible attack is offset by the PR:L requirement, meaning unauthenticated exploitation is not possible. No EPSS score was provided in the input; given the niche, self-hosted deployment model of Nezha and the authenticated access barrier, mass opportunistic exploitation appears unlikely. The absence of a CISA KEV listing and the absence of known public exploit code further support a non-emergency classification. However, for operators whose threat model includes malicious or compromised internal users - such as teams granting dashboard access to multiple personnel - the risk is meaningful: a single low-privilege account is sufficient to blind all monitoring visibility by crashing the dashboard. The impact being purely availability (C:N/I:N/A:H) limits lateral blast radius, but a downed monitoring dashboard can mask real incidents on monitored infrastructure. No conflicting signals exist between the CVSS vector and the description; the network vector and low-privilege requirement are consistent with the dashboard API architecture described.

An attacker who has obtained a low-privilege Nezha dashboard account - whether via credential theft, a shared team account, or a compromised user - writes a simple loop that issues repeated POST requests to /api/v1/terminal or /api/v1/file. Each request registers a new ioStreamContext in the global unbounded map without triggering any server-side limit, causing heap allocation to grow continuously until the Go runtime crashes the dashboard process and monitoring visibility is lost for all operators.