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.
13470 vulnerabilities reference this CWE, most recent first.
GHSA-498W-8867-93P4
Vulnerability from github – Published: 2022-05-17 04:43 – Updated: 2022-05-17 04:43Directory traversal vulnerability in Sixnet SixView Manager 2.4.1 allows remote attackers to read arbitrary files via a .. (dot dot) in an HTTP GET request to TCP port 18081.
{
"affected": [],
"aliases": [
"CVE-2014-2976"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2014-04-23T15:55:00Z",
"severity": "MODERATE"
},
"details": "Directory traversal vulnerability in Sixnet SixView Manager 2.4.1 allows remote attackers to read arbitrary files via a .. (dot dot) in an HTTP GET request to TCP port 18081.",
"id": "GHSA-498w-8867-93p4",
"modified": "2022-05-17T04:43:49Z",
"published": "2022-05-17T04:43:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2014-2976"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/58231"
},
{
"type": "WEB",
"url": "http://www.exploit-db.com/exploits/32973"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-499R-G7PC-VMP9
Vulnerability from github – Published: 2026-07-20 19:15 – Updated: 2026-07-20 19:15Summary
A maliciously crafted package, published on an untrusted third party repository other than Packagist.org or Private Packagist, can cause Composer to write files outside the vendor/ directory and outside your project, with attacker-controlled content, during a normal install or update through using an invalid package name, which was not correctly validated by Composer.
This is an arbitrary file write that can be used to execute code outside the Composer project's context in which you expected the package code to execute (for example by writing shell startup files, SSH authorized_keys, or a cron entry). It is a supply-chain issue: it requires a malicious or compromised package to be present in the dependency graph, it is not otherwise remotely exploitable against a machine.
The fix makes Composer validate every package produced by dependency resolution before anything is written to composer.lock or installed, and abort with a security error if a package name is not a valid vendor/package name.
Am I affected?
You may be affected if you install packages from an untrusted third party repository, which does not sufficiently validate package names. Packagist.org and Private Packagist are safe, as they validate package names correctly.
Patched versions
Fixed in 2.2.29 and 2.10.2. Composer 1.x is also affected and you should move to a safe 2.x release.
Workarounds
Do not use untrusted package repositories. If you have to, mirror them through an internal repository like Private Packagist.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "composer/composer"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "2.10.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "composer/composer"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "2.2.29"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-59948"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-787"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-20T19:15:29Z",
"nvd_published_at": "2026-07-08T20:16:59Z",
"severity": "HIGH"
},
"details": "## Summary\n\nA maliciously crafted package, published on an untrusted third party repository other than Packagist.org or Private Packagist, can cause Composer to write files outside the `vendor/` directory and outside your project, with attacker-controlled content, during a normal `install` or `update` through using an invalid package name, which was not correctly validated by Composer.\n\nThis is an arbitrary file write that can be used to execute code outside the Composer project\u0027s context in which you expected the package code to execute (for example by writing shell startup files, SSH `authorized_keys`, or a cron entry). It is a supply-chain issue: it requires a malicious or compromised package to be present in the dependency graph, it is not otherwise remotely exploitable against a machine.\n\nThe fix makes Composer validate every package produced by dependency resolution before anything is written to `composer.lock` or installed, and abort with a security error if a package name is not a valid `vendor/package` name.\n\n## Am I affected?\n\nYou may be affected if you install packages from an untrusted third party repository, which does not sufficiently validate package names. Packagist.org and Private Packagist are safe, as they validate package names correctly.\n\n## Patched versions\n\nFixed in **2.2.29** and **2.10.2**. Composer 1.x is also affected and you should move to a safe 2.x release.\n\n## Workarounds\n\nDo not use untrusted package repositories. If you have to, mirror them through an internal repository like Private Packagist.",
"id": "GHSA-499r-g7pc-vmp9",
"modified": "2026-07-20T19:15:29Z",
"published": "2026-07-20T19:15:29Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/composer/composer/security/advisories/GHSA-499r-g7pc-vmp9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59948"
},
{
"type": "WEB",
"url": "https://github.com/composer/composer/commit/502c6c4f699802d9cf464728b3e8a95674f919a0"
},
{
"type": "WEB",
"url": "https://github.com/composer/composer/commit/c50b1efd13ebd73f6dca19b31424c5a02bf93cc1"
},
{
"type": "PACKAGE",
"url": "https://github.com/composer/composer"
},
{
"type": "WEB",
"url": "https://github.com/composer/composer/releases/tag/2.10.2"
},
{
"type": "WEB",
"url": "https://github.com/composer/composer/releases/tag/2.2.29"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Composer: Arbitrary file write outside vendor via malicious transitive package name"
}
GHSA-49F4-QCXF-QV2V
Vulnerability from github – Published: 2023-01-09 18:30 – Updated: 2023-01-12 21:30Path-Traversal in MKP storing in Tribe29 Checkmk <=2.0.0p32 and <= 2.1.0p18 allows an administrator to write mkp files to arbitrary locations via a malicious mkp file.
{
"affected": [],
"aliases": [
"CVE-2022-4884"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-01-09T17:15:00Z",
"severity": "MODERATE"
},
"details": "Path-Traversal in MKP storing in Tribe29 Checkmk \u003c=2.0.0p32 and \u003c= 2.1.0p18 allows an administrator to write mkp files to arbitrary locations via a malicious mkp file.",
"id": "GHSA-49f4-qcxf-qv2v",
"modified": "2023-01-12T21:30:24Z",
"published": "2023-01-09T18:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4884"
},
{
"type": "WEB",
"url": "https://checkmk.com/werk/15065"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-49GV-J75H-V44Q
Vulnerability from github – Published: 2025-09-26 09:31 – Updated: 2026-04-01 18:36Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in SeaTheme BM Content Builder allows Path Traversal. This issue affects BM Content Builder: from n/a through n/a.
{
"affected": [],
"aliases": [
"CVE-2025-59002"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-26T09:15:33Z",
"severity": "HIGH"
},
"details": "Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027) vulnerability in SeaTheme BM Content Builder allows Path Traversal. This issue affects BM Content Builder: from n/a through n/a.",
"id": "GHSA-49gv-j75h-v44q",
"modified": "2026-04-01T18:36:20Z",
"published": "2025-09-26T09:31:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59002"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/bm-builder/vulnerability/wordpress-bm-content-builder-plugin-3-16-3-3-arbitrary-file-deletion-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-49H3-CWHJ-4737
Vulnerability from github – Published: 2026-07-24 20:41 – Updated: 2026-07-24 20:41Summary
Cloudreve's WOPI PUT_RELATIVE handler treats X-WOPI-SuggestedTarget as a path, not a filename. It splits the header on / and joins the segments onto the source file's directory with URI.JoinRaw, which feeds Go's url.JoinPath. url.JoinPath resolves ./.. segments, so a slash-bearing target such as a/../../evil.docx collapses to a location outside the source file's directory. The lower-level upload path then validates only the final, already-cleaned basename (evil.docx), which is harmless, and checks ownership against the resolved ancestor — which is still the same user's drive.
A WOPI access token is bound to exactly one file (the route enforces fileId == session.FileID with a 403 otherwise). PUT_RELATIVE escapes that per-file scope: a token issued for one file can create (and, conditionally, overwrite) files elsewhere in the same account.
Root cause (verified at 26b6b10)
1. Token is single-file scoped (the boundary being escaped) — middleware ViewerSessionValidation:
fileId := hashid.FromContext(c)
if fileId != session.FileID { // 403 — token is bound to ONE file
c.Status(http.StatusForbidden); c.Abort(); return
}
Route: wopi := noAuth.Group("file/wopi", middleware.HashID(hashid.FileID), middleware.ViewerSessionValidation()); wopi.POST(":id", controllers.ModifyFile) → POST /api/v4/file/wopi/:id?access_token=<token>.
2. PUT_RELATIVE dispatch — routers/controllers/wopi.go:
case wopi.MethodPutRelative: // X-WOPI-Override: PUT_RELATIVE
err = service.PutContent(c, true)
3. SuggestedTarget joined as a path — service/explorer/viewer.go:
fileName, _ := wopi.UTF7Decode(c.GetHeader(wopi.SuggestedTargetHeader)) // X-WOPI-SuggestedTarget
fileUriParsed, _ := fs.NewUriFromString(fileUri)
if strings.HasPrefix(fileName, ".") { /* treat as extension */ }
fileUri = fileUriParsed.DirUri().JoinRaw(fileName).String() // <-- path join, not basename
...
subService := FileUpdateService{ Uri: fileUri }
res, err := subService.PutContent(c, lockSession)
4. JoinRaw splits on / and normalizes via url.JoinPath — pkg/filemanager/fs/uri.go:
func (u *URI) Join(elem ...string) *URI {
newUrl, _ := url.Parse(u.U.String())
return &URI{U: newUrl.JoinPath(/* PathEscape each elem */ ...)} // JoinPath cleans ./ and ../
}
func (u *URI) JoinRaw(elem string) *URI {
return u.Join(strings.Split(strings.TrimPrefix(elem, Separator), Separator)...)
}
PathEscape leaves . unescaped (it is in the unreserved set), so .. segments survive into JoinPath, which resolves them. URI.Name() returns path.Base(path.Clean(path)) — the cleaned basename.
5. Upload checks ownership of the resolved ancestor and validates only the clean basename — pkg/filemanager/fs/dbfs/upload.go:
ancestor, err := f.getFileByPath(ctx, navigator, req.Props.Uri) // URI already traversal-normalized
...
if _, ok := ctx.Value(ByPassOwnerCheckCtxKey{}).(bool); !ok && ancestor.OwnerID() != f.user.ID {
return nil, fs.ErrOwnerOnly // same-user -> passes
}
...
if err := validateNewFile(req.Props.Uri.Name(), req.Props.Size, policy); err != nil { // checks "evil.docx" only
return nil, err
}
validateFileName rejects / \ : * ? " < > | and bare ./.. — but the traversal is already gone by the time it sees the basename.
Validation performed
Independent validation against commit 26b6b10 in a clean sandbox.
Source-verified (static): the full chain confirmed verbatim — single-file-scoped token (403 on mismatch) → PUT_RELATIVE dispatch → DirUri().JoinRaw(SuggestedTarget) → url.JoinPath normalization → ancestor ownership check (same-user passes) → basename-only validation of the cleaned name.
Dynamic (control-flow executed): the full binary is not buildable offline here (modules behind an unreachable Go proxy, embedded frontend, DB). I built and ran a harness using the real Go net/url stdlib plus the verbatim Join/JoinRaw/DirUri/Path/Name/PathEscape/shouldEscape and the validateFileName gate, driving the same transformation PUT_RELATIVE performs. Source = cloudreve://my/folder/current.docx:
SuggestedTarget resolved URI final basename validator
"copy.docx" cloudreve://my/folder/copy.docx "copy.docx" ACCEPT
"a/../../evil.docx" cloudreve://my/evil.docx "evil.docx" ACCEPT <- ESCAPED to /
"a/../../../top.docx" cloudreve://my/top.docx "top.docx" ACCEPT <- ESCAPED to /
"sub/evil.docx" cloudreve://my/folder/sub/evil.docx "evil.docx" ACCEPT <- different subdir
".pdf" cloudreve://my/folder/current.pdf "current.pdf" ACCEPT
"a%2f..%2f..%2fenc.docx" cloudreve://my/folder/a%252f..%252f.. "a%2f..%2f..%2f" ACCEPT (NO escape)
The headline payload a/../../evil.docx deterministically resolves to cloudreve://my/evil.docx (account root) with a clean, accepted basename. Output matches the original audit probe exactly. Honest caveat: a leading non-.. segment (e.g. a/) is required to prime the join; a single ../evil.docx does not cleanly escape, and URL-encoded separators (%2f) do not traverse through this path (they are re-escaped into one literal segment). Only literal / separators work.
Confidence tier: source-verified + control-flow dynamically reproduced (no full live HTTP write against a deployed instance).
Deduplication: no existing CVE/GHSA matches. Known Cloudreve advisories are CVE-2022-32167 (XSS, v1–v3.5.3) and CVE-2026-25726 (weak-PRNG ATO, instances initialized < v4.10.0) — both unrelated. SECURITY.md lists "user permissions" as high-impact and in scope for all 4.x, so this qualifies as a vulnerability under the project's own policy.
Steps to reproduce
Setup: user owns cloudreve://my/folder/current.docx; open it in the WOPI editor to obtain <token> (the session is bound to that file's ID).
- Send the crafted
PUT_RELATIVE: ``` POST /api/v4/file/wopi/?access_token= HTTP/1.1 Host: target X-WOPI-Override: PUT_RELATIVE X-WOPI-SuggestedTarget: Content-Type: application/octet-stream
``
2. Cloudreve rewrites the target fromcloudreve://my/folder/current.docxtocloudreve://my/evil.docx, validates the basenameevil.docx` (passes), and writes the content.
Expected: the target is rejected or constrained to the source file's directory.
Actual: a file is written at the account root, outside the token's single-file scope.
Impact
A WOPI access token scoped to one file can write files to other locations in the same user's account. A malicious or compromised WOPI integration (or a leaked token) can plant or, conditionally, overwrite files at attacker-chosen paths the account owns, defeating the per-file scoping the WOPI session is meant to enforce. Confined to the session user's account (not cross-user).
Remediation
- Treat
X-WOPI-SuggestedTarget(andX-WOPI-RequestedName) as a filename, not a path: reject/,\, dot segments, and percent-encoded separator variants before joining. - Prefer
DirUri().Join(sanitizedBaseName)overJoinRaw, and after constructing the target URI assert it is a direct child of the source file's directory. - Add regression tests for
a/../../evil.docx,sub/evil.docx, and encoded-separator variants.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/cloudreve/Cloudreve/v4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.0.0-20260613023150-7968e50429ef"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/cloudreve/Cloudreve/v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "3.0.0-20250225100611-da4e44b77af4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55495"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-24T20:41:16Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n \nCloudreve\u0027s WOPI `PUT_RELATIVE` handler treats `X-WOPI-SuggestedTarget` as a path, not a filename. It splits the header on `/` and joins the segments onto the source file\u0027s directory with `URI.JoinRaw`, which feeds Go\u0027s `url.JoinPath`. `url.JoinPath` resolves `.`/`..` segments, so a slash-bearing target such as `a/../../evil.docx` collapses to a location outside the source file\u0027s directory. The lower-level upload path then validates only the final, already-cleaned basename (`evil.docx`), which is harmless, and checks ownership against the *resolved ancestor* \u2014 which is still the same user\u0027s drive.\n \nA WOPI access token is bound to exactly one file (the route enforces `fileId == session.FileID` with a 403 otherwise). `PUT_RELATIVE` escapes that per-file scope: a token issued for one file can create (and, conditionally, overwrite) files elsewhere in the same account.\n\n## Root cause (verified at `26b6b10`)\n \n**1. Token is single-file scoped (the boundary being escaped)** \u2014 `middleware` `ViewerSessionValidation`:\n \n```go\nfileId := hashid.FromContext(c)\nif fileId != session.FileID { // 403 \u2014 token is bound to ONE file\n c.Status(http.StatusForbidden); c.Abort(); return\n}\n```\n \nRoute: `wopi := noAuth.Group(\"file/wopi\", middleware.HashID(hashid.FileID), middleware.ViewerSessionValidation())`; `wopi.POST(\":id\", controllers.ModifyFile)` \u2192 `POST /api/v4/file/wopi/:id?access_token=\u003ctoken\u003e`.\n \n**2. `PUT_RELATIVE` dispatch** \u2014 `routers/controllers/wopi.go`:\n \n```go\ncase wopi.MethodPutRelative: // X-WOPI-Override: PUT_RELATIVE\n err = service.PutContent(c, true)\n```\n \n**3. SuggestedTarget joined as a path** \u2014 `service/explorer/viewer.go`:\n \n```go\nfileName, _ := wopi.UTF7Decode(c.GetHeader(wopi.SuggestedTargetHeader)) // X-WOPI-SuggestedTarget\nfileUriParsed, _ := fs.NewUriFromString(fileUri)\nif strings.HasPrefix(fileName, \".\") { /* treat as extension */ }\nfileUri = fileUriParsed.DirUri().JoinRaw(fileName).String() // \u003c-- path join, not basename\n...\nsubService := FileUpdateService{ Uri: fileUri }\nres, err := subService.PutContent(c, lockSession)\n```\n \n**4. `JoinRaw` splits on `/` and normalizes via `url.JoinPath`** \u2014 `pkg/filemanager/fs/uri.go`:\n \n```go\nfunc (u *URI) Join(elem ...string) *URI {\n newUrl, _ := url.Parse(u.U.String())\n return \u0026URI{U: newUrl.JoinPath(/* PathEscape each elem */ ...)} // JoinPath cleans ./ and ../\n}\nfunc (u *URI) JoinRaw(elem string) *URI {\n return u.Join(strings.Split(strings.TrimPrefix(elem, Separator), Separator)...)\n}\n```\n \n`PathEscape` leaves `.` unescaped (it is in the unreserved set), so `..` segments survive into `JoinPath`, which resolves them. `URI.Name()` returns `path.Base(path.Clean(path))` \u2014 the cleaned basename.\n \n**5. Upload checks ownership of the resolved ancestor and validates only the clean basename** \u2014 `pkg/filemanager/fs/dbfs/upload.go`:\n \n```go\nancestor, err := f.getFileByPath(ctx, navigator, req.Props.Uri) // URI already traversal-normalized\n...\nif _, ok := ctx.Value(ByPassOwnerCheckCtxKey{}).(bool); !ok \u0026\u0026 ancestor.OwnerID() != f.user.ID {\n return nil, fs.ErrOwnerOnly // same-user -\u003e passes\n}\n...\nif err := validateNewFile(req.Props.Uri.Name(), req.Props.Size, policy); err != nil { // checks \"evil.docx\" only\n return nil, err\n}\n```\n \n`validateFileName` rejects `/ \\ : * ? \" \u003c \u003e |` and bare `.`/`..` \u2014 but the traversal is already gone by the time it sees the basename.\n\n## Validation performed\n \nIndependent validation against commit `26b6b10` in a clean sandbox.\n \n**Source-verified (static):** the full chain confirmed verbatim \u2014 single-file-scoped token (403 on mismatch) \u2192 `PUT_RELATIVE` dispatch \u2192 `DirUri().JoinRaw(SuggestedTarget)` \u2192 `url.JoinPath` normalization \u2192 ancestor ownership check (same-user passes) \u2192 basename-only validation of the cleaned name.\n \n**Dynamic (control-flow executed):** the full binary is not buildable offline here (modules behind an unreachable Go proxy, embedded frontend, DB). I built and ran a harness using the **real Go `net/url` stdlib** plus the **verbatim** `Join`/`JoinRaw`/`DirUri`/`Path`/`Name`/`PathEscape`/`shouldEscape` and the `validateFileName` gate, driving the same transformation `PUT_RELATIVE` performs. Source = `cloudreve://my/folder/current.docx`:\n \n```\nSuggestedTarget resolved URI final basename validator\n\"copy.docx\" cloudreve://my/folder/copy.docx \"copy.docx\" ACCEPT\n\"a/../../evil.docx\" cloudreve://my/evil.docx \"evil.docx\" ACCEPT \u003c- ESCAPED to /\n\"a/../../../top.docx\" cloudreve://my/top.docx \"top.docx\" ACCEPT \u003c- ESCAPED to /\n\"sub/evil.docx\" cloudreve://my/folder/sub/evil.docx \"evil.docx\" ACCEPT \u003c- different subdir\n\".pdf\" cloudreve://my/folder/current.pdf \"current.pdf\" ACCEPT\n\"a%2f..%2f..%2fenc.docx\" cloudreve://my/folder/a%252f..%252f.. \"a%2f..%2f..%2f\" ACCEPT (NO escape)\n```\n \nThe headline payload `a/../../evil.docx` deterministically resolves to `cloudreve://my/evil.docx` (account root) with a clean, accepted basename. Output matches the original audit probe exactly. Honest caveat: a leading non-`..` segment (e.g. `a/`) is required to prime the join; a single `../evil.docx` does not cleanly escape, and **URL-encoded separators (`%2f`) do not traverse** through this path (they are re-escaped into one literal segment). Only literal `/` separators work.\n \n**Confidence tier: source-verified + control-flow dynamically reproduced (no full live HTTP write against a deployed instance).**\n \n**Deduplication:** no existing CVE/GHSA matches. Known Cloudreve advisories are CVE-2022-32167 (XSS, v1\u2013v3.5.3) and CVE-2026-25726 (weak-PRNG ATO, instances initialized \u003c v4.10.0) \u2014 both unrelated. `SECURITY.md` lists \"user permissions\" as high-impact and in scope for all 4.x, so this qualifies as a vulnerability under the project\u0027s own policy.\n \n## Steps to reproduce\n \n**Setup:** user owns `cloudreve://my/folder/current.docx`; open it in the WOPI editor to obtain `\u003ctoken\u003e` (the session is bound to that file\u0027s ID).\n \n1. Send the crafted `PUT_RELATIVE`:\n ```\n POST /api/v4/file/wopi/\u003cfile-id\u003e?access_token=\u003ctoken\u003e HTTP/1.1\n Host: target\n X-WOPI-Override: PUT_RELATIVE\n X-WOPI-SuggestedTarget: \u003cUTF-7 of \"a/../../evil.docx\"\u003e\n Content-Type: application/octet-stream\n \n \u003cfile bytes\u003e\n ```\n2. Cloudreve rewrites the target from `cloudreve://my/folder/current.docx` to `cloudreve://my/evil.docx`, validates the basename `evil.docx` (passes), and writes the content.\n**Expected:** the target is rejected or constrained to the source file\u0027s directory.\n**Actual:** a file is written at the account root, outside the token\u0027s single-file scope.\n \n## Impact\n \nA WOPI access token scoped to one file can write files to other locations in the same user\u0027s account. A malicious or compromised WOPI integration (or a leaked token) can plant or, conditionally, overwrite files at attacker-chosen paths the account owns, defeating the per-file scoping the WOPI session is meant to enforce. Confined to the session user\u0027s account (not cross-user).\n \n## Remediation\n \n- Treat `X-WOPI-SuggestedTarget` (and `X-WOPI-RequestedName`) as a **filename**, not a path: reject `/`, `\\`, dot segments, and percent-encoded separator variants before joining.\n- Prefer `DirUri().Join(sanitizedBaseName)` over `JoinRaw`, and after constructing the target URI assert it is a direct child of the source file\u0027s directory.\n- Add regression tests for `a/../../evil.docx`, `sub/evil.docx`, and encoded-separator variants.",
"id": "GHSA-49h3-cwhj-4737",
"modified": "2026-07-24T20:41:16Z",
"published": "2026-07-24T20:41:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cloudreve/cloudreve/security/advisories/GHSA-49h3-cwhj-4737"
},
{
"type": "WEB",
"url": "https://github.com/cloudreve/cloudreve/commit/7968e50429efab40ffa8f57fecdfbd5a73d23630"
},
{
"type": "PACKAGE",
"url": "https://github.com/cloudreve/cloudreve"
},
{
"type": "WEB",
"url": "https://github.com/cloudreve/cloudreve/releases/tag/4.17.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Cloudreve: Path Traversal in WOPI PUT_RELATIVE Allows Arbitrary File Creation in Owner Account"
}
GHSA-49P4-PX3H-RQ49
Vulnerability from github – Published: 2026-06-22 20:15 – Updated: 2026-06-22 20:15Impact
When processing a build contexts or add/copy instructions, a malicious server serving a Git repository or a tar archive file can cause files outside of the build context directory to be included in the build context or copied into the build.
Patches
Fixed in Buildah 1.44 and 1.43.2.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/containers/buildah"
},
"ranges": [
{
"events": [
{
"introduced": "1.38.1"
},
{
"fixed": "1.43.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44517"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-22T20:15:48Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\nWhen processing a build contexts or `add`/`copy` instructions, a malicious server serving a Git repository or a tar archive file can cause files outside of the build context directory to be included in the build context or copied into the build.\n\n### Patches\n\nFixed in Buildah 1.44 and 1.43.2.",
"id": "GHSA-49p4-px3h-rq49",
"modified": "2026-06-22T20:15:48Z",
"published": "2026-06-22T20:15:48Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/containers/buildah/security/advisories/GHSA-49p4-px3h-rq49"
},
{
"type": "WEB",
"url": "https://github.com/podman-container-tools/buildah/security/advisories/GHSA-49p4-px3h-rq49"
},
{
"type": "PACKAGE",
"url": "https://github.com/podman-container-tools/buildah"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Build breakout using malicious Containerfile and Git Smart HTTP server or GitHub release tar archive"
}
GHSA-49R2-73M6-PP8F
Vulnerability from github – Published: 2021-04-19 14:51 – Updated: 2021-04-23 17:13Improper URL validation in development mode handler in com.vaadin:flow-server versions 2.0.0 through 2.4.1 (Vaadin 14.0.0 through 14.4.2), and 3.0 prior to 5.0 (Vaadin 15 prior to 18) allows attacker to request arbitrary files stored outside of intended frontend resources folder.
- https://vaadin.com/security/cve-2020-36321
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.vaadin:flow-server"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "5.0.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.vaadin:flow-server"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.4.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-36321"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-22"
],
"github_reviewed": true,
"github_reviewed_at": "2021-04-16T23:16:25Z",
"nvd_published_at": "2021-04-23T16:15:00Z",
"severity": "MODERATE"
},
"details": "Improper URL validation in development mode handler in `com.vaadin:flow-server` versions 2.0.0 through 2.4.1 (Vaadin 14.0.0 through 14.4.2), and 3.0 prior to 5.0 (Vaadin 15 prior to 18) allows attacker to request arbitrary files stored outside of intended frontend resources folder.\n\n- https://vaadin.com/security/cve-2020-36321",
"id": "GHSA-49r2-73m6-pp8f",
"modified": "2021-04-23T17:13:44Z",
"published": "2021-04-19T14:51:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vaadin/flow/security/advisories/GHSA-49r2-73m6-pp8f"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36321"
},
{
"type": "WEB",
"url": "https://github.com/vaadin/flow/pull/9392"
},
{
"type": "WEB",
"url": "https://vaadin.com/security/cve-2020-36321"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Directory traversal in development mode handler in Vaadin 14 and 15-17"
}
GHSA-49R7-W8P8-XGC3
Vulnerability from github – Published: 2022-05-17 04:12 – Updated: 2025-04-12 12:48Directory traversal vulnerability in UploadServlet in Novell ZENworks Configuration Management (ZCM) 10 and 11 before 11.3.2 allows remote attackers to execute arbitrary code via a crafted directory name in the uid parameter, in conjunction with a WAR filename in the filename parameter and WAR content in the POST data, a different vulnerability than CVE-2010-5323 and CVE-2010-5324.
{
"affected": [],
"aliases": [
"CVE-2015-0779"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2015-06-07T23:59:00Z",
"severity": "HIGH"
},
"details": "Directory traversal vulnerability in UploadServlet in Novell ZENworks Configuration Management (ZCM) 10 and 11 before 11.3.2 allows remote attackers to execute arbitrary code via a crafted directory name in the uid parameter, in conjunction with a WAR filename in the filename parameter and WAR content in the POST data, a different vulnerability than CVE-2010-5323 and CVE-2010-5324.",
"id": "GHSA-49r7-w8p8-xgc3",
"modified": "2025-04-12T12:48:30Z",
"published": "2022-05-17T04:12:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-0779"
},
{
"type": "WEB",
"url": "https://github.com/rapid7/metasploit-framework/pull/5096"
},
{
"type": "WEB",
"url": "https://raw.githubusercontent.com/pedrib/PoC/master/generic/zenworks_zcm_rce.txt"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/36964"
},
{
"type": "WEB",
"url": "https://www.novell.com/support/kb/doc.php?id=7016419"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2015/Apr/21"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-49RR-2FPG-HFW9
Vulnerability from github – Published: 2024-11-14 12:31 – Updated: 2024-11-14 12:31Avigilon – CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
{
"affected": [],
"aliases": [
"CVE-2024-45253"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-14T10:15:05Z",
"severity": "HIGH"
},
"details": "Avigilon \u2013 CWE-22: Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027)",
"id": "GHSA-49rr-2fpg-hfw9",
"modified": "2024-11-14T12:31:00Z",
"published": "2024-11-14T12:31:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45253"
},
{
"type": "WEB",
"url": "https://www.gov.il/en/Departments/faq/cve_advisories"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-49VX-VWJ9-Q95M
Vulnerability from github – Published: 2023-07-06 03:30 – Updated: 2024-04-04 05:24An issue in the com.nextev.datastatistic component of NIO EC6 Aspen before v3.3.0 allows attackers to escalate privileges via path traversal.
{
"affected": [],
"aliases": [
"CVE-2023-24256"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-06T02:15:09Z",
"severity": "HIGH"
},
"details": "An issue in the com.nextev.datastatistic component of NIO EC6 Aspen before v3.3.0 allows attackers to escalate privileges via path traversal.",
"id": "GHSA-49vx-vwj9-q95m",
"modified": "2024-04-04T05:24:15Z",
"published": "2023-07-06T03:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24256"
},
{
"type": "WEB",
"url": "https://github.com/hhj4ck/JailBreakEC6/blob/main/BugReport.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"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.