EUVD-2026-88020
GHSA-5j6x-8f94-88gc
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as non-admin user
-
DeliverySubmit crafted alert rule to POST /api/v1/alert-rule
-
ExploitTrigger unrecovered panic in evaluator goroutine
-
ExecutionRule persisted to datastore
-
ImpactRepeated crash-loop on restart disables monitoring
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Numeric truncation prevention
|
| Exploitation Conditions | Requires a valid authenticated but non-administrator account on the Nezha dashboard (PR:L) and network reachability to the dashboard's HTTP API. The attacker submits a malformed alert rule - one with an invalid rule type or a duration value outside accepted bounds - to the POST /api/v1/alert-rule endpoint; no admin role, user interaction, or special deployment mode is needed. Limiting factors: exploitation is gated on obtaining any account, so instances that disable self-registration and restrict accounts to trusted users materially reduce exposure; impact is confined to availability (monitoring outage), with recovery requiring manual removal of the persisted rule from the backing datastore since the process crash-loops on restart. |
| Impact | This is a genuine but bounded availability threat. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H) scoring 7.1 is internally consistent with the description: a remote, low-privilege (any authenticated non-admin) user can trigger a high-availability impact with no user interaction and low complexity, while confidentiality and integrity are untouched. The severity comes entirely from the persistence/self-perpetuating nature - the malformed rule is stored, so the process crash-loops on every restart, effectively bricking the monitoring/control plane until an operator manually removes the rule from the datastore. No EPSS score, no CISA KEV listing, and no public proof-of-concept were provided, so there is no public exploit identified at time of analysis. The practical barrier is that PR:L requires a valid (even if unprivileged) account, which limits this to insiders, compromised low-tier accounts, or instances with open/weak registration. This is a real, easy-to-weaponize DoS worth patching promptly for exposed multi-user deployments, but it is not a remote-unauthenticated RCE and should not be prioritized as critical. |
| Exploit ScenarioDerived | An attacker with any non-administrator account on a Nezha dashboard submits a single crafted alert rule with an invalid rule type or out-of-bounds duration to POST /api/v1/alert-rule. The alert-evaluator goroutine panics and is not recovered, crashing the dashboard process; because the rule was persisted, the process crash-loops on every restart, disabling all monitoring and control-plane functionality. No public PoC is available, but exploitation is trivial given the low complexity and single-request nature. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 27, 2026
Denial of service in the Nezha monitoring dashboard before 2.3.8 lets any authenticated non-administrator account crash the dashboard process by submitting a malformed alert rule (invalid rule type or out-of-bounds duration) to POST /api/v1/alert-rule, which triggers an unrecovered panic in the alert evaluator goroutine. Because the offending rule is persisted, the dashboard enters a crash loop on every restart, taking down monitoring and the control plane until the bad record is manually removed from the backing datastore. No public exploit code was identified at time of analysis, exploitation requires only a low-privileged account (CVSS PR:L) and network reachability to the dashboard API, and impact is confined to availability with no confidentiality or integrity loss.
RemediationAI
Upgrade Nezha to version 2.3.8 or later, which is the release boundary that resolves the missing validation - vendor-released patch: 2.3.8, per the advisory at https://github.com/nezhahq/nezha/security/advisories/GHSA-2qc6-x993-hjq9. Because the trigger requires only a valid non-administrator account, the most effective compensating control is to disable self-registration and restrict dashboard accounts to trusted operators, which materially reduces exposure for unpatched instances; the trade-off is ongoing manual user provisioning and no protection against an already-provisioned low-privileged user. You can additionally block or rate-limit POST /api/v1/alert-rule at a reverse proxy or WAF for non-administrator sessions, accepting that this breaks legitimate alert rule management for those users. Note that a simple restart will NOT restore service: the malformed rule persists in the backing datastore and re-triggers the panic, so recovery requires directly deleting the offending alert-rule record from the database before or after applying the upgrade. Restrict network exposure of the dashboard API to trusted management networks as a defense in depth, and confirm the panic is fully suppressed on restart after the upgrade.
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 server monitoring and control-plane dashboard written in Go, and the affected component is its alert-rule subsystem. The flaw is rooted in insufficient input validation - categorized as CWE-197 (numeric truncation error) - where the alert rule type field and duration bounds are not properly checked before being stored and consumed. A duration value that is malformed or outside the accepted range is handled unsafely when the alert evaluator goroutine processes it, resulting in an unrecovered panic that terminates the dashboard process. The CPE cpe:2.3:a:nezhahq:nezha:*:*:*:*:*:*:*:* (all versions before 2.3.8) confirms the vendor is nezhahq and the entire pre-2.3.8 release line is in scope. The critical aggravating factor is persistence: the malformed rule survives in the datastore, so the evaluator re-reads and re-panics on every restart, converting a single request into a self-inflicted, recurring outage rather than a transient crash.
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
Remote authenticated low-priv user (PR:L) sends one request with no interaction (AC:L/UI:N); impact is availability-only via persistent crash-loop (A:H), no C/I impact, no scope change.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
2DescriptionCVE.org
Nezha before 2.3.8 fails to validate alert rule type and duration bounds, allowing authenticated non-administrator users to create malformed rules that trigger unrecovered panics in the alert evaluator goroutine. Attackers can submit a crafted alert rule via the POST /api/v1/alert-rule endpoint to crash the dashboard process, which persists the rule and causes repeated crashes on restart, disabling all monitoring and control plane functionality.
Technical POC Analysis
Evidence caveat: no patch diff was supplied with this evidence set.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
Nezha monitoring dashboard deployments prior to version 2.3.8 can be driven into a persistent crash loop by any authenticated user holding even a basic, non-administrative account. Because the malicious alert rule is saved to the database, the dashboard does not recover on restart, meaning the organization loses both its monitoring visibility and the associated control plane until an engineer manually deletes the offending record from the datastore. Leadership should care because this is an availability risk that any internal low-privilege account holder - or anyone who compromises one - can trigger repeatedly, and currently there is no vendor patch to close it.
No vendor-released patch identified at time of analysis. Interim mitigations: restrict network reachability to the dashboard API (place behind VPN or allow-listed management segment), minimize and audit non-administrator dashboard accounts, enforce reverse-proxy/WAF validation of alert-rule payloads (rule type and duration bounds), monitor for dashboard restarts or panic events, and maintain a tested procedure plus datastore access to remove the persisted offending alert_rule record on each restart until a fix is available.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
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
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
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
Permanent deadlock of the alerting subsystem in Nezha Dashboard 1.8.0 through 2.3.12 allows any authenticated non-admin
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
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
Exploit-DB