GHSA-8qhj-4f8c-j8qg Nezha has cross-site GET request that can trigger stored cron commands on a victim's agents
SummaryThe 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.DetailsSource-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.PoCSafe 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:ImpactA 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 remediationMake 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.
CVSS v3.1 score: 7.1