CVE-2026-62283 in Nezha
Summary
by MITRE • 08/21/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/21/2026
The vulnerability identified in Nezha Monitoring versions ranging from 1.14.13 through 1.14.14 and 2.0.0 through 2.0.9 represents a critical failure in session isolation and access control mechanisms within the application's remote stream handling logic. Nezha is designed as a self-hosted, lightweight monitoring and operations tool for servers and websites, relying heavily on real-time interactive sessions such as terminal shells and file managers to facilitate system administration tasks. The core technical flaw resides in the service/rpc/io_stream.go module, where the CreateStream function generates stream identifiers without binding them to the specific user account that initiated the request. This architectural oversight means that the generated Universally Unique Identifier (UUID) serves merely as a pointer to an active session rather than a cryptographically secured token tied to the creator's identity and permissions. Consequently, the authentication checks performed by the WebSocket endpoints GET /ws/terminal/:id and GET /ws/file/:id are insufficient, as they only verify the existence of the provided UUID in the system registry without validating whether the requesting user is the legitimate owner or has been explicitly authorized for that specific session.
This design deficiency allows an authenticated attacker with a low-privilege RoleMember account to escalate their access and compromise other users' sessions if they can obtain a valid stream identifier through side-channel information leakage. The vulnerability leverages common data exposure vectors such as browser history, HTTP referer headers containing previous URLs, or telemetry logs that may inadvertently record the full session IDs during normal administrative operations. Once an attacker acquires a live stream UUID belonging to another user with higher privileges, they can directly attach their client to that active terminal or file-manager session. This capability effectively bypasses all intended access controls, granting the attacker unauthorized read and write access to files on target servers as well as the ability to execute arbitrary shell commands within the context of the victim's session. The impact is severe, potentially leading to full system compromise, data exfiltration, lateral movement across the monitored infrastructure, and integrity violations depending on the privileges held by the targeted user account.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, specifically reflecting failures in authorization checks where access is granted based solely on resource identifiers rather than proper ownership verification. It also maps to ATT&CK technique T1078 Valid Accounts, as it exploits legitimate credentials combined with flawed session management logic to impersonate or hijack other users' activities. The lack of binding between the stream identifier and the user context violates fundamental principles of secure session handling where tokens must be cryptographically bound to the session owner's identity and authentication state. This ensures that even if a token is intercepted, it cannot be reused by an unauthorized party unless they also possess valid credentials for the target account or can bypass additional multi-factor checks not present in this implementation.
To mitigate this vulnerability, organizations running affected versions of Nezha Monitoring must immediately upgrade to version 2.0.10 or later, where the developers have implemented proper binding of stream identifiers to their creating users and enhanced validation logic at the WebSocket endpoints. In environments where immediate patching is not feasible due to operational constraints, administrators should implement strict network segmentation to limit access to monitoring interfaces and enforce robust logging and monitoring solutions that detect unusual patterns in session ID usage or unauthorized attachment attempts. Additionally, reviewing browser history policies and disabling telemetry features that expose sensitive identifiers can reduce the attack surface for information leakage vectors. Regular security audits of authentication flows and adherence to OWASP guidelines on session management are recommended to prevent similar access control failures in future deployments.