CVE-2026-49396

Summary

Summary The dashboard exposes the cron manual-trigger action as an authenticated GET /api/v1/cron/:id/manual endpoint. Dashboard JWTs are sent in the nz-jwt cookie and configured with SameSite=Lax, which browsers include on top-level cross-site GET navigations. Because this state-changing GET endpoint has no CSRF token, origin validation, or fetch-metadata guard, an attacker can cause a logged-in Nezha user to trigger one of their existing cron tasks by navigating the victim's browser to the manual-trigger URL. If the targeted cron task sends a command to an online agent, the stored command is dispatched to the agent task stream. The attacker cannot create or modify the cron command through this issue alone, but can force execution of a command that the victim already saved and is authorized to run. Details Source-to-sink chain: The dashboard registers the manual cron trigger as a GET route under the authenticated API group: auth.GET("/cron/:id/manual", commonHandler(manualTriggerCron)) at cmd/dashboard/controller/controller.go:131-134. JWT auth is cookie-enabled: CookieName: "nz-jwt", SendCookie: true, CookieSameSite: http.SameSiteLaxMode, and TokenLookup: "header: Authorization, query: token, cookie: nz-jwt" at cmd/dashboard/controller/jwt.go:23-46. The handler parses the route ID, loads the cron object, checks only normal object ownership via cr.HasPermission(c), then calls singleton.ManualTrigger(cr) at cmd/dashboard/controller/cron.go:170-187. ManualTrigger immediately runs CronTrigger(cr)() at service/singleton/crontask.go:249-250. CronTrigger dispatches the stored command to online eligible agents via s.TaskStream.Send(&pb.Task{Id: cr.ID, Data: cr.Command, Type: model.TaskTypeCommand}) at service/singleton/crontask.go:289-304 after the owner/server check in cronCanSendToServer (service/singleton/crontask.go:315-317). Object authorization is user ownership/admin only: Common.HasPermission returns true for admins or matching UserID at model/common.go:44-56. There is no CSRF token, Origin/Referer validation, or Fetch Metadata check on this GET action. False-positive screening: The endpoint is not read-only: the safe proof below observed an in-memory agent stream receiving the command task. The route is authenticated, and the unauthenticated negative control failed with ApiErrorUnauthorized and dispatched no task. SameSite=Lax mitigates cross-site POSTs, but this action uses GET; Lax cookies are still sent on top-level cross-site GET navigations, which is why state-changing GET endpoints remain CSRF-sensitive. The attacker must know or guess a cron ID owned by the victim. IDs are numeric. The issue does not allow creating or editing a command; it forces execution of an existing stored task. The permission check still limits the triggered task to the victim's own task or an admin's task, but CSRF abuses the victim's browser/session to satisfy that check. PoC Safe local proof used a Go test overlay only; no repository files were modified for the proof and no real command was executed. The test creates an in-memory SQLite database, a victim user, a victim-owned server with an in-memory fake task stream, and a victim-owned cron task with command text touch /tmp/should-not-run. It then performs two requests: Negative control: cross-site-style GET without the nz-jwt cookie. Expected result: response contains ApiErrorUnauthorized; zero tasks are dispatched. Positive proof: cross-site-style GET with the victim's nz-jwt cookie. Expected result: API response succeeds and exactly one task is dispatched to the fake agent stream with Id=7, Type=model.TaskTypeCommand, and Data="touch /tmp/should-not-run". Command run from a clean checkout of the tested tree: Observed output in this environment: The -vet=off flag was only needed because this checkout lacks the generated cmd/dashboard/docs directory and Go vet still tries to chdir into the overlay-created package directory. The overlay includes a minimal docs package stub so the controller package can compile without generating Swagger files. Cleanup: Impact A remote attacker can cause a logged-in dashboard user to trigger an existing cron task by making the user's browser navigate to /api/v1/cron/<known-id>/manual. If that cron task dispatches an agent command, the command is sent to the victim's online agent without the victim intentionally clicking the manual trigger in the dashboard. Security impact is integrity and availability: Integrity: forced execution of a stored command on victim-controlled agents. Availability: forced execution of disruptive stored tasks, repeated task starts, or repeated notifications/offline failure paths. Confidentiality: not directly demonstrated; the PoC does not show data exfiltration. Suggested remediation Make manual cron triggering a non-idempotent method such as POST /api/v1/cron/:id/manual instead of GET. Require a CSRF token for cookie-authenticated state-changing requests, or reject unsafe cross-site requests with Origin/Referer and Fetch Metadata validation. Consider not accepting JWTs from cookies for state-changing API calls unless a CSRF token is present. Add a regression test that sends a cross-site-style GET with a valid cookie and asserts no cron task is dispatched. If frontend compatibility requires cookies, keep SameSite=Lax or stricter, but do not rely on it to protect state-changing GET routes.

Impact

Affected versions

Security releases

Remediation advice