CVE-2026-100394: Nezha monitoring dashboard denial of service via service deletion race

CVE-2026-100394 · Severity: medium · CVSS 6.5 · Published 2026-10-14

Nezha is a server monitoring dashboard that tracks service health via agent reports. A low-privilege member can crash the entire dashboard process by creating and deleting services while rapidly sending monitoring data, bringing down the web UI and APIs for all tenants. The attack requires only access to their own services and agents, no administrative privileges.

Technologies: github.com/nezhahq/nezha (Go). Vendors: Go, Nezha.

Quick answers

Is CVE-2026-100394 exploited in the wild?
No. Junglewise Threat Intelligence has no report of CVE-2026-100394 being exploited in the wild.
How severe is CVE-2026-100394?
Medium severity, with a CVSS score of 6.5, published 14 October 2026.
Which products and versions are affected?
github.com/nezhahq/nezha (Go) >= 0.0.0-20260628010923-fd31e5f1b0f8, < 0.0.0-20260721131105-c893aa57867d, SEMVER:introduced=0.0.0-20260628010923-fd31e5f1b0f8,fixed=0.0.0-20260721131105-c893aa57867d; Nezha monitoring dashboard v2.2.7 through v2.2.10.
Is there a fix for CVE-2026-100394?
Yes. github.com/nezhahq/nezha (Go): upgrade to 0.0.0-20260721131105-c893aa57867d or later. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is CVE-2026-100394 attacked?
It is attacked over the network, in a hosted service.
Am I affected by CVE-2026-100394?
Check whether you run github.com/nezhahq/nezha (Go) or Nezha monitoring dashboard at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

How to fix

  • github.com/nezhahq/nezha (Go): upgrade to 0.0.0-20260721131105-c893aa57867d or later
    go get github.com/nezhahq/nezha@v0.0.0-20260721131105-c893aa57867d

Technical details

A nil pointer dereference in the service-monitor worker (servicesentinel.go:601) occurs due to a cross-lock TOCTOU between the check-and-use of service status maps. The worker validates service existence under servicesLock, then writes to status maps under serviceResponseDataStoreLock at a later point; a concurrent delete removes map entries in the gap between these two locks. Since the gRPC server lacks a recovery interceptor, the panic in the worker goroutine terminates the entire process. Attack preconditions: member authentication via agent credentials, ability to create/delete own services, and sending ping results over gRPC.

Affected products

  • Nezha Nezha monitoring dashboard v2.2.7 through v2.2.10

Identifiers

  • CVE-2026-100394
  • GHSA-qjpp-gffx-2wm9
  • GO-2026-6794

Timeline

  • 2026-10-15: disclosed

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.