EUVD-2026-36601
GHSA-jg62-j5h6-8mpq
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Network-reachable dashboard API requires only low-privilege auth; no complexity or interaction needed; impact is exclusively availability with no scope change.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
3DescriptionCVE.org
Nezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O&M tool. From version 1.0.0 to before version 2.2.0, the Nezha dashboard exposes two endpoints that create long-lived WebSocket streams to monitored agents: POST /api/v1/terminal → createTerminal() (terminal.go:27-67) and POST /api/v1/file → createFM() (fm.go:28-67). Both call rpc.NezhaHandlerSingleton.CreateStream(streamId, ...) which inserts a new ioStreamContext into an unbounded map[string]*ioStreamContext (s.ioStreams in io_stream.go:59-67). There is no per-user rate limit, no global semaphore, and no per-server connection cap. This issue has been patched in version 2.2.0.
AnalysisAI
Unbounded WebSocket stream allocation in Nezha Monitoring versions 1.0.0 through 2.1.x allows any authenticated dashboard user to exhaust server memory and crash the monitoring service. The two affected endpoints - POST /api/v1/terminal and POST /api/v1/file - each insert a long-lived ioStreamContext into a global Go map with no per-user rate limit, no global semaphore, and no per-server connection cap, making repeated calls a trivial denial-of-service vector. No public exploit code has been identified at time of analysis, and the issue is not listed in CISA KEV; the vendor released a patch in version 2.2.0.
Technical ContextAI
Nezha Monitoring is a self-hosted, Go-based server monitoring and operations tool (CPE: cpe:2.3:a:nezhahq:nezha). The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling). Two dashboard API handlers - createTerminal() at terminal.go:27-67 and createFM() at fm.go:28-67 - both call rpc.NezhaHandlerSingleton.CreateStream(streamId, ...), which inserts a new ioStreamContext into the global map[string]*ioStreamContext stored in s.ioStreams (io_stream.go:59-67). Because this map is unbounded and the stream lifecycle has no enforcement mechanism - no request quota per user, no system-wide cap on concurrent streams, and no eviction or timeout for idle entries - any caller with dashboard access can inflate this map without constraint until the Go runtime runs out of heap space.
RemediationAI
Upgrade Nezha Monitoring to version 2.2.0 or later, which introduces the necessary resource controls on stream creation for both the terminal and file manager endpoints. Full details are available in the vendor security advisory at https://github.com/nezhahq/nezha/security/advisories/GHSA-jg62-j5h6-8mpq. If an immediate upgrade is not possible, restrict dashboard access to the minimum set of trusted user accounts - since PR:L authentication is the sole barrier to exploitation, reducing credential exposure directly constrains attack surface. A reverse-proxy rate-limiting rule targeting POST /api/v1/terminal and POST /api/v1/file (for example, a per-session request-per-minute cap via nginx limit_req or HAProxy stick-tables) can throttle stream creation volume; note that overly aggressive rate limits may interfere with legitimate operator terminal and file-management sessions. Monitoring Go process heap growth on the dashboard host (e.g., via /debug/pprof or external memory alerting) can serve as an early detection signal for exploitation attempts.
Unauthenticated path traversal in Nezha Monitoring (nezhahq/nezha) before 2.0.13 allows remote attackers to read arbitra
Cross-tenant session hijacking in Nezha Monitoring (v1.14.13-1.14.14 and v2.0.0-2.0.9) lets any authenticated low-privil
Nezha Monitoring versions prior to 2.2.5 expose stored third-party API credentials in plaintext through two listing API
Host header injection in Nezha Monitoring versions 1.0.0 through 2.2.0 allows unauthenticated remote attackers to redire
Nezha Monitoring versions 2.0.14 through 2.1.0 (exclusive) allows any authenticated user to exploit the NAT-based Host c
Incorrect authorization in Nezha Monitoring's DDNS profile subsystem allows an authenticated low-privilege member to pre
Same technique Denial Of Service
View allVendor StatusVendor
SUSE
Severity: Moderate| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.5 | Affected |
| openSUSE Leap 15.6 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today