CVE-2026-101085: Nezha Dashboard DOS Vulnerability

CVE-2026-101085 Overview

CVE-2026-101085 is a denial-of-service vulnerability in Nezha, a self-hosted server monitoring and management platform. Versions before 2.3.8 fail to validate alert rule type and duration bounds submitted through the dashboard API. Authenticated non-administrator users can submit a crafted alert rule via the POST /api/v1/alert-rule endpoint. The malformed rule triggers an unrecovered panic in the alert evaluator goroutine, crashing the dashboard process. Because the dashboard persists the rule before evaluation, the panic repeats on every restart, disabling all monitoring and control plane functionality until the record is removed from the database.

Critical Impact

A single low-privileged API request can permanently crash the Nezha dashboard and disable the entire monitoring control plane until manual database intervention.

Affected Products

• Nezha monitoring dashboard versions prior to 2.3.8
• Deployments exposing the /api/v1/alert-rule endpoint to authenticated users
• Self-hosted Nezha instances with multi-user access enabled

Discovery Timeline

• 2026-09-27 - CVE-2026-101085 published to the National Vulnerability Database (NVD)
• 2026-09-28 - Last updated in NVD database

Technical Details for CVE-2026-101085

Vulnerability Analysis

The vulnerability is categorized as a Numeric Truncation Error [CWE-197] combined with missing input validation. The Nezha dashboard accepts alert rule definitions through a REST endpoint without enforcing bounds on the rule type field or the duration field. When the alert evaluator goroutine later deserializes and processes the malformed rule, it encounters values outside the supported range and triggers a runtime panic. Because the panic occurs in a background goroutine without recovery handling, it propagates to the parent process and terminates the dashboard.

The persistence layer compounds the impact. The crafted rule is written to the database before evaluation, so restarting the dashboard reloads the same rule and triggers the same panic. Administrators cannot restore service through normal process restarts and must manually delete the malicious record from the backing store.

Root Cause

The root cause is insufficient server-side validation on the alert rule creation handler. The code path accepts user-supplied values for alert type and duration without range checks, and the downstream evaluator does not defensively handle unexpected values. The absence of a recover() call in the alert evaluator goroutine means a single panic takes down the entire process.

Attack Vector

Exploitation requires only low-privileged authenticated access. Any user who can reach the POST /api/v1/alert-rule endpoint can submit a crafted JSON payload with an invalid alert type or out-of-range duration. The attack is network-reachable, requires no user interaction, and produces a persistent denial-of-service condition. Refer to the GitHub Security Advisory GHSA-2qc6-x993-hjq9 and the VulnCheck Advisory - Nezha DoS for payload details.

Detection Methods for CVE-2026-101085

Indicators of Compromise

• Repeated crashes of the Nezha dashboard process immediately after startup
• Alert rule records in the database with unrecognized type values or extreme duration values
• POST /api/v1/alert-rule requests from non-administrator user sessions in access logs
• Goroutine panic stack traces referencing the alert evaluator in dashboard logs

Detection Strategies

• Review Nezha dashboard logs for Go runtime panic messages originating in the alert evaluation subsystem
• Audit the alert rule table for entries created by non-administrator accounts and validate field values against the supported schema
• Correlate dashboard restart events with recent writes to the alert rule endpoint

Monitoring Recommendations

• Instrument dashboard process health with external uptime monitoring to identify crash loops quickly
• Enable HTTP access logging on the Nezha API and forward logs to a central analytics platform
• Alert on repeated POST /api/v1/alert-rule requests from the same user within short windows

How to Mitigate CVE-2026-101085

Immediate Actions Required

• Upgrade Nezha to version 2.3.8 or later, which adds validation for alert rule type and duration fields
• Audit existing alert rules and remove any records containing invalid or out-of-range values
• Restrict dashboard account creation and review the privilege level of all non-administrator users

Patch Information

The maintainers released a fix in Nezha 2.3.8. The patch enforces bounds on alert rule input fields and prevents malformed rules from reaching the evaluator. See the GitHub Security Advisory GHSA-2qc6-x993-hjq9 for the full fix commit and upgrade guidance.

Workarounds

• Place the Nezha dashboard behind a reverse proxy that blocks the /api/v1/alert-rule endpoint for non-administrator sessions until patching is complete
• Disable or remove non-administrator accounts on exposed dashboards as a temporary control
• If a crash loop is already in progress, stop the dashboard, delete the offending row from the alert rule table, then restart the service

# Example: identify and remove a malicious alert rule from SQLite backing store
sqlite3 /opt/nezha/data/sqlite.db \
  "SELECT id, name, type, duration FROM alert_rules;"
sqlite3 /opt/nezha/data/sqlite.db \
  "DELETE FROM alert_rules WHERE id = <offending_id>;"