Nezha
Monthly
Cleartext third-party credentials are exposed to any authenticated principal holding DDNS read access in Nezha versions 2.2.5 through 2.3.14, because the GET /api/v1/ddns list handler returns DDNS webhook profiles without redacting the WebhookURL and WebhookRequestBody fields. An admin account or a Personal Access Token granted the nezha:ddns:read scope can retrieve tokens embedded directly in other users' webhook URLs (for example query strings such as ?token=...) or request bodies, which the vendor's fix specifically addresses for every user's profiles rather than only the requester's. Per the vendor-assigned CVSS 4.0 vector (7.1, PR:L, VC:H with no integrity or availability impact), the exposure is confidentiality-only and gated behind the authentication and scope prerequisite; no public exploit identified at time of analysis, and neither CISA KEV status nor public exploit code is reported for this issue.
Nezha monitoring dashboards running versions 1.0.0 through 2.3.14 can be knocked offline by an authenticated user who holds file-manager scope, because the dashboard's file manager WebSocket handler (fmStream) never imposes a read limit on incoming frames. A single oversized binary message sent to /api/v1/ws/file/:id is buffered whole by gorilla/websocket, exhausting process memory until the kernel OOM-killer terminates the dashboard - which in turn severs monitoring visibility for every agent the dashboard managed. There is no public exploit identified at time of analysis, but a vendor patch (2.3.15) and the upstream fixing commit are already public, so any dashboard exposed to users with file-manager permissions should be treated as a moderate-priority availability risk rather than a critical one; the attacked service is the dashboard itself, not the monitored endpoints.
Resource exhaustion in Nezha 2.0.13 through 2.3.14 allows an authenticated user to open unbounded concurrent connections to the /api/v1/ws/transfer WebSocket endpoint and hold thousands of ServerTransferClass.Subscribe subscriptions without limit, exhausting file descriptors, memory, and goroutines and blocking agent gRPC reconnections. Exploitation requires a valid authenticated dashboard session (CVSS vector includes PR:L), with no user interaction and no non-default configuration beyond a login-capable account; the impact is limited to availability of the dashboard and agent connectivity, and no public exploit has been identified at time of analysis. A vendor patch is available in Nezha 2.3.15 and later.
Permanent deadlock of the alerting subsystem in Nezha Dashboard 1.8.0 through 2.3.12 allows any authenticated non-admin member to disable monitoring notifications by issuing four crafted notification API calls, and continued blocking requests can then exhaust server memory. The flaw is an improper locking issue (CWE-667) in which a mutex is unlocked non-deferred on a nil-map panic path, leaving the lock permanently held. Exploitation requires a valid low-privilege account (the assessed CVSS:3.1 vector is AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), and no public exploit code was identified at time of analysis, so this represents a genuine but bounded availability risk rather than a critical priority.
Host header injection in Nezha 2.2.3's OAuth2 redirect endpoint (/api/v1/oauth2/{provider}) allows an unauthenticated remote attacker who can control the HTTP Host header on a request reaching the server to make Nezha emit an attacker-chosen redirect_uri to the configured identity provider; a victim induced to start the OAuth2 login/binding flow can then have their authorization code delivered to the attacker's origin, letting the attacker complete the flow and take over the account. The bug is a regression of the GHSA-9rc6-8cjv-rcvx fix and only manifests when the new optional dashboard_host setting is left empty, so the code no longer falls back to install_host; exploitation also requires victim interaction and an identity provider that accepts the forged redirect URI, which is why the independent assessment scores it CVSS:3.1/AV:N/AC:H/PR:N/UI:R while the vendor-style CVSS 4.0 rating is 9.3. No public exploit code has been identified at time of analysis and the issue is not in CISA KEV; no patched release version was published with the advisory, only an upstream fix commit (38824dbc11a63964c5b9296ae4c68e62b34fa04b).
Authenticated privilege escalation in Nezha Dashboard before 2.3.5 lets any account holding the nezha:service:write scope escalate into privileged Agent operations by creating or updating a service monitor whose Task.Type is set to a command or configuration task value, since the service API never validated that the submitted type belonged to the supported probe set. Because service monitors and privileged operations share the same protobuf Task.Type integer namespace, the crafted task is accepted and dispatched to Agents within the attacker's existing authorization scope, resulting in command execution or Agent reconfiguration (CWE-269). The independent assessment rates this as a genuine but authentication-gated privilege-escalation issue whose urgency is moderate and whose blast radius scales with how broadly service:write is delegated; the vendor has released a fix in 2.3.5 (commit 38824dbc11a63964c5b9296ae4c68e62b34fa04b) and no public exploit has been identified at time of analysis.
Denial of service in the Nezha monitoring dashboard before 2.3.8 lets any authenticated non-administrator account crash the dashboard process by submitting a malformed alert rule (invalid rule type or out-of-bounds duration) to POST /api/v1/alert-rule, which triggers an unrecovered panic in the alert evaluator goroutine. Because the offending rule is persisted, the dashboard enters a crash loop on every restart, taking down monitoring and the control plane until the bad record is manually removed from the backing datastore. No public exploit code was identified at time of analysis, exploitation requires only a low-privileged account (CVSS PR:L) and network reachability to the dashboard API, and impact is confined to availability with no confidentiality or integrity loss.
Cross-tenant session hijacking in Nezha Monitoring (v1.14.13-1.14.14 and v2.0.0-2.0.9) lets any authenticated low-privilege RoleMember attach to another user's live WebSocket terminal or file-manager session and gain interactive shell access and full file read/write on the monitored target server. The flaw stems from stream UUIDs at GET /ws/terminal/:id and GET /ws/file/:id being validated only for existence, never bound to their creating user, so an attacker who learns a live UUID from access logs, referer headers, browser history, or telemetry breadcrumbs achieves cross-tenant remote code execution. Fixed in v2.0.10; no public exploit identified at time of analysis, though the upstream commit and its regression tests fully disclose the mechanism.
Unauthenticated path traversal in Nezha Monitoring (nezhahq/nezha) before 2.0.13 allows remote attackers to read arbitrary files from the dashboard host by abusing the NoRoute fallbackToFrontend handler. The handler matches the /dashboard prefix with strings.HasPrefix rather than a path-segment comparison, so a request like /dashboard../data/config.yaml is normalized by path.Join into the application's data directory and served by http.ServeFile. No public exploit identified at time of analysis, but the bypass is trivially reproducible from the disclosed root-cause writeup.
An authenticated dashboard user in Nezha 2.0.0 through 2.3.x can cause a persistent denial of service against non-TSDB deployments by deleting a service through POST /api/v1/batch-delete/service, which leaves orphaned service_histories rows behind. On the dashboard's next startup, ServiceSentinel.loadTodayStats dereferences the missing per-service status map entries for those leftover rows and panics, and the crash repeats on every restart until an operator manually removes the orphaned history. The trigger is not immediate and depends on a restart occurring, and TSDB-backed configurations appear unaffected; no public exploit code was identified at time of analysis and the issue is not in CISA KEV. Vendor-released patch: 2.4.0.
Cross-tenant server ID enumeration in the Nezha monitoring dashboard (versions 1.7.0 through 2.3.14) lets an authenticated low-privilege member map other tenants' server IDs by sweeping sequential identifiers against the getServerConfig and setServerConfig endpoints and distinguishing 'permission denied' responses from success payloads. According to the authoritative assessment, exploitation requires a valid member account plus a shared, multi-tenant deployment where more than one user's servers coexist; on a single-tenant self-hosted install there are no other tenants to enumerate, sharply reducing real impact. It yields server-ID mapping rather than configuration contents, secrets, or control, and stays confined to a low-severity information-disclosure outcome (C:L, I:N, A:N). No public exploit code was identified at time of analysis, and this CVE is not in CISA KEV; vendor patch version 2.3.15 is available.
Host header injection in Nezha 2.1.0 through 2.3.14 lets an attacker who can control or spoof the Host header on a victim's MCP request redirect file uploads and capture one-time download tokens that can be replayed to exfiltrate files. The flaw is in mintTransferTool, which builds the fs.download_url and fs.upload_url transfer links from the unvalidated Host header, so the observable impact is limited to low confidentiality and integrity loss rather than code execution. Exploitation is unauthenticated per the CVSS vector (PR:N) but conditional on the attacker influencing the reflected Host value - for example through a misconfigured or trusting reverse proxy, DNS rebinding, or a man-in-the-middle position on the victim's path - and on the victim actually invoking the MCP transfer tools. No public exploit code or confirmed active exploitation was identified at time of analysis, and the vendor has shipped a fix in Nezha 2.3.15.
Denial of service in Nezha Monitoring 2.2.7 through 2.2.10 lets an authenticated RoleMember crash the whole dashboard process by racing their own agent's TCP/ICMP result report against deletion of a service the member owns, producing a nil pointer dereference in ServiceSentinel.worker that panics the process and takes down every tenant's web interface, REST API, and agent connections until the service is restarted. Confirmed actively exploited? No - no public exploit code or active exploitation has been identified at time of analysis, and the issue is availability-only (C:N/I:N/A:H) with no data disclosure or modification. The published CVSS of 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) matches the assessed impact, but independent analysis rates attack complexity as High (AC:H) because the attacker must win a concurrency window between the ownership check and the pointer dereference; that window is retriable, so practical reliability is higher than a one-shot race would suggest.
Authenticated non-admin users can deadlock the alerting subsystem in Nezha 1.8.0 through releases before 2.3.13 by racing the notification-group UpdateGroup/DeleteGroup operations against the batch-delete endpoint with oversized id lists, closing an ABBA lock-order inversion that halts alert delivery until the service is restarted. This is an availability-only race condition (CWE-362) that requires a valid low-privileged account and successful timing; independent assessment maps it to CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H and rates it a moderate-severity issue rather than a top-tier priority. No public exploit identified at time of analysis, and no code execution, data access, or integrity impact is assessed.
Information disclosure in Nezha before version 2.2.7 allows any authenticated user to retrieve their own bcrypt-hashed password by requesting the GET /api/v1/profile endpoint. While the exposure of password hashes is a security weakness, bcrypt is a deliberately slow, salted hashing algorithm, so offline cracking is only feasible for weak or reused passwords; this makes the issue low-risk. No public exploit code is known, and the vulnerability is not confirmed as actively exploited. The independent assessment rates this as a genuinely low-priority issue (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N), emphasizing that the disclosed hashes are resistant to cracking for strong passwords.
Denial of service in Nezha, the server and website monitoring tool, affects versions 2.2.11 through 2.3.0, where an authenticated user holding the member role and owning at least one agent can crash the entire instance. The attacker issues a concurrent server-delete request (POST /api/v1/batch-delete/server) against their own server to win a narrow TOCTOU race inside the sentinel worker, which then dereferences a missing entry in its server-list snapshot; because the sentinel workers and the gRPC server lack any recover()/recovery interceptor, the resulting panic is unrecovered and brings down the whole process. This is an availability-only flaw (no confidentiality or integrity impact) rated 6.0 under CVSS 4.0 and 5.9 (AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H) in our independent assessment, with no public exploit code identified at time of analysis and a fix available in 2.3.1.
Authenticated users of the Nezha monitoring dashboard (versions 2.0.10 through 2.3.2) who can configure notification or DDNS webhook URLs can bypass the dashboard's SSRF denylist by supplying an IPv6 literal in the 6to4 prefix 2002::/16 or the local-use NAT64 prefix 64:ff9b:1::/48, causing the server to issue outbound HTTP requests to those endpoints. Exploitation is heavily constrained: the CVSS vector is PR:L, meaning an attacker must already hold a webhook-configuring account, and meaningful impact depends on the deployment's network providing unusual or non-standards-compliant routing for these transition ranges; the advisory confirms no path to IPv4 metadata, loopback, or private-network requests was demonstrated. No public exploit code has been identified at time of analysis and the issue is not known to be exploited, but the vendor has shipped a fix in version 2.3.3 (commit d1fcde8e) that explicitly blocks both prefixes. The independent assessment rates this as a low-priority, high-caveat SSRF with AC:H and only low confidentiality impact.
Nezha Monitoring versions prior to 2.2.5 expose stored third-party API credentials in plaintext through two listing API endpoints to any authenticated admin or PAT holder with read-scoped access. The GET /api/v1/ddns and GET /api/v1/notification handlers serialize full database objects - including Cloudflare API tokens, TencentCloud SecretKeys, and Slack, Discord, and Telegram webhook URLs with embedded bot tokens - without any field-level redaction, enabling a single API call to harvest all configured credentials. No public exploit has been identified at time of analysis, and a vendor-released patch is available in v2.2.5.
Host header injection in Nezha Monitoring versions 1.0.0 through 2.2.0 allows unauthenticated remote attackers to redirect OAuth2 callback URLs to attacker-controlled domains, enabling OAuth token theft and account takeover. The flaw resides in the getRedirectURL function (oauth2.go:22-29), which blindly concatenates the HTTP request's Host header with a fixed path when constructing the OAuth2 redirect URL, with no allowlisting or validation performed. A vendor-released patch exists in version 2.2.0; no public exploit has been identified at time of analysis and the vulnerability is not in the CISA KEV catalog.
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.
Incorrect authorization in Nezha Monitoring's DDNS profile subsystem allows an authenticated low-privilege member to pre-populate their server record with nonexistent DDNS profile IDs, then hijack any future victim-owned DDNS profile whose auto-assigned ID collides with a pre-stored value. Affected versions span 2.0.14 through pre-2.1.0 of the self-hosted nezhahq/nezha platform. When the collision occurs, the DDNS worker dispatches DNS updates on behalf of the attacker's server using the victim's DDNS provider credentials and configuration, achieving cross-tenant DNS manipulation and disrupting the victim's legitimate DDNS service. No public exploit identified at time of analysis; vendor-released patch available in version 2.1.0.
Nezha Monitoring versions 2.0.14 through 2.1.0 (exclusive) allows any authenticated user to exploit the NAT-based Host claiming mechanism to preempt all dashboard routing, resulting in complete availability loss for the monitoring platform. The vulnerability stems from CWE-284 (Improper Access Control) - the application fails to properly restrict which authenticated principals may register or override a dashboard Host identity via NAT traversal. No public exploit has been identified at time of analysis, and this vulnerability is not listed in the CISA KEV catalog.
Cleartext third-party credentials are exposed to any authenticated principal holding DDNS read access in Nezha versions 2.2.5 through 2.3.14, because the GET /api/v1/ddns list handler returns DDNS webhook profiles without redacting the WebhookURL and WebhookRequestBody fields. An admin account or a Personal Access Token granted the nezha:ddns:read scope can retrieve tokens embedded directly in other users' webhook URLs (for example query strings such as ?token=...) or request bodies, which the vendor's fix specifically addresses for every user's profiles rather than only the requester's. Per the vendor-assigned CVSS 4.0 vector (7.1, PR:L, VC:H with no integrity or availability impact), the exposure is confidentiality-only and gated behind the authentication and scope prerequisite; no public exploit identified at time of analysis, and neither CISA KEV status nor public exploit code is reported for this issue.
Nezha monitoring dashboards running versions 1.0.0 through 2.3.14 can be knocked offline by an authenticated user who holds file-manager scope, because the dashboard's file manager WebSocket handler (fmStream) never imposes a read limit on incoming frames. A single oversized binary message sent to /api/v1/ws/file/:id is buffered whole by gorilla/websocket, exhausting process memory until the kernel OOM-killer terminates the dashboard - which in turn severs monitoring visibility for every agent the dashboard managed. There is no public exploit identified at time of analysis, but a vendor patch (2.3.15) and the upstream fixing commit are already public, so any dashboard exposed to users with file-manager permissions should be treated as a moderate-priority availability risk rather than a critical one; the attacked service is the dashboard itself, not the monitored endpoints.
Resource exhaustion in Nezha 2.0.13 through 2.3.14 allows an authenticated user to open unbounded concurrent connections to the /api/v1/ws/transfer WebSocket endpoint and hold thousands of ServerTransferClass.Subscribe subscriptions without limit, exhausting file descriptors, memory, and goroutines and blocking agent gRPC reconnections. Exploitation requires a valid authenticated dashboard session (CVSS vector includes PR:L), with no user interaction and no non-default configuration beyond a login-capable account; the impact is limited to availability of the dashboard and agent connectivity, and no public exploit has been identified at time of analysis. A vendor patch is available in Nezha 2.3.15 and later.
Permanent deadlock of the alerting subsystem in Nezha Dashboard 1.8.0 through 2.3.12 allows any authenticated non-admin member to disable monitoring notifications by issuing four crafted notification API calls, and continued blocking requests can then exhaust server memory. The flaw is an improper locking issue (CWE-667) in which a mutex is unlocked non-deferred on a nil-map panic path, leaving the lock permanently held. Exploitation requires a valid low-privilege account (the assessed CVSS:3.1 vector is AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), and no public exploit code was identified at time of analysis, so this represents a genuine but bounded availability risk rather than a critical priority.
Host header injection in Nezha 2.2.3's OAuth2 redirect endpoint (/api/v1/oauth2/{provider}) allows an unauthenticated remote attacker who can control the HTTP Host header on a request reaching the server to make Nezha emit an attacker-chosen redirect_uri to the configured identity provider; a victim induced to start the OAuth2 login/binding flow can then have their authorization code delivered to the attacker's origin, letting the attacker complete the flow and take over the account. The bug is a regression of the GHSA-9rc6-8cjv-rcvx fix and only manifests when the new optional dashboard_host setting is left empty, so the code no longer falls back to install_host; exploitation also requires victim interaction and an identity provider that accepts the forged redirect URI, which is why the independent assessment scores it CVSS:3.1/AV:N/AC:H/PR:N/UI:R while the vendor-style CVSS 4.0 rating is 9.3. No public exploit code has been identified at time of analysis and the issue is not in CISA KEV; no patched release version was published with the advisory, only an upstream fix commit (38824dbc11a63964c5b9296ae4c68e62b34fa04b).
Authenticated privilege escalation in Nezha Dashboard before 2.3.5 lets any account holding the nezha:service:write scope escalate into privileged Agent operations by creating or updating a service monitor whose Task.Type is set to a command or configuration task value, since the service API never validated that the submitted type belonged to the supported probe set. Because service monitors and privileged operations share the same protobuf Task.Type integer namespace, the crafted task is accepted and dispatched to Agents within the attacker's existing authorization scope, resulting in command execution or Agent reconfiguration (CWE-269). The independent assessment rates this as a genuine but authentication-gated privilege-escalation issue whose urgency is moderate and whose blast radius scales with how broadly service:write is delegated; the vendor has released a fix in 2.3.5 (commit 38824dbc11a63964c5b9296ae4c68e62b34fa04b) and no public exploit has been identified at time of analysis.
Denial of service in the Nezha monitoring dashboard before 2.3.8 lets any authenticated non-administrator account crash the dashboard process by submitting a malformed alert rule (invalid rule type or out-of-bounds duration) to POST /api/v1/alert-rule, which triggers an unrecovered panic in the alert evaluator goroutine. Because the offending rule is persisted, the dashboard enters a crash loop on every restart, taking down monitoring and the control plane until the bad record is manually removed from the backing datastore. No public exploit code was identified at time of analysis, exploitation requires only a low-privileged account (CVSS PR:L) and network reachability to the dashboard API, and impact is confined to availability with no confidentiality or integrity loss.
Cross-tenant session hijacking in Nezha Monitoring (v1.14.13-1.14.14 and v2.0.0-2.0.9) lets any authenticated low-privilege RoleMember attach to another user's live WebSocket terminal or file-manager session and gain interactive shell access and full file read/write on the monitored target server. The flaw stems from stream UUIDs at GET /ws/terminal/:id and GET /ws/file/:id being validated only for existence, never bound to their creating user, so an attacker who learns a live UUID from access logs, referer headers, browser history, or telemetry breadcrumbs achieves cross-tenant remote code execution. Fixed in v2.0.10; no public exploit identified at time of analysis, though the upstream commit and its regression tests fully disclose the mechanism.
Unauthenticated path traversal in Nezha Monitoring (nezhahq/nezha) before 2.0.13 allows remote attackers to read arbitrary files from the dashboard host by abusing the NoRoute fallbackToFrontend handler. The handler matches the /dashboard prefix with strings.HasPrefix rather than a path-segment comparison, so a request like /dashboard../data/config.yaml is normalized by path.Join into the application's data directory and served by http.ServeFile. No public exploit identified at time of analysis, but the bypass is trivially reproducible from the disclosed root-cause writeup.
An authenticated dashboard user in Nezha 2.0.0 through 2.3.x can cause a persistent denial of service against non-TSDB deployments by deleting a service through POST /api/v1/batch-delete/service, which leaves orphaned service_histories rows behind. On the dashboard's next startup, ServiceSentinel.loadTodayStats dereferences the missing per-service status map entries for those leftover rows and panics, and the crash repeats on every restart until an operator manually removes the orphaned history. The trigger is not immediate and depends on a restart occurring, and TSDB-backed configurations appear unaffected; no public exploit code was identified at time of analysis and the issue is not in CISA KEV. Vendor-released patch: 2.4.0.
Cross-tenant server ID enumeration in the Nezha monitoring dashboard (versions 1.7.0 through 2.3.14) lets an authenticated low-privilege member map other tenants' server IDs by sweeping sequential identifiers against the getServerConfig and setServerConfig endpoints and distinguishing 'permission denied' responses from success payloads. According to the authoritative assessment, exploitation requires a valid member account plus a shared, multi-tenant deployment where more than one user's servers coexist; on a single-tenant self-hosted install there are no other tenants to enumerate, sharply reducing real impact. It yields server-ID mapping rather than configuration contents, secrets, or control, and stays confined to a low-severity information-disclosure outcome (C:L, I:N, A:N). No public exploit code was identified at time of analysis, and this CVE is not in CISA KEV; vendor patch version 2.3.15 is available.
Host header injection in Nezha 2.1.0 through 2.3.14 lets an attacker who can control or spoof the Host header on a victim's MCP request redirect file uploads and capture one-time download tokens that can be replayed to exfiltrate files. The flaw is in mintTransferTool, which builds the fs.download_url and fs.upload_url transfer links from the unvalidated Host header, so the observable impact is limited to low confidentiality and integrity loss rather than code execution. Exploitation is unauthenticated per the CVSS vector (PR:N) but conditional on the attacker influencing the reflected Host value - for example through a misconfigured or trusting reverse proxy, DNS rebinding, or a man-in-the-middle position on the victim's path - and on the victim actually invoking the MCP transfer tools. No public exploit code or confirmed active exploitation was identified at time of analysis, and the vendor has shipped a fix in Nezha 2.3.15.
Denial of service in Nezha Monitoring 2.2.7 through 2.2.10 lets an authenticated RoleMember crash the whole dashboard process by racing their own agent's TCP/ICMP result report against deletion of a service the member owns, producing a nil pointer dereference in ServiceSentinel.worker that panics the process and takes down every tenant's web interface, REST API, and agent connections until the service is restarted. Confirmed actively exploited? No - no public exploit code or active exploitation has been identified at time of analysis, and the issue is availability-only (C:N/I:N/A:H) with no data disclosure or modification. The published CVSS of 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) matches the assessed impact, but independent analysis rates attack complexity as High (AC:H) because the attacker must win a concurrency window between the ownership check and the pointer dereference; that window is retriable, so practical reliability is higher than a one-shot race would suggest.
Authenticated non-admin users can deadlock the alerting subsystem in Nezha 1.8.0 through releases before 2.3.13 by racing the notification-group UpdateGroup/DeleteGroup operations against the batch-delete endpoint with oversized id lists, closing an ABBA lock-order inversion that halts alert delivery until the service is restarted. This is an availability-only race condition (CWE-362) that requires a valid low-privileged account and successful timing; independent assessment maps it to CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H and rates it a moderate-severity issue rather than a top-tier priority. No public exploit identified at time of analysis, and no code execution, data access, or integrity impact is assessed.
Information disclosure in Nezha before version 2.2.7 allows any authenticated user to retrieve their own bcrypt-hashed password by requesting the GET /api/v1/profile endpoint. While the exposure of password hashes is a security weakness, bcrypt is a deliberately slow, salted hashing algorithm, so offline cracking is only feasible for weak or reused passwords; this makes the issue low-risk. No public exploit code is known, and the vulnerability is not confirmed as actively exploited. The independent assessment rates this as a genuinely low-priority issue (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N), emphasizing that the disclosed hashes are resistant to cracking for strong passwords.
Denial of service in Nezha, the server and website monitoring tool, affects versions 2.2.11 through 2.3.0, where an authenticated user holding the member role and owning at least one agent can crash the entire instance. The attacker issues a concurrent server-delete request (POST /api/v1/batch-delete/server) against their own server to win a narrow TOCTOU race inside the sentinel worker, which then dereferences a missing entry in its server-list snapshot; because the sentinel workers and the gRPC server lack any recover()/recovery interceptor, the resulting panic is unrecovered and brings down the whole process. This is an availability-only flaw (no confidentiality or integrity impact) rated 6.0 under CVSS 4.0 and 5.9 (AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H) in our independent assessment, with no public exploit code identified at time of analysis and a fix available in 2.3.1.
Authenticated users of the Nezha monitoring dashboard (versions 2.0.10 through 2.3.2) who can configure notification or DDNS webhook URLs can bypass the dashboard's SSRF denylist by supplying an IPv6 literal in the 6to4 prefix 2002::/16 or the local-use NAT64 prefix 64:ff9b:1::/48, causing the server to issue outbound HTTP requests to those endpoints. Exploitation is heavily constrained: the CVSS vector is PR:L, meaning an attacker must already hold a webhook-configuring account, and meaningful impact depends on the deployment's network providing unusual or non-standards-compliant routing for these transition ranges; the advisory confirms no path to IPv4 metadata, loopback, or private-network requests was demonstrated. No public exploit code has been identified at time of analysis and the issue is not known to be exploited, but the vendor has shipped a fix in version 2.3.3 (commit d1fcde8e) that explicitly blocks both prefixes. The independent assessment rates this as a low-priority, high-caveat SSRF with AC:H and only low confidentiality impact.
Nezha Monitoring versions prior to 2.2.5 expose stored third-party API credentials in plaintext through two listing API endpoints to any authenticated admin or PAT holder with read-scoped access. The GET /api/v1/ddns and GET /api/v1/notification handlers serialize full database objects - including Cloudflare API tokens, TencentCloud SecretKeys, and Slack, Discord, and Telegram webhook URLs with embedded bot tokens - without any field-level redaction, enabling a single API call to harvest all configured credentials. No public exploit has been identified at time of analysis, and a vendor-released patch is available in v2.2.5.
Host header injection in Nezha Monitoring versions 1.0.0 through 2.2.0 allows unauthenticated remote attackers to redirect OAuth2 callback URLs to attacker-controlled domains, enabling OAuth token theft and account takeover. The flaw resides in the getRedirectURL function (oauth2.go:22-29), which blindly concatenates the HTTP request's Host header with a fixed path when constructing the OAuth2 redirect URL, with no allowlisting or validation performed. A vendor-released patch exists in version 2.2.0; no public exploit has been identified at time of analysis and the vulnerability is not in the CISA KEV catalog.
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.
Incorrect authorization in Nezha Monitoring's DDNS profile subsystem allows an authenticated low-privilege member to pre-populate their server record with nonexistent DDNS profile IDs, then hijack any future victim-owned DDNS profile whose auto-assigned ID collides with a pre-stored value. Affected versions span 2.0.14 through pre-2.1.0 of the self-hosted nezhahq/nezha platform. When the collision occurs, the DDNS worker dispatches DNS updates on behalf of the attacker's server using the victim's DDNS provider credentials and configuration, achieving cross-tenant DNS manipulation and disrupting the victim's legitimate DDNS service. No public exploit identified at time of analysis; vendor-released patch available in version 2.1.0.
Nezha Monitoring versions 2.0.14 through 2.1.0 (exclusive) allows any authenticated user to exploit the NAT-based Host claiming mechanism to preempt all dashboard routing, resulting in complete availability loss for the monitoring platform. The vulnerability stems from CWE-284 (Improper Access Control) - the application fails to properly restrict which authenticated principals may register or override a dashboard Host identity via NAT traversal. No public exploit has been identified at time of analysis, and this vulnerability is not listed in the CISA KEV catalog.