Nezha EUVD-2026-114328

Exploitation requires an authenticated dashboard account (PR:L) capable of calling POST /api/v1/batch-delete/service to delete its own service, and it only harms deployments running the dashboard in non-TSDB mode - the description scopes the crash to 'the non-TSDB dashboard.' The denial of service is not instantaneous: it manifests only on the dashboard's next startup/restart, when loadTodayStats processes the orphaned service_histories rows, and persists across restarts until an operator manually deletes those rows. Limiting factors: authentication is mandatory (no anonymous path), TSDB-backed configurations appear unaffected, and the attacker cannot directly choose the trigger moment since it depends on a restart occurring.

This is a genuine but low-urgency availability issue, not a widespread-exploitation priority. The CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:L/UI:N) and the 6.0 Medium score align well with the description: impact is confined to availability (VA:H; VC:N/VI:N), the attacker must be authenticated (PR:L), and the crash does not fire on demand but only on the dashboard's next startup - consistent with AC:H and the AT:P attack-requirement, since the attacker does not control when the restart occurs. There is no KEV listing and no verified public exploit code (only a vendor advisory and the patch commit are referenced), so exploitation status is 'no public exploit identified at time of analysis'; EPSS was not supplied. vuln.today assigns the decision label 'this_month', and SSVC-style signals agree: a low-privileged but legitimate user can self-inflict the condition, technical impact is a denial of service rather than code execution or data loss. One important conditional limit the raw vector does not convey: the crash only affects the non-TSDB dashboard configuration, so TSDB-backed deployments are not in scope per the description. Net: a real, patch-worthy robustness bug in a self-hosted product, but low real-world risk relative to its score - no confidentiality or integrity impact and a prerequisite of authenticated access.

A low-privileged but authenticated Nezha dashboard user issues POST /api/v1/batch-delete/service to delete their own service, which hard-deletes the service but leaves orphaned service_histories rows behind. On the dashboard's next startup, ServiceSentinel.loadTodayStats dereferences a nil status map entry for that orphaned history and the process panics, producing a crash that recurs on each startup until the rows are removed manually. No public exploit code is identified; the bug and fix are confirmed from the vendor commit and VulnCheck advisory.