Nezhahq Nezha vulnerabilities

29 vulnerabilities

Known vulnerabilities in Nezhahq Nezha, newest first, with CVSS severity, EPSS, KEV listings, ransomware use and the affected versions.

7.1HighCVE-2026-111387nezhahq · nezhaNezha 2.2.5 before 2.3.15 Information Disclosure via DDNS List EndpointNezha from 2.2.5 before 2.3.15 contains an information disclosure vulnerability that allows authenticated users to retrieve third-party credentials because listDDNS omits WebhookURL and WebhookRequestBody redaction. Admins or PATs with nezha:ddns:read scope can call GET /api/v1/ddns to read cleartext tokens embedded in every user's DDNS webhook profiles.EPSS0.26%5.3MediumCVE-2026-111386nezhahq · nezhaNezha 1.7.0 before 2.3.15 Cross-Tenant Server-ID Enumeration via getServerConfigNezha 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.EPSS0.21%6.3MediumCVE-2026-111385nezhahq · nezhaNezha 2.1.0 before 2.3.15 Host Header Injection via MCP Transfer ToolsNezha from 2.1.0 before 2.3.15 contains a host header injection vulnerability in mintTransferTool that builds fs.download_url and fs.upload_url transfer URLs from the unvalidated Host header. Attackers who control the Host header seen on a victim's MCP request can redirect file uploads or capture one-time download tokens and replay them to exfiltrate files.EPSS0.19%7.1HighCVE-2026-111384nezhahq · nezhaNezha 1.0.0 before 2.3.15 Memory Exhaustion via File Manager WebSocketNezha 1.0.0 before 2.3.15 contains a memory exhaustion vulnerability in the dashboard file manager WebSocket endpoint because fmStream never calls SetReadLimit, leaving message size unbounded. Authenticated users with file manager scopes can send one oversized binary message to /api/v1/ws/file/:id, triggering an OOM kill that drops all agent monitoring.EPSS0.29%7.1HighCVE-2026-111383nezhahq · nezhaNezha 2.0.13 before 2.3.15 Denial of Service via /api/v1/ws/transfer WebSocketNezha from 2.0.13 before 2.3.15 contains a resource exhaustion vulnerability that allows authenticated users to open unbounded concurrent connections to the /api/v1/ws/transfer WebSocket endpoint. Attackers can hold thousands of subscriptions created by ServerTransferClass.Subscribe without limits, exhausting file descriptors, memory, and goroutines and blocking agent gRPC reconnections.EPSS0.29%6.5MediumCVE-2026-100394Gogithub.com/nezhahq · nezha +1 moreNezha Monitoring: Whole-instance DoS in Nezha dashboard: a member can crash the process for every tenantNezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O&M tool. From 2.2.7 until 2.2.11, ServiceSentinel.worker in service/singleton/servicesentinel.go checked an owned service under servicesLock and later dereferenced pointer-valued serviceStatusToday and serviceCurrentStatusData entries under serviceResponseDataStoreLock without revalidating that ServiceSentinel.Delete had not removed them. A RoleMember could concurrently report TCP or ICMP results through the member's own agent and delete the same owned service, causing a nil pointer dereference. Because the gRPC server had no recovery interceptor, the worker panic terminated the whole dashboard process and disrupted every tenant's web interface, REST API, and agent connections. The issue affects availability only and does not disclose or modify data. This issue is fixed in versions 2.2.11 and 2.3.0.EPSS0.42%6MediumCVE-2026-105112nezhahq · nezhaNezha 1.8.0 before 2.3.13 Deadlock DoS via notification-group endpointsNezha from 1.8.0 before 2.3.13 contains a lock-order inversion in UpdateGroup and DeleteGroup that allows authenticated non-admin users to deadlock the alerting subsystem. Attackers can concurrently call the notification-group and batch-delete endpoints with oversized id lists to widen the race and close an ABBA cycle, permanently killing alert delivery until restart.EPSS0.18%7.1HighCVE-2026-105113nezhahq · nezhaNezha 1.8.0 before 2.3.13 Denial of Service via Notification Mutex DeadlockNezha Dashboard from 1.8.0 before 2.3.13 contains an improper locking vulnerability where a non-deferred mutex unlock leaks on a nil-map panic path. Any authenticated non-admin member can issue four notification API calls to permanently deadlock the alerting subsystem, then exhaust memory with blocking requests.EPSS0.20%6.9MediumCVE-2026-59155Gogithub.com/nezhahq · nezha +1 moreNezha Monitoring: DDNS and Notification credential exposure via unredacted list APINezha 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.EPSS0.48%6MediumCVE-2026-101088nezhahq · nezhaNezha before 2.3.1 Denial of Service via Concurrent Server DeleteNezha is a server and website monitoring tool. In versions >= 2.2.11 and < 2.3.1, the service sentinel worker (service/singleton/servicesentinel.go) contains an incomplete fix for a previously reported nil dereference denial of service (GHSA-qjpp-gffx-2wm9). The 2026-07-21 fix re-validated the service lifecycle under serviceResponseDataStoreLock but reused an already-captured, now stale reporter pointer and never re-validated the server, and that lock does not guard ServerShared. An authenticated user with the member role who owns an agent can issue a concurrent server delete (POST /api/v1/batch-delete/server) for their own server to win the race window, causing the worker to dereference a missing entry in the server list snapshot. Because the sentinel workers and the gRPC server have no recover()/recovery interceptor, the resulting panic is unrecovered and crashes the entire instance. This is fixed in version 2.3.1.EPSS0.18%9.8CriticalCVE-2026-101090Gogithub.com/nezhahq · nezha +1 moreNezha through 2.2.3 Host Header Injection via OAuth2 redirect_uriNezha 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.EPSS0.36%3.1LowCVE-2026-101089nezhahq · nezhaNezha before 2.2.7 Information Disclosure via /api/v1/profileNezha 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.EPSS0.15%5.3MediumCVE-2026-101087nezhahq · nezhaNezha 2.0.10 through 2.3.2 SSRF Denylist Bypass IPv6Nezha versions 2.0.10 through 2.3.2 use a restricted HTTP client to validate user-configurable notification and DDNS webhook URLs, but the denylist did not cover IPv6 transition ranges — specifically the 6to4 prefix 2002::/16 and the local-use IPv4/IPv6 translation prefix 64:ff9b:1::/48. Because such addresses satisfy Go's netip.Addr.IsGlobalUnicast check, the URL validator accepted them. An authenticated user able to configure a webhook may be able to cause the dashboard to issue requests to an otherwise restricted IPv6 endpoint, but only where the dashboard's network provides unusual or non-standards-compliant routing for these transition ranges; no direct path to an IPv4 metadata, loopback, or private-network HTTP request has been demonstrated. The issue is fixed in version 2.3.3 (commit d1fcde8e), which blocks both prefixes.EPSS0.26%7.1HighCVE-2026-101086nezhahq · nezhaNezha Dashboard before 2.3.5 Task Type Validation BypassNezha 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.EPSS0.32%7.1HighCVE-2026-101085nezhahq · nezhaNezha before 2.3.8 Denial of Service via Alert RuleNezha 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.EPSS0.25%9.9CriticalCVE-2026-62283Gogithub.com/nezhahq · nezha +1 moreNezha Monitoring: Cross-tenant terminal/file-manager session hijack via WebSocket stream UUID without ownership checkNezha 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.EPSS0.55%7.1HighCVE-2026-47120Gogithub.com/nezhahq · nezha +1 moreNezha Monitoring: RoleMember can fire other users' cron tasks via AlertRule.FailTriggerTasks (no ownership check)Nezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O&M tool. From version 1.4.0 to before version 2.0.8, a RoleMember can fire other users' cron tasks via AlertRule.FailTriggerTasks (no ownership check). This issue has been patched in version 2.0.8.EPSS0.37%6.5MediumCVE-2026-47124Gogithub.com/nezhahq · nezha +1 moreNezha WebSocket server stream discloses cross-tenant server telemetry to authenticated membersNezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O&M tool. From version 1.4.0 to before version 2.0.9, any authenticated non-admin member can connect to the server-status WebSocket and receive telemetry for all servers, including servers owned by other users. The normal server list API filters objects by HasPermission, but the WebSocket stream treats the presence of any authenticated user as authorization for the full unfiltered server list. This issue has been patched in version 2.0.9.EPSS0.37%6.4MediumCVE-2026-47268Gogithub.com/naiba · nezha +2 moreNezha Monitoring: Authenticated DDNS webhook configuration allows blind SSRF from the dashboard hostNezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O&M tool. From version 0.20.0 to before version 2.0.10, an authenticated Nezha dashboard user can create or update a DDNS profile with provider webhook and configure an arbitrary webhook_url, HTTP method, request body, and headers. When DDNS is triggered for a server that uses that profile, the dashboard process sends the configured request with utils.HttpClient without the SSRF protections used by notification webhooks. This allows a low-privileged authenticated user who controls an owned server/DDNS profile to make the dashboard host issue HTTP requests to loopback or internal network services. The response body is not returned to the attacker in the confirmed path, so this is a blind SSRF / internal state-changing request primitive. This issue has been patched in version 2.0.10.EPSS0.25%7.1HighCVE-2026-48119Gogithub.com/naiba · nezha +2 moreNezha Monitoring: Authenticated agents can forge service-monitor results for other users' servicesNezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O&M tool. From version 0.20.0 to before version 2.0.12, authenticated agents can forge service-monitor results for other users' services. This issue has been patched in version 2.0.12.EPSS0.37%