Nezha Monitoring vulnerabilities

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 prior to version 2.0.13 has a vulnerability in the NoRoute handler in the dashboard that allows access to admin assets without authentication. By exploiting an incorrect URL prefix check, an attacker can access system files.

Nezha Monitoring versions from 1.4.0 to before 2.0.8 allow RoleMember users to create scheduled cron tasks that can execute arbitrary commands on servers, including those belonging to other users. This poses a risk of unauthorized access to systems.

Nezha Monitoring before version 2.2.5 returns full resource objects in API responses for /api/v1/ddns and /api/v1/notification, including plaintext third-party API credentials such as Cloudflare API tokens, TencentCloud SecretKeys, Slack, Discord, and Telegram webhook URLs with embedded bot tokens, and Authorization header values. Any authenticated admin or PAT with nezha:ddns:read or nezha:notification:read scope can retrieve stored credentials via the listDDNS and listNotification handlers in a single API response.

Nezha Monitoring versions from 1.0.0 to before 2.2.0 have a vulnerability in the getRedirectURL function that constructs the OAuth2 callback URL without validating the Host header. This can lead to host header injection.

Nezha Monitoring versions from 1.0.0 to before 2.2.0 have a vulnerability that allows the creation of long-lived WebSocket streams without limits. Two endpoints, POST /api/v1/terminal and POST /api/v1/file, lack user rate limits and server connection caps.

Nezha Monitoring versions from 2.0.14 to before 2.1.0 allows accepting and persisting nonexistent ddns_profiles IDs for a member-owned server. If another user later creates a DDNS profile with one of those IDs, it can lead to the use of the other user's DDNS profile configuration in the context of the attacker's server.

Nezha Monitoring is a tool for monitoring servers and websites. In versions from 2.0.14 to before 2.1.0, authenticated users can claim the dashboard Host through NAT, allowing them to preempt all dashboard routing.

Nezha Monitoring is a tool for monitoring servers and websites. In versions from 2.0.0 to before 2.0.14, private services were enumerable via per-server endpoints, leaking name and timing data.

Nezha Monitoring is a tool for monitoring servers and websites. In versions from 1.0.0 to before 2.0.14, a malicious cross-site GET request can trigger stored cron commands on a victim's agents. This issue has been patched in version 2.0.14.

Nezha Monitoring is a tool for monitoring servers and websites. In versions from 0.20.0 to before 2.0.12, authenticated agents can forge service-monitor results for other users' services. This issue has been patched in version 2.0.12.

Nezha Monitoring before version 2.0.10 allows authenticated users to create or update a DDNS profile with any webhook_url, leading to an SSRF vulnerability. Low-privileged users can send HTTP requests to internal network services.

Nezha Monitoring versions from 1.4.0 to before 2.0.9 allow authenticated non-admin users to access the server-status WebSocket and receive telemetry data for all servers, including those owned by other users.

Nezha Monitoring versions from 1.4.0 to before 2.0.8 allow RoleMember to trigger other users' cron tasks without ownership checks. This issue has been patched in version 2.0.8.

Nezha Monitoring is a tool for monitoring servers and websites, which in versions from 1.4.0 to before 2.0.8 allows users with the RoleMember role to make unauthorized HTTP requests. As a result, users can send requests to URLs they control and receive responses, creating a risk of data exposure.