Nezha versions from 2.2.5 up to but not including 2.3.15 have an information disclosure vulnerability. Authenticated users with the nezha:ddns:read scope can retrieve third-party credentials because the listDDNS API endpoint does not redact sensitive fields such as WebhookURL and WebhookRequestBody. This allows reading cleartext tokens embedded in users' DDNS webhook profiles.
Nezha from 1.7.0 before 2.3.15 contains an information disclosure vulnerability that allows authenticated members to enumerate other tenants' server IDs through differential responses. Attackers can sweep sequential IDs against getServerConfig and setServerConfig, distinguishing 'permission denied' from success payloads to map other users' servers.
Nezha versions from 2.1.0 up to but not including 2.3.15 contain a host header injection vulnerability in the mintTransferTool component. This vulnerability allows attackers who can control the Host header in a victim's MCP request to manipulate file upload and download URLs. Exploitation could enable redirection of file uploads or capture and replay of one-time download tokens to exfiltrate files. The vulnerability has a medium severity with a CVSS 4.0 score of 6.3.
Nezha versions 1.0.0 up to but not including 2.3.15 have a memory exhaustion vulnerability in the dashboard file manager WebSocket endpoint. This occurs because the fmStream component does not set a read limit on incoming messages, allowing authenticated users with file manager permissions to send an oversized binary message. Exploiting this can cause an out-of-memory (OOM) kill, which disrupts agent monitoring.
Nezha versions from 2.0.13 up to but not including 2.3.15 have a resource exhaustion vulnerability. Authenticated users can open unlimited concurrent WebSocket connections to the /api/v1/ws/transfer endpoint, causing exhaustion of file descriptors, memory, and goroutines. This can block agent gRPC reconnections and degrade service availability.
CVE-2026-100394 is a race condition vulnerability in nezhahq's Nezha dashboard affecting versions 2.2.7 through 2.2.10. A low-privilege user can cause a nil pointer dereference crash in the service-monitor worker by racing service report and delete operations on their own service. This crash kills the entire dashboard process, causing a denial of service affecting all tenants' web UI, REST API, and agent connections. The issue is fixed in version 2.2.11 and later.
Nezha Dashboard versions from 1.8.0 up to but not including 2.3.13 have an improper locking vulnerability. This flaw involves a non-deferred mutex unlock that leaks on a nil-map panic path. An authenticated non-admin user can exploit this by issuing four notification API calls, causing a permanent deadlock in the alerting subsystem and subsequently exhausting memory with blocking requests. The vulnerability has a CVSS 4.0 score of 7.1, indicating high severity.
Nezha versions from 1.8.0 up to but not including 2.3.13 contain a race condition due to a lock-order inversion in the UpdateGroup and DeleteGroup functions. This flaw allows authenticated non-admin users to cause a deadlock in the alerting subsystem by concurrently invoking notification-group and batch-delete endpoints with oversized ID lists. The deadlock can permanently disrupt alert delivery until the system is restarted.
Nezha 2.2.3 contains a Host header injection regression in the OAuth2 redirect endpoint. When the new optional dashboard_host setting is empty, /api/v1/oauth2/{provider} (cmd/dashboard/controller/oauth2.go) reflects the attacker-supplied HTTP Host header into the redirect_uri sent to the identity provider instead of falling back to the configured install_host. An attacker who induces a victim to begin OAuth2 login via a request that reaches Nezha with a forged Host header can cause an attacker-controlled callback URL to be used as the redirect_uri; if the OAuth2 provider accepts it, the victim's authorization code is delivered to the attacker origin, allowing the attacker to complete the OAuth2 login/binding flow and take over the account. This regresses the fix for GHSA-9rc6-8cjv-rcvx and is configuration-dependent (dashboard_host empty). At the time of the advisory no patched version was available.
Nezha before 2.2.7 contains an information disclosure vulnerability in the GET /api/v1/profile endpoint that returns the bcrypt-hashed password field of authenticated users. Attackers can extract password hashes and perform offline cracking attacks without rate limiting or audit trail constraints.
CVE-2026-101088 is a time-of-check time-of-use (TOCTOU) race condition vulnerability in the nezha monitoring tool versions >=2.2.11 and <2.3.1. An authenticated user with member role can trigger a concurrent server deletion to cause a panic in the sentinel worker, crashing the entire instance. This occurs because of an incomplete fix that reuses a stale pointer without proper re-validation under locking. The issue is fixed in version 2.3.1.
Nezha versions 2.0.10 through 2.3.2 contain a server-side request forgery (SSRF) vulnerability due to incomplete denylist coverage of IPv6 transition ranges in the HTTP client used for validating user-configurable webhook URLs. Authenticated users can exploit this to cause the dashboard to send requests to certain IPv6 endpoints that are normally restricted. The vulnerability is fixed in version 2.3.3 by blocking the problematic IPv6 prefixes.
Nezha Dashboard versions before 2.3.5 fail to restrict service monitor task types to supported probe types, allowing authenticated users with nezha:service:write scope to submit privileged task types through the service API. Attackers can deliver command execution or Agent configuration tasks to Agents within their authorization scope by exploiting the shared protobuf Task.Type namespace between service monitors and privileged operations.
Nezha before 2.3.8 fails to validate alert rule type and duration bounds, allowing authenticated non-administrator users to create malformed rules that trigger unrecovered panics in the alert evaluator goroutine. Attackers can submit a crafted alert rule via the POST /api/v1/alert-rule endpoint to crash the dashboard process, which persists the rule and causes repeated crashes on restart, disabling all monitoring and control plane functionality.
Nezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O&M tool. Nezha versions 1.14.13 through 1.14.14 and 2.0.0 through 2.0.9 do not bind stream identifiers created by CreateStream in service/rpc/io_stream.go to their creating user, and `GET /ws/terminal/:id` and `GET /ws/file/:id` only check whether the supplied UUID exists. An authenticated RoleMember who obtains a live stream UUID from logs, browser history, referer data, or telemetry can attach to another user's terminal or file-manager session, read and write target-server files, and execute shell commands. This issue is fixed in version 2.0.10.
Nezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O&M tool. Prior to 2.2.5, the GET /api/v1/ddns and GET /api/v1/notification endpoints return full resource objects including plaintext third-party API credentials, including Cloudflare API tokens, TencentCloud SecretKeys, Slack, Discord, and Telegram webhook URLs with embedded bot tokens, and Authorization header values, without any field-level redaction. Any authenticated admin or PAT with nezha:ddns:read or nezha:notification:read scope can receive stored credentials through the listDDNS and listNotification handlers in a single API response. This issue is fixed in version 2.2.5.
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 getRedirectURL function in oauth2.go:22-29 constructs the OAuth2 callback URL by concatenating the request's Host header with a fixed path, with zero validation of the Host header. This can result in host header injection. This issue has been patched in version 2.2.0.
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.
Nezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O&M tool. From version 2.0.14 to before version 2.1.0, PATCH /server/{id} accepts and persists nonexistent ddns_profiles IDs for a member-owned server. If another user later creates a DDNS profile with one of those IDs, the DDNS worker resolves the stored ID and dispatches an update using the other user's DDNS profile configuration in the context of the attacker's server. This issue has been patched in version 2.1.0.
Nezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O&M tool. From version 2.0.14 to before version 2.1.0, authenticated users can claim the dashboard Host through NAT and preempt all dashboard routing. This issue has been patched in version 2.1.0.