Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as non-admin member
-
DeliverySend four crafted notification API calls
-
ExploitTrigger nil-map panic leaking mutex lock
-
ExecutionDeadlock alerting subsystem
-
ImpactFlood blocking requests to exhaust memory
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Proper locking
|
| Exploitation Conditions | Requires a valid authenticated non-admin member account on the Nezha Dashboard and the ability to reach the notification API; the attacker issues four notification API calls to hit the nil-map panic path. The core limiting factor is authentication (PR:L) - the attacker must already possess credentials, so risk is highest on instances with open/self-service registration or many low-trust users, and lowest on tightly controlled single-admin deployments. No user interaction or non-default configuration is required beyond having a reachable, running alerting subsystem on an affected version (1.8.0 before 2.3.13). |
| Impact | This is a genuine but bounded availability risk, not a critical priority. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) and the 7.1 (High) score are driven entirely by availability impact (VA:H) with zero confidentiality or integrity impact (VC:N/VI:N) - consistent with the CWE-667 improper-locking root cause. The decisive mitigating signal is PR:L: exploitation requires a valid authenticated non-admin account, so this is not internet-wide drive-by attackable; the realistic threat model is a malicious or compromised low-privilege member, or an instance with open/self-service registration. No EPSS score, no CISA KEV listing, and no public exploit were provided, so there is no evidence of active exploitation or weaponization. The signals are internally consistent (no conflicts between vector and description), but the 'Information Disclosure' tag directly contradicts the vector (VC:N) and the DoS description - it appears mislabeled and should not be used to prioritize this as a data-exposure issue. |
| Exploit ScenarioDerived | A low-privilege authenticated member (or anyone who can self-register on an open instance) sends four crafted notification API calls that drive the alerting code down a nil-map panic path where a non-deferred mutex is never unlocked, permanently deadlocking the alerting subsystem. The attacker then floods the now-blocking endpoints with requests, causing unbounded memory growth and denial of service. No public exploit code was identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 03, 2026
Permanent deadlock of the alerting subsystem in Nezha Dashboard 1.8.0 through 2.3.12 allows any authenticated non-admin member to disable monitoring notifications by issuing four crafted notification API calls, and continued blocking requests can then exhaust server memory. The flaw is an improper locking issue (CWE-667) in which a mutex is unlocked non-deferred on a nil-map panic path, leaving the lock permanently held. Exploitation requires a valid low-privilege account (the assessed CVSS:3.1 vector is AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), and no public exploit code was identified at time of analysis, so this represents a genuine but bounded availability risk rather than a critical priority.
RemediationAI
Upgrade Nezha Dashboard to 2.3.13 or later, which is the vendor-released fix for this incorrect-locking defect (GHSA-7j7v-j77m-6g3m, https://github.com/nezhahq/nezha/security/advisories/GHSA-7j7v-j77m-6g3m); confirm the running dashboard version after upgrade rather than relying on the package tag alone. If immediate upgrade is not possible, the most effective compensating control is to reduce the attack surface for the PR:L prerequisite: disable public/self-service registration and remove or disable non-admin member accounts so only trusted administrators can authenticate, accepting the trade-off that legitimate multi-user monitoring access is lost. Additionally, restrict network access to the notification API endpoints (bind the dashboard behind an authenticating reverse proxy or firewall allow-list) so that only trusted clients can reach them, and apply rate limiting/request concurrency caps on those endpoints to blunt the memory-exhaustion second stage, with the trade-off that aggressive limits may delay legitimate alert delivery. As a stopgap, monitor the Nezha process for stalled alerting or rising memory and restart it to clear the leaked mutex, though this only restores service temporarily and does not remove the underlying flaw. There is no vendor-supplied configuration workaround that fixes the non-deferred unlock itself, so patching remains the only complete remedy.
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 a self-hosted server monitoring and alerting dashboard written in Go, and the affected component is its notification/alerting subsystem. The defect class is CWE-667 (Improper Locking): the code takes a mutex to protect alerting state but performs the corresponding unlock in a non-deferred statement, so when a code path triggers a panic on a nil map access, the unlock is skipped and the mutex remains held indefinitely. Because Go mutexes are not reentrant and are process-wide, every subsequent attempt to acquire the same lock blocks forever, effectively deadlocking the alerting pipeline. An attacker who already holds an authenticated non-admin member session can deliberately drive the code into the nil-map panic with four notification API calls to force the lock leak, then keep issuing blocking requests that accumulate waiting goroutines and allocations until memory is exhausted and the process becomes unavailable. The published CPE cpe:2.3:a:nezhahq:nezha identifies the vendor/product scope, and the assessed vector is AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H - notably scope-unchanged and availability-only, with no confidentiality or integrity impact. Per the vendor advisory, the issue was corrected by using a deferred unlock (or equivalent panic-safe locking) in Nezha 2.3.13.
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:N/VI:N/VA:H/SC:N/SI:N/SA:N
Network-reachable API callable by any low-privilege member (PR:L), no user interaction; impact is a permanent deadlock plus memory exhaustion, so A:H with C:N/I:N.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
2DescriptionCVE.org
Nezha Dashboard from 1.8.0 before 2.3.13 contains an improper locking vulnerability where a non-deferred mutex unlock leaks on a nil-map panic path. Any authenticated non-admin member can issue four notification API calls to permanently deadlock the alerting subsystem, then exhaust memory with blocking requests.
Technical POC Analysis
CWE-667 (Improper Locking), with CWE-248 (Uncaught Exception) and CWE-400 (Uncontrolled Resource Consumption) as the downstream consequences in the advisory.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
Nezha Dashboard 1.8.0 through 2.3.12 contains a high-severity availability flaw that lets any authenticated non-admin member disable monitoring notifications and, with sustained requests, exhaust server memory. This can create monitoring blind spots and service degradation for teams relying on Nezha for operational visibility, though the issue requires a valid low-privilege account and no public exploit was identified at time of analysis.
No vendor-released patch identified at time of analysis. Interim mitigations include restricting Nezha Dashboard access to trusted administrators, removing or disabling unnecessary non-admin accounts, rate-limiting or blocking crafted notification API calls, monitoring for alerting deadlock and memory exhaustion, and maintaining a redundant alerting channel until a vendor fix is available.
Threat Intelligence Overview
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
Host 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
Resource exhaustion in Nezha 2.0.13 through 2.3.14 allows an authenticated user to open unbounded concurrent connections
Cleartext third-party credentials are exposed to any authenticated principal holding DDNS read access in Nezha versions
Nezha monitoring dashboards running versions 1.0.0 through 2.3.14 can be knocked offline by an authenticated user who ho
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
Nezha Monitoring versions 2.0.14 through 2.1.0 (exclusive) allows any authenticated user to exploit the NAT-based Host c
EUVD-2026-92017
GHSA-2w9f-mhfg-hq53
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB