CVE-2026-53519 is a critical-severity path traversal vulnerability in github.com/nezhahq/nezha (go), affecting versions < 2.0.13. It is fixed in 2.0.13.
Summary fallbackToFrontend in the dashboard's NoRoute handler treats any URL whose raw string starts with /dashboard as an admin-frontend asset request. The check uses strings.HasPrefix, not a path-segment match, so the input /dashboard../data/config.yaml is accepted; strings.TrimPrefix leaves ../data/config.yaml; and path.Join("admin-dist", "../data/config.yaml") normalizes to data/config.yaml, which os.Stat finds and http.ServeFile returns. No authentication required. In default deployments (the values shipped in model/config.go and the layout shipped in the project Dockerfile) data/config.yaml contains the HS256 jwtsecretkey used by cmd/dashboard/controller/jwt.go to sign every dashboard session cookie. A unauth attacker reads that secret, forges an admin JWT, and signs in as any user, full dashboard takeover from one GET request. Details Root cause fallbackToFrontend is wired as the catch-all at cmd/dashboard/controller/controller.go:157, r.NoRoute(fallbackToFrontend(frontendDist)), so every URL not matched by an earlier route reaches it, including pre-auth. Path math (verified, see appendix) | Input URL.Path | TrimPrefix(..., "/dashboard") | path.Join("admin-dist", ...) | Reachable file | |---|---|---|---| | /dashboard/login | /login | admin-dist/login | legitimate, intended | | /dashboard/../data/config.yaml | /../data/config.yaml | data/config.yaml | but blocked by Go http.ServeFile's URL ..-segment guard → 400 | | /dashboard../data/config.yaml | ../data/config.yaml | data/config.yaml | served, 200 | | /dashboard%2e%2e/data/config.yaml | ../data/config.yaml (decoded) | data/config.yaml | served, 200 | | /dashboard..%2fdata/config.yaml | ../data/config.yaml (decoded) | data/config.yaml | served, 200 | The negative control (/dashboard/../data/config.yaml) lands at the same on-disk path after path.Join, but is rejected by http.ServeFile because Go's stdlib enforces a URL-level traversal guard that fires when the request URL itself contains a standalone .. segment. The bypass works because in /dashboard../... the first URL segment is the single token dashboard.., no standalone .., so the stdlib guard does not trigger. The traversal segment is created after TrimPrefix, downstream of every defense. Why the existing defenses miss The prefix check is a substring test on the raw URL string, not a segment test. dashboard and dashboard.. are both accepted. path.Join silently Cleans the result, so the .. is consumed correctly to escape admin-dist, with no error returned to indicate escape. Go's http.ServeFile stdlib guard fires only on URLs with a standalone .. segment (per net/http.containsDotDot). The payload puts the dots inside the first segment instead. No anchored "is this still under the template root?" check exists after path.Join. PoC Setup The harness plants this data/config.yaml: Observed responses Primary payload, pre-auth secret disclosure: Negative control, Go stdlib guard rejects the canonical form: Encoded-dot variant, bypass also works: Encoded-slash variant, bypass also works: Double-encoded, confirms the bypass requires single-level encoding: The literal %252e%252e does not decode to .., so the path becomes admin-dist/%2e%2e/data/config.yaml (no escape), os.Stat fails, and the handler falls through to serving admin-dist/index.html, no secret disclosure. Encoded leading slash, also blocked at the stdlib layer: SQLite database exfil, same primitive: Sanity checks Normal /dashboard/ request still serves admin-dist/index.html with HTTP 200, the bypass does not regress legitimate behavior. Requests to /api/... still hit the JSON-404 branch, the bypass is isolated to the /dashboard fallback. Impact Direct primitive Unauth read of any file in the dashboard's working directory subtree reachable by escaping admin-dist one level. In default deployments that includes: | File | Default path | Why it matters | |---|---|---| | data/config.yaml | from -c flag default (cmd/dashboard/main.go:104) | Contains jwtsecretkey (signing key, HS256), agentsecretkey, OAuth2 client secrets, GitHub release token, GeoIP API key, and any custom secrets | | data/sqlite.db | from -db flag default (cmd/dashboard/main.go:105) | Full dashboard state: users (incl. admin), bcrypt password hashes, server registry, API tokens, notification configs | Chain to administrative account takeover (verified path) Read config, GET /dashboard../data/config.yaml returns plaintext YAML containing jwtsecretkey. Read database, GET /dashboard../data/sqlite.db returns the SQLite file; an attacker opens it and reads the users table to recover admin user IDs (and any other claims the JWT references). Forge a JWT, the dashboard's JWT middleware at cmd/dashboard/controller/jwt.go:22,27 is wired with: go Key: []byte(singleton.Conf.JWTSecretKey), SigningAlgorithm: "HS256", CookieName: "nz-jwt", IdentityKey: model.CtxKeyAuthorizedUser, HS256 is symmetric, possession of the key is sufficient to sign tokens that pass verification. An attacker mints a token whose user_id claim matches the admin user from step 2 and attaches it as the nz-jwt cookie (or Authorization: Bearer ...). Operate as admin, every admin handler (adminHandler chain) now accepts the forged session, granting CRUD on servers, users, cron tasks, notifications, and OAuth2 settings. The chain is fully deterministic against a default-configured dashboard: two unauth HTTP GETs and a JWT signing operation, no race, no user interaction, no special timing. Suggested fix Make the prefix test segment-aware and reject paths whose cleaned form escapes the template root before any filesystem call. Minimal diff: The /dashboard -> /dashboard/ redirect at line 382 already exists, so requiring the trailing slash is safe and aligns with the regexes in frontendPageUrlRegistry. The same hardening should be applied to the user-template branch (lines 399–405), which uses the same path.Join pattern with singleton.Conf.UserTemplate. While the /dashboard prefix-confusion vector doesn't hit it directly, any future code change that hands a controlled URL.Path to that branch would re-introduce the same primitive. A defense-in-depth alternative is to replace the local os.Stat + http.ServeFile branch with a http.FileServer(http.FS(subFS)) rooted at the embedded admin-dist subdirectory, which keeps the embedded-FS contract and removes the working-directory escape entirely.
Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files. Typical impact: unauthorized file read or write outside the intended directory.
CVE-2026-53519 has a CVSS score of 9.1 (Critical). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment.
A fixed version is available (2.0.13). Upgrading removes the vulnerable code path.
go
github.com/nezhahq/nezha (< 2.0.13)github.com/nezhahq/nezha → 2.0.13 (go)Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter instead of chasing every advisory.
Kodem's runtime-powered SCA identifies whether CVE-2026-53519 is reachable in your applications. Explore open-source security for your team.
See if CVE-2026-53519 is reachable in your applications. Get a demo
Already deployed Kodem? See CVE-2026-53519 in your environment →Upgrade github.com/nezhahq/nezha to 2.0.13 or later to resolve this vulnerability.
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
CVE-2026-53519 is a critical-severity path traversal vulnerability in github.com/nezhahq/nezha (go), affecting versions < 2.0.13. It is fixed in 2.0.13. Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files.
CVE-2026-53519 has a CVSS score of 9.1 (Critical). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
github.com/nezhahq/nezha (go) versions < 2.0.13 is affected.
Yes. CVE-2026-53519 is fixed in 2.0.13. Upgrade to this version or later.
Whether CVE-2026-53519 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
Upgrade github.com/nezhahq/nezha to 2.0.13 or later.