Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.9",
  "pubDate": "2026-08-21T21:17:01.183Z",
  "pubdate": "2026-08-21T21:17:01.183Z",
  "executiveSummary": "An insecure direct object reference and stream binding vulnerability exists in Nezha Monitoring, specifically within stream identifier handling in the remote procedure call and WebSocket routing logic.\nThe vulnerability allows an authenticated low-privileged user, such as a RoleMember, to hijack active terminal and file-manager sessions belonging to other users.\nAffected products include Nezha versions 1.14.13 through 1.14.14 and 2.0.0 through 2.0.9.\nThe risk implications are severe, as successful exploitation permits unauthorized cross-user session attachment, arbitrary file reading and writing on target servers, and remote code execution via interactive shell commands.\nAttacker capabilities require valid authentication as a RoleMember and the acquisition of a live stream UUID through information leakage vectors such as logs, browser history, referer data, or telemetry.\nThe issue is fully resolved in version 2.0.10 by binding stream identifiers to their creating users and enforcing strict authorization checks on WebSocket endpoints.",
  "technicalDetails": "The vulnerability resides in the core service logic of Nezha Monitoring, specifically within service/rpc/io_stream.go, where the CreateStream function fails to cryptographically or logically bind newly generated stream identifiers to the specific user context that initiated the creation request.\nConcurrently, the WebSocket routing endpoints, specifically GET /ws/terminal/:id and GET /ws/file/:id, suffer from insufficient access control validation. Instead of verifying session ownership and validating that the requesting user possesses administrative or matching permissions for the specific stream, the endpoints merely perform a simplistic existence check against the supplied UUID parameter.\nThe attack flow begins when an authenticated attacker with a low-privileged RoleMember role obtains a valid, active live stream UUID. This identifier can be leaked via multiple secondary sources including system logs, browser history, HTTP referer headers, or telemetry data.\nOnce the target UUID is acquired, the attacker crafts a WebSocket handshake request targeting either the terminal or file-manager endpoints using the harvested UUID. Because the application logic lacks proper user-to-stream binding validation and only checks if the UUID exists in memory, the server accepts the unauthorized connection and bridges the attacker into the active session.\nThis post-exploitation state grants the attacker full interactive capabilities over the hijacked session, allowing them to read and write arbitrary files on the target server and execute arbitrary shell commands within the context of the monitored host.\nNetwork exposure is constrained to the web interface and API routing layers, but the authentication requirement is minimal, as any active session with RoleMember privileges can trigger the flaw provided a valid stream UUID is harvested."
}