CVE-2026-47124: Nezha Monitoring Authorization Bypass in WebSocket Telemetry Access

Technical summary

The vulnerability stems from an authorization control bypass in Nezha Monitoring's WebSocket implementation for server telemetry streaming. The server-status WebSocket endpoint uses a simple presence-of-authentication check rather than applying the same permission-based filtering (HasPermission) enforced by the standard server list API. An authenticated non-admin user can establish a WebSocket connection and receive unfiltered telemetry for all servers, including those belonging to other organizations or users. This represents a case of inconsistent access control logic between REST and WebSocket interfaces, allowing privilege escalation without requiring admin credentials or network access beyond standard authentication.

Business impact

Exposure of real-time infrastructure telemetry across tenant boundaries can reveal operational patterns, performance baselines, and resource utilization of other users' systems. In multi-tenant deployments, this enables competitive intelligence gathering or reconnaissance for further attacks. For security-conscious organizations, unauthorized visibility into monitoring data may trigger compliance violations (HIPAA, PCI-DSS, SOC 2) if customer or payment infrastructure metrics are exposed. The ease of exploitation—requiring only valid login credentials—increases the likelihood of misuse by disgruntled employees or compromised user accounts. Organizations relying on Nezha for critical infrastructure monitoring should treat this as a data confidentiality incident requiring urgent patching.

Affected systems

Nezha Monitoring versions 1.4.0 through 2.0.8 are affected. Version 2.0.9 and later contain the fix. Self-hosted deployments are most at risk, particularly those hosting multiple tenants or providing monitoring-as-a-service. Environments where non-admin user accounts have been provisioned for specific teams or customers are at heightened risk of unintended data exposure.

Exploitability

Exploitability is moderate to high. An attacker requires valid login credentials—a low bar in environments with many users or where credentials have been compromised. No special network positioning, complex exploitation steps, or user interaction is needed. The attack is deterministic: connect to the WebSocket endpoint, authenticate, and receive the full unfiltered stream. No active exploitation has been reported in the wild (KEV status not met), but the simplicity and directness of the attack vector make it attractive to low-skill attackers or insider threats.

Remediation

Upgrade to Nezha Monitoring version 2.0.9 or later immediately. This version implements proper permission-based filtering on the WebSocket stream, mirroring the authorization logic of the standard API. Before patching, organizations should audit WebSocket connection logs (if available) to detect unauthorized access to telemetry, and consider restricting non-admin account creation or limiting which users can connect to monitoring systems. Verify the patch version against the official Nezha project releases to ensure authenticity.

Patch guidance

Upgrade to version 2.0.9 or later. Follow the project's official upgrade documentation to ensure configuration continuity. If you are running a version prior to 1.4.0, you are not affected by this specific vulnerability. Organizations operating airgapped or highly controlled environments should test the upgrade in a staging environment first, then deploy during a maintenance window. Confirm post-upgrade that non-admin users no longer receive unfiltered server telemetry via WebSocket connections.

Detection guidance

Monitor WebSocket connections to the server-status endpoint for patterns inconsistent with expected user behavior: non-admin users opening WebSocket streams, frequency of connections per user, and volume of telemetry data consumed per session. Review authentication logs for successful logins from unexpected locations or times that might correlate with WebSocket access. If audit logging is available in your Nezha instance, examine WebSocket authorization decisions and compare them to API-level access control decisions. Hunt for discrepancies where a user accessed server data via WebSocket that should have been restricted by API policy. Network-level detection is challenging without protocol analysis, but monitoring for sustained WebSocket connections from non-admin user IPs to the monitoring server can yield leads.

Why prioritize this

CVSS 6.5 (Medium) reflects high confidentiality impact but no integrity or availability loss. However, this warrants prioritization because: (1) authentication bypass to cross-tenant data access is a fundamental control failure; (2) affected versions have been in production since 1.4.0, meaning widespread exposure is possible; (3) the fix is available and straightforward to apply; (4) insider threat and compromised credential scenarios make this practically exploitable. For organizations using Nezha in multi-tenant or sensitive monitoring roles, treat this as high-priority despite the CVSS score.

Risk score, explained

The CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N score of 6.5 appropriately reflects network accessibility, low attack complexity, requirement for valid authentication (PR:L), no user interaction, and high confidentiality impact limited to a single security domain. The lack of integrity or availability impact prevents a higher score. However, contextual risk is elevated in multi-tenant environments where cross-user visibility fundamentally undermines data isolation assumptions. Organizations should layer this CVSS assessment with their own risk model accounting for Nezha's criticality, tenant composition, and regulatory constraints.

Frequently asked questions