Summary
Nezha Monitoring: Unbounded WebSocket Streams, Resource Exhaustion DoS
1. Description
The Nezha dashboard exposes two endpoints that create long-lived WebSocket streams to monitored agents:
POST /api/v1/terminal→createTerminal()(terminal.go:27-67)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. Each stream allocates:
- A
ioStreamContextstruct with several channels and sync primitives - Two goroutines via
StartStream()(io_stream.go:358-369), bidirectionalio.CopyBuffer - A gRPC IOStream between the dashboard and the agent
- An agent-side PTY/shell process
Vulnerable code:
terminal.go:27-67, createTerminal:
func createTerminal(c *gin.Context) (*model.CreateTerminalResponse, error) {
// ... validation ...
rpc.NezhaHandlerSingleton.CreateStream(streamId, getUid(c), server.ID)
// ... sends TaskTypeTerminalGRPC to agent ...
return &model.CreateTerminalResponse{...}, nil
}
fm.go:28-67, createFM:
func createFM(c *gin.Context) (*model.CreateFMResponse, error) {
// ... validation ...
rpc.NezhaHandlerSingleton.CreateStream(streamId, getUid(c), server.ID)
// ... sends TaskTypeFM to agent ...
return &model.CreateFMResponse{...}, nil
}
io_stream.go:55-67, CreateStreamWithPurpose (inserts into unbounded map):
func (s *NezhaHandler) CreateStreamWithPurpose(...) {
s.ioStreamMutex.Lock()
defer s.ioStreamMutex.Unlock()
s.ioStreams[streamId] = &ioStreamContext{
creatorUserID: creatorUserID,
targetServerID: targetServerID,
purpose: purpose,
userIoConnectCh: make(chan struct{}),
agentIoConnectCh: make(chan struct{}),
revokedCh: make(chan struct{}),
}
}
io_stream.go:319-372, StartStream spawns two goroutines per stream:
func (s *NezhaHandler) StartStream(streamId string, timeout time.Duration) error {
// ...
go func() {
_, innerErr := io.CopyBuffer(userIo, agentIo, bp.buf)
errCh <- innerErr
}()
go func() {
_, innerErr := io.CopyBuffer(agentIo, userIo, bp.buf)
errCh <- innerErr
}()
return <-errCh
}
The NezhaHandler.ioStreams map is initialized as a plain make(map[string]*ioStreamContext) in nezha.go:36, no capacity limit, no eviction policy beyond explicit CloseStream / RevokeStreamsForServer.
The HasPermission check at terminal.go:41-43 and fm.go:43-45 controls access scope but does not limit creation volume. A user with ScopeServerExec (terminal) or ScopeServerRead+Write+Delete (file manager) can open unlimited streams.
2. PoC
A conceptual attack (no Docker needed):
# As an authenticated user with a valid JWT or PAT:
for i in {1..1000}; do
curl -X POST "https://dashboard.example.com/api/v1/terminal" \
-H "Authorization: Bearer $JWT" \
-H "Content-Type: application/json" \
-d '{"server_id": 1}' &
done
wait
Each request:
- Creates a new stream entry in
ioStreams - Sends a
TaskTypeTerminalGRPCtask to the agent - When the WebSocket attachment occurs (
GET /ws/terminal/{id}), spawns 2 goroutines for I/O relay and allocates a 1 MB buffer per goroutine
The attack targets three resource domains:
- Dashboard memory/goroutines, each stream adds goroutines, channels, and buffers
- Agent resources, each stream spawns a PTY/shell process on the monitored server
- gRPC connection pool, concurrent IOStreams consume gRPC multiplexing capacity
The POST /file (createFM) endpoint provides an alternative path with the same unbounded behavior, using ScopeServerRead+Write+Delete instead of ScopeServerExec.
3. Impact
- Denial of Service against the dashboard: memory exhaustion, goroutine starvation, or gRPC stream table overflow from rapid stream creation
- Denial of Service against monitored agents: each terminal session spawns a PTY process on the agent, an attacker can crash or degrade all agents behind the dashboard
- Operational cascade: if the dashboard OOMs, all agent monitoring and alerting is lost
- PAT connection-registry bypass: rapid create-connect-disconnect cycles may evade cleanup tracking
The attack requires only authenticated access with standard scopes, no special privileges. Any team member with terminal access to a server can DoS the entire infrastructure.
4. Remediation
Implement layered rate limiting and concurrency control:
Per-user stream cap in
CreateStream, reject if the user already has N active streams (e.g., 10 per user):func (s *NezhaHandler) CreateStreamWithPurpose(...) { s.ioStreamMutex.Lock() defer s.ioStreamMutex.Unlock() count := 0 for _, ctx := range s.ioStreams { if ctx.creatorUserID == creatorUserID { count++ } } if count >= maxStreamsPerUser { return error } // ... existing code ... }Per-server semaphore, limit concurrent streams to any single server (e.g., 20 per server)
Rate limiter on
createTerminalandcreateFM, mirror the existing MCP rate limiter (mcp_ratelimit.go) for legacy WebSocket endpointsAdd a configurable
MaxStreamsPerUser/MaxStreamsPerServersetting so operators can tune limits without code changes
Impact
The application allocates resources such as memory, threads, or file descriptors based on untrusted input without enforcing a cap. Typical impact: resource exhaustion leading to denial of service.
CVE-2026-53522 has a CVSS score of 6.5 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.2.0); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-53522? CVE-2026-53522 is a medium-severity allocation of resources without limits or throttling vulnerability in github.com/nezhahq/nezha (go), affecting versions >= 1.0.0, < 2.2.0. It is fixed in 2.2.0. The application allocates resources such as memory, threads, or file descriptors based on untrusted input without enforcing a cap.
- How severe is CVE-2026-53522? CVE-2026-53522 has a CVSS score of 6.5 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of github.com/nezhahq/nezha are affected by CVE-2026-53522? github.com/nezhahq/nezha (go) versions >= 1.0.0, < 2.2.0 is affected.
- Is there a fix for CVE-2026-53522? Yes. CVE-2026-53522 is fixed in 2.2.0. Upgrade to this version or later.
- Is CVE-2026-53522 exploitable, and should I be worried? Whether CVE-2026-53522 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-53522 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-53522? Upgrade
github.com/nezhahq/nezhato 2.2.0 or later.