CVE-2026-53522: Nezha Monitoring DoS Vulnerability

CVE-2026-53522 Overview

CVE-2026-53522 is a resource exhaustion vulnerability in Nezha Monitoring, a self-hostable server and website monitoring and operations tool. The flaw affects versions from 1.0.0 to before 2.2.0. The Nezha dashboard exposes two endpoints that create long-lived WebSocket streams to monitored agents without any rate limiting, global semaphore, or per-server connection cap. An authenticated low-privilege user can repeatedly invoke these endpoints to exhaust dashboard and agent resources. The issue is tracked under [CWE-770: Allocation of Resources Without Limits or Throttling] and has been patched in version 2.2.0.

Critical Impact
An authenticated attacker can exhaust memory and connection resources on the Nezha dashboard and monitored agents, resulting in denial of service.

Affected Products

Nezha Monitoring dashboard versions 1.0.0 through 2.1.x
nezhahq/nezha server component (terminal and file manager modules)
Monitored agents connected to a vulnerable dashboard

Discovery Timeline

2026-06-12 - CVE-2026-53522 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2026-53522

Vulnerability Analysis

The Nezha dashboard exposes two endpoints that establish persistent WebSocket streams to monitored agents. The POST /api/v1/terminal endpoint invokes createTerminal() in terminal.go:27-67, and POST /api/v1/file invokes createFM() in fm.go:28-67. Both handlers call rpc.NezhaHandlerSingleton.CreateStream(streamId, ...). Each call inserts a new ioStreamContext into the unbounded s.ioStreams map declared as map[string]*ioStreamContext at io_stream.go:59-67. The implementation enforces no per-user rate limit, no global semaphore, and no per-server connection cap. An authenticated user can issue thousands of requests, each spawning a long-lived stream that consumes memory, file descriptors, and goroutines on both the dashboard and the target agent.

Root Cause

The root cause is missing resource governance on stream allocation. The ioStreams map grows without bound because the CreateStream path lacks any admission control. There is no cap on concurrent streams per user, per target server, or globally across the dashboard process.

Attack Vector

Exploitation requires network access to the dashboard API and valid low-privilege authentication. The attacker repeatedly issues POST /api/v1/terminal or POST /api/v1/file requests, each producing a new WebSocket-backed ioStreamContext. Sustained request volume drives memory growth and goroutine accumulation, eventually causing dashboard and agent processes to become unresponsive. No user interaction is required and the attack scales linearly with request rate.

No verified public proof-of-concept code is available. See the GitHub Security Advisory GHSA-jg62-j5h6-8mpq for the maintainer technical write-up.

Detection Methods for CVE-2026-53522

Indicators of Compromise

High-volume POST /api/v1/terminal or POST /api/v1/file requests originating from a single authenticated session or source IP
Sustained growth in dashboard process memory, goroutine count, and open file descriptors without a proportional increase in legitimate users
Agent processes reporting elevated CPU or memory usage and dropped heartbeat connections

Detection Strategies

Monitor HTTP access logs for repeated calls to /api/v1/terminal and /api/v1/file from the same principal within short time windows
Track the size of the in-memory stream map by inspecting /debug/pprof heap profiles or runtime metrics if exposed
Alert on anomalous WebSocket connection counts between the dashboard and any single agent

Monitoring Recommendations

Forward dashboard access logs and process metrics to a centralized logging or SIEM pipeline for correlation
Establish baselines for normal terminal and file manager session counts per user role
Configure alerts when concurrent stream counts exceed expected operational thresholds

How to Mitigate CVE-2026-53522

Immediate Actions Required

Upgrade Nezha Monitoring to version 2.2.0 or later, which contains the official fix
Restrict dashboard API exposure to trusted networks using a reverse proxy or firewall rules
Audit existing dashboard user accounts and remove or rotate credentials for accounts that do not require terminal or file access

Patch Information

The vulnerability is patched in Nezha Monitoring version 2.2.0. Refer to the GitHub Security Advisory GHSA-jg62-j5h6-8mpq for release notes and upgrade guidance. Operators running versions 1.0.0 through 2.1.x should plan an immediate upgrade.

Workarounds

Place the dashboard behind a reverse proxy that enforces request rate limits on /api/v1/terminal and /api/v1/file
Apply network-level connection limits per source IP using nginx, haproxy, or iptables rules
Limit dashboard accounts with terminal or file manager permissions to a minimal set of trusted operators

bash

# Example nginx rate limiting for vulnerable endpoints
limit_req_zone $binary_remote_addr zone=nezha_streams:10m rate=5r/m;

location ~ ^/api/v1/(terminal|file)$ {
    limit_req zone=nezha_streams burst=2 nodelay;
    limit_conn_zone $binary_remote_addr zone=nezha_conn:10m;
    limit_conn nezha_conn 3;
    proxy_pass http://nezha_dashboard_upstream;
}