Nezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O&M tool. From version 1.0.0 to before version 2.0.14, cross-site GET request can trigger stored cron commands on a victim's agents. This issue has been patched in version 2.0.14.

Affected: Go: github.com/nezhahq/nezha

### 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:

1. 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`. 2. 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`. 3. 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/controll…