EUVD-2026-102567
GHSA-xpxc-2hwp-cv47
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as low-privilege tenant member
-
ExploitSweep sequential IDs via getServerConfig/setServerConfig
-
ExecutionDistinguish permission-denied from success responses
-
ImpactEnumerate and map other tenants' servers
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V6 - Authentication Response uniformity
|
| Exploitation Conditions | Exploitation requires a valid authenticated low-privilege member account on a Nezha dashboard (PR:L) and a multi-tenant/shared deployment where more than one tenant's servers coexist; the attacker abuses the getServerConfig and setServerConfig endpoints, relying on observable differences between 'permission denied' and success responses to act as an enumeration oracle. Limiting factors: it only works on versions 1.7.0 through 2.3.14 (patched in 2.3.15), it yields server-ID mapping rather than direct data/secret exfiltration or control, and in single-tenant self-hosted installs there are no other tenants to enumerate, sharply reducing real-world impact. |
| Impact | This is a genuine but low-to-moderate priority issue, not a top-tier emergency. The CVSS 4.0 base score is 5.3 (Medium), and every signal is internally consistent: the vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N describes a network-reachable, low-complexity attack that requires an already-authenticated low-privilege account (PR:L) and yields only low confidentiality impact (VC:L) with no integrity or availability impact. CWE-204 (Observable Response Discrepancy) matches the described differential-response oracle precisely. No EPSS score, CISA KEV listing, or public proof-of-concept was supplied in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The practical risk is bounded: an attacker must first hold a valid tenant account, and the payoff is enumeration/mapping of other tenants' server IDs rather than direct secret theft or control. The main aggravating factor is that this is a multi-tenant isolation (cross-tenant) flaw, which matters disproportionately in shared/hosted Nezha deployments; in single-tenant self-hosted installs the impact is marginal. Overall: a real, vendor-confirmed and patched isolation weakness worth remediating on a normal cycle, not a drop-everything event. |
| Exploit ScenarioDerived | An attacker registers or obtains a normal low-privilege member account on a shared Nezha dashboard, then scripts sequential server-ID requests against getServerConfig and setServerConfig. By comparing 'permission denied' responses to success/other payloads, they infer which IDs belong to other tenants and build a map of foreign servers. No public exploit code is identified at time of analysis, but the technique is simple to automate given the network vector and low attack complexity. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 16, 2026
Cross-tenant server ID enumeration in the Nezha monitoring dashboard (versions 1.7.0 through 2.3.14) lets an authenticated low-privilege member map other tenants' server IDs by sweeping sequential identifiers against the getServerConfig and setServerConfig endpoints and distinguishing 'permission denied' responses from success payloads. According to the authoritative assessment, exploitation requires a valid member account plus a shared, multi-tenant deployment where more than one user's servers coexist; on a single-tenant self-hosted install there are no other tenants to enumerate, sharply reducing real impact. It yields server-ID mapping rather than configuration contents, secrets, or control, and stays confined to a low-severity information-disclosure outcome (C:L, I:N, A:N). No public exploit code was identified at time of analysis, and this CVE is not in CISA KEV; vendor patch version 2.3.15 is available.
RemediationAI
Vendor-released patch: upgrade Nezha to 2.3.15 or later, which resolves the enumeration oracle on getServerConfig and setServerConfig; operators building from source can apply the referenced upstream commit 36b742a7e9a81ed782363dd19efd77b7030fbd0f, whose release notes should be reviewed because it also changes DDNS credential redaction, file-manager WebSocket input limits, and MCP transfer host handling, any of which can alter existing behavior. Until the upgrade is deployed, the most effective compensating control is architectural: move tenants onto separate Nezha instances or restrict dashboard membership to trusted administrators, since enumeration gains the attacker nothing where no other tenants' servers are registered. If a shared instance must remain, front the dashboard with a reverse proxy that denies the getServerConfig and setServerConfig paths to non-admin roles - accepting that this can break legitimate member and agent workflows that depend on those endpoints - and add rate limiting plus alerting for sequential-ID sweeps or for patterns of 403 responses interleaved with success responses from a single account. Rotating or renumbering server IDs is not a durable mitigation because the enumeration condition recurs with any sequential allocation scheme. Review the advisory at https://github.com/nezhahq/nezha/security/advisories/GHSA-228w-p4h4-6rvw for the authoritative fix guidance; note that no public exploit code was identified at time of analysis and that patching remains the only complete fix because the defect is a response-semantics issue rather than a configurable feature.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Nezha is an open-source, Go-based server monitoring and management panel whose dashboard exposes HTTP APIs consumed by browser clients and agent components; deployments can be multi-tenant, with multiple members owning distinct servers under one dashboard instance. The root cause is CWE-204 (Observable Response Discrepancy): the getServerConfig and setServerConfig handlers do not respond uniformly when the requested server ID belongs to another member versus when it is inaccessible or nonexistent, so an error path such as 'permission denied' is distinguishable from a valid or differently shaped response. That difference turns the endpoints into an enumeration oracle against sequential integer IDs, letting an authenticated member infer which IDs exist and belong to other tenants. This is a behavioral/oracle defect rather than an injection or memory-safety issue, and it leaks identifier key-space metadata only - not configuration values, credentials, or execution primitives. The affected CPE is cpe:2.3:a:nezhahq:nezha:*:*:*:*:*:*:*:*, with a fix commit at 36b742a7e9a81ed782363dd19efd77b7030fbd0f; that commit also bundles adjacent hardening (redaction of DDNS webhook credentials in list responses, a 1 MiB read limit on file-manager WebSocket input, and validation of operator-declared dashboard hosts for MCP transfer URLs), so it should be treated as a version bump rather than a minimal one-line fix.
Know when Nezha gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Network-reachable endpoints with low complexity, but a valid low-privilege tenant account is required (PR:L); impact is limited to disclosure of other tenants' server IDs, so C:L and I:N/A:N.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
Nezha from 1.7.0 before 2.3.15 contains an information disclosure vulnerability that allows authenticated members to enumerate other tenants' server IDs through differential responses. Attackers can sweep sequential IDs against getServerConfig and setServerConfig, distinguishing 'permission denied' from success payloads to map other users' servers.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Related Vulnerabilities in Nezha Dashboard Access Control and Disclosure Flaws
View all 5Host header injection in Nezha 2.2.3's OAuth2 redirect endpoint (/api/v1/oauth2/{provider}) allows an unauthenticated re
Unauthenticated path traversal in Nezha Monitoring (nezhahq/nezha) before 2.0.13 allows remote attackers to read arbitra
Cross-tenant session hijacking in Nezha Monitoring (v1.14.13-1.14.14 and v2.0.0-2.0.9) lets any authenticated low-privil
Permanent deadlock of the alerting subsystem in Nezha Dashboard 1.8.0 through 2.3.12 allows any authenticated non-admin
Authenticated privilege escalation in Nezha Dashboard before 2.3.5 lets any account holding the nezha:service:write scop
Denial of service in the Nezha monitoring dashboard before 2.3.8 lets any authenticated non-administrator account crash
Nezha Monitoring versions prior to 2.2.5 expose stored third-party API credentials in plaintext through two listing API
Host header injection in Nezha Monitoring versions 1.0.0 through 2.2.0 allows unauthenticated remote attackers to redire
Unbounded WebSocket stream allocation in Nezha Monitoring versions 1.0.0 through 2.1.x allows any authenticated dashboar
Exploit-DB