CVE-2026-49397: Nezha Monitoring Private Service Enumeration Vulnerability

Technical summary

The vulnerability stems from insufficient access controls on per-server service enumeration endpoints. Nezha's service visibility flag (EnableShowInService: false) is meant to prevent private services from appearing in public-facing dashboards and API responses. However, the implementation fails to enforce this restriction consistently across all endpoint types. Attackers can bypass the visibility control by directly querying per-server endpoints, which either list services without respecting the privacy flag or leak service metadata through information channels like response timing. This creates a side-channel information disclosure affecting CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor), with contributing factors in CWE-285 (Improper Authorization) and CWE-863 (Incorrect Authorization).

Business impact

For organizations deploying Nezha to monitor mixed public and private infrastructure, this vulnerability compromises the operational security model. Administrators may run private internal services (databases, admin interfaces, development systems) alongside public-facing services, relying on the EnableShowInService flag to prevent exposure. An attacker who discovers these hidden services gains reconnaissance data: service names hint at functionality, and timing measurements can reveal which systems are active and potentially their load or availability state. In multi-tenant or sensitive environments, this information leakage could facilitate targeted attacks, help attackers map internal dependencies, or expose the existence of systems that should remain invisible. Patch compliance is straightforward, making remediation risk relatively low if deployment tracking is in place.

Affected systems

Nezha Monitoring versions 2.0.0 through 2.0.13 are vulnerable. Self-hosted instances of Nezha running these versions with private services configured are at risk. The vulnerability does not require special deployment conditions—any instance with at least one service marked as private (EnableShowInService: false) is potentially affected. Downstream distributions or forks bundling Nezha within those version ranges may also be vulnerable; verify the exact Nezha version included in any monitoring solution that wraps it.

Exploitability

Exploitation is straightforward and requires only network access to the Nezha instance; no authentication is needed. An attacker can enumerate per-server endpoints without credentials, making the attack vector Network with Low attack complexity. The impact is limited to information disclosure—no system compromise, privilege escalation, or service disruption occurs. However, the low barrier to discovery and the informational nature of the leak (service names and timing data) make this a practical reconnaissance technique. Timing-based side channels may require some skill to reliably extract, but basic service enumeration is trivial. The CVSS 3.1 score of 5.3 (Medium) reflects the low attack complexity and lack of authentication requirements, balanced against the informational-only impact.

Remediation

Upgrade Nezha Monitoring to version 2.0.14 or later. This patch closes the enumeration gap by enforcing the EnableShowInService privacy flag on per-server service endpoints. After upgrading, verify that private services no longer appear in or leak from API responses by testing against the enumeration endpoints. No configuration changes should be necessary post-patch; the fix corrects the underlying authorization logic.

Patch guidance

Apply version 2.0.14 or later to all Nezha Monitoring instances. Verify the update through your package manager, container registry, or official Nezha release channels. Test the patch in a staging environment if possible, querying per-server endpoints to confirm that services marked as private are no longer enumerable. Monitor logs after patching for any connection anomalies. Because Nezha is a self-hosted tool, patch deployment depends on your organization's deployment model (containers, binaries, package managers); ensure all instances are updated, including any replicas or backup instances.

Detection guidance

Monitor logs for repeated queries to per-server service endpoints (such as /api/server/{id}/services or similar paths depending on Nezha version) from unauthenticated or unexpected sources. Timing analysis—detecting multiple rapid endpoint requests with varying server IDs—can indicate enumeration activity. Review Nezha configuration files for services with EnableShowInService: false and cross-reference them against recent API request logs to see if they were targeted. Network intrusion detection systems can flag patterns of repeated endpoint scanning. Vulnerability scanning tools targeting Nezha should flag versions below 2.0.14.

Why prioritize this

This is a medium-severity flaw affecting reconnaissance and operational security posture. While it does not enable direct system compromise, it undermines the intended privacy model for sensitive monitoring data. Organizations operating mixed public/private infrastructure and relying on Nezha's visibility controls should prioritize patching. The fix is contained in a single version bump with no apparent breaking changes, making it low-risk to deploy. Patch within your standard maintenance window, prioritizing instances that monitor sensitive or internal systems.

Risk score, explained

CVSS 5.3 (Medium) accurately reflects the risk: the vulnerability is easily exploitable over the network without authentication (AV:N, AC:L, PR:N, UI:N), but the impact is confined to information disclosure with low confidentiality impact (C:L) and no impact on integrity or availability. The lack of authentication and straightforward attack surface push severity upward, while the limited scope and informational-only damage keep it moderate rather than high. Organizations running older versions with private services should treat this as a priority within the medium tier.

Frequently asked questions