CVE-2026-53522: Nezha Monitoring Resource Exhaustion via Unbounded WebSocket Streams

Technical summary

The vulnerability exists in two dashboard endpoints—POST /api/v1/terminal and POST /api/v1/file—that open WebSocket streams to monitored agents via rpc.NezhaHandlerSingleton.CreateStream(). Each call inserts an ioStreamContext into an unbounded map without rate limiting, global semaphores, or per-server connection caps. An authenticated user can trigger unlimited stream creation, causing unbounded memory consumption and eventual denial of service. The flaw is rooted in io_stream.go's unrestricted map growth (lines 59-67) combined with the absence of connection pooling or throttling logic in both terminal.go and fm.go handlers.

Business impact

An insider or attacker with compromised dashboard credentials can disable monitoring visibility by crashing the Nezha dashboard. In distributed infrastructure deployments, loss of the monitoring plane prevents detection of real infrastructure incidents, delays incident response, and creates a window for undetected compromise. Organizations relying on Nezha for compliance reporting or SLA verification may also face documentation gaps during outages.

Affected systems

Nezha Monitoring versions 1.0.0 through 2.1.x are vulnerable. The fix is available in version 2.2.0 and later. Any Nezha installation exposed to users with dashboard authentication—whether internal staff or federated identity—is at risk. Deployments in high-trust network segments are lower-risk than those accessible from less-trusted networks, but credential compromise remains a viable attack vector.

Exploitability

Exploitation requires valid Nezha dashboard credentials (PR:L per CVSS vector), but no special complexity or user interaction. An authenticated attacker can invoke the vulnerable endpoints via HTTP/WebSocket with minimal effort. No exploit code is required; a simple loop making repeated API calls suffices. The barrier to exploitation is primarily credential acquisition, not technical sophistication. However, the attack is not yet in the wild and carries no known active exploitation.

Remediation

Upgrade Nezha to version 2.2.0 or later, which patches the unbounded stream creation by introducing connection limits and rate-limiting logic. Verify the upgrade against the official Nezha release notes and changelog. During patching, temporarily restrict dashboard access via network segmentation or WAF rules to reduce credential exposure risk. After patching, audit WebSocket connection logs for signs of prior exhaustion attempts.

Patch guidance

Obtain version 2.2.0 from the official Nezha repository. Review the patch release notes to confirm remediation scope. In production, plan a maintenance window to restart the Nezha service cleanly after upgrade; WebSocket connections will briefly disconnect during the restart, which is expected. Test the upgrade in a staging environment first, validating that all monitored agents reconnect and that terminal/file management endpoints function normally. No database migration or configuration change is required for this patch.

Detection guidance

Monitor Nezha dashboard logs for repeated stream creation from a single user within short time windows. Alert on rising ioStreams map size (if metrics are exposed) or memory growth correlated with API calls to /api/v1/terminal or /api/v1/file. Network-level detection: look for a single source IP repeatedly opening WebSocket connections to the dashboard on ports typically used by Nezha (default 8008 for HTTP, verify for your deployment). Check for unusual authentication patterns or credential use outside normal business hours or from unexpected locations.

Why prioritize this

This vulnerability scores CVSS 6.5 MEDIUM because it requires authentication and causes only availability impact, not confidentiality or integrity breaches. However, it directly threatens operational visibility in monitoring infrastructure, making it more urgent in practice than the score suggests. Prioritize patching if your Nezha dashboard is accessible to less-trusted users, has shared or federated credentials, or if you have recent evidence of suspicious credential activity. Organizations with air-gapped or strictly role-limited Nezha deployments can schedule patching in normal change windows.

Risk score, explained

The CVSS 3.1 score of 6.5 reflects attack vector network (reachable over the network), low attack complexity (no special conditions required), and requirement for low-privilege authentication. The primary impact is availability (denial of service via resource exhaustion), hence the A:H rating. The score does not weigh the operational criticality of losing monitoring, which is context-dependent; your organization may internally prioritize this higher if monitoring loss creates compliance violations or cascades to undetected production incidents.

Frequently asked questions