Skip to content

Commit d8eb64e

Browse files
1 parent 4c982a9 commit d8eb64e

2 files changed

Lines changed: 110 additions & 0 deletions

File tree

Lines changed: 55 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,55 @@
1+
{
2+
"schema_version": "1.4.0",
3+
"id": "GHSA-533q-w4g6-5586",
4+
"modified": "2026-04-16T21:13:40Z",
5+
"published": "2026-04-16T21:13:40Z",
6+
"aliases": [],
7+
"summary": "PsiTransfer: Upload PATCH path traversal can create `config.<NODE_ENV>.js` and lead to code execution on restart",
8+
"details": "### Summary\n\nThe upload PATCH flow under `/files/:uploadId` validates the mounted request path using the still-encoded `req.path`, but the downstream tus handler later writes using the decoded `req.params.uploadId`. In deployments that use a supported custom `PSITRANSFER_UPLOAD_DIR` whose basename prefixes a startup-loaded JavaScript path, such as `conf`, an unauthenticated attacker can create `config.<NODE_ENV>.js` in the application root. The attacker-controlled file is then executed on the next process restart.\n\n### Details\n\nObserved in `2.4.1`, the upload middleware derives `fid` from `req.path.substring(1)` and calls `store.info(fid)` before handing the request to tus. For a request such as `/files/..%2Fconfig.production.js`, this outer check sees the encoded value `..%2Fconfig.production.js`. The downstream `patch('/:uploadId')` route, however, receives the decoded parameter `../config.production.js`. In the same code path, the `catch` branch uses `if(! e instanceof httpErrors.NotFound)`, which does not correctly stop execution on a missing upload target.\n\nThe write sink is `Store.getFilename(fid)`, which resolves `path.resolve(uploadDir, fid.replace('++', '/'))` and then only checks `startsWith(uploadDir)`. With a supported custom upload directory such as `<app_root>/conf`, the decoded target `../config.production.js` resolves to `<app_root>/config.production.js`, and the current string-prefix jail check still accepts it because the resolved path begins with `<app_root>/conf`.\n\nThe file creation is observable even when the request ends in failure. `store.append()` creates the target write stream first and only consults the JSON sidecar in the `finish` handler. As a result, `PATCH /files/..%2Fconfig.production.js` returns `404 Not Found` in my test, but still leaves an attacker-controlled `config.production.js` on disk.\n\nOn the next start, `config.js` executes `require(path.resolve(__dirname, \\`config.${process.env.NODE_ENV}.js\\`))` when the file exists. I verified this in a temporary copy of the application by setting `NODE_ENV=production` and `PSITRANSFER_UPLOAD_DIR` to a custom `conf` directory, sending a single PATCH request that wrote JavaScript into `config.production.js`, and then restarting the process. The attacker code executed during startup and created a proof file. Until a fix exists, the shortest safe workaround is to reject PATCH requests unless the expected sidecar metadata already exists and to avoid upload directory names that can prefix startup-loaded paths under the application root.\n\n### PoC\n\n1. Start PsiTransfer `2.4.1` from source with `NODE_ENV=production` and a supported custom upload directory whose basename prefixes a startup-loaded file path, for example `PSITRANSFER_UPLOAD_DIR=/opt/psitransfer/conf`.\n2. Send a PATCH request directly to the upload endpoint:\n\n```http\nPATCH /files/..%2Fconfig.production.js HTTP/1.1\nHost: target\nTus-Resumable: 1.0.0\nUpload-Offset: 0\nContent-Type: application/offset+octet-stream\n\nmodule.exports = {}; require('fs').writeFileSync('/tmp/psitransfer-rce-proof', 'owned');\n```\n\n3. Observe that the response is `404 Not Found`, but `/opt/psitransfer/config.production.js` is created and contains the attacker-controlled payload.\n4. Restart the PsiTransfer process, or wait for the next routine restart under the same `NODE_ENV`.\n5. Observe that `/tmp/psitransfer-rce-proof` is created during startup, confirming server-side JavaScript execution from the injected `config.production.js`.\n\n### Impact\n\nThe observed result is unauthenticated creation of an attacker-controlled startup configuration file outside the intended upload directory. In affected deployments, this becomes code execution with the PsiTransfer service account on the next process restart, allowing full compromise of the application's confidentiality, integrity, and availability within that execution context. Default Docker and default source/systemd examples did not satisfy the RCE precondition in my review because their documented upload directory names do not prefix startup-loaded paths, but the vulnerable logic is still reachable.",
9+
"severity": [
10+
{
11+
"type": "CVSS_V3",
12+
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H"
13+
}
14+
],
15+
"affected": [
16+
{
17+
"package": {
18+
"ecosystem": "npm",
19+
"name": "psitransfer"
20+
},
21+
"ranges": [
22+
{
23+
"type": "ECOSYSTEM",
24+
"events": [
25+
{
26+
"introduced": "0"
27+
},
28+
{
29+
"fixed": "2.4.3"
30+
}
31+
]
32+
}
33+
]
34+
}
35+
],
36+
"references": [
37+
{
38+
"type": "WEB",
39+
"url": "https://github.com/psi-4ward/psitransfer/security/advisories/GHSA-533q-w4g6-5586"
40+
},
41+
{
42+
"type": "PACKAGE",
43+
"url": "https://github.com/psi-4ward/psitransfer"
44+
}
45+
],
46+
"database_specific": {
47+
"cwe_ids": [
48+
"CWE-22"
49+
],
50+
"severity": "HIGH",
51+
"github_reviewed": true,
52+
"github_reviewed_at": "2026-04-16T21:13:40Z",
53+
"nvd_published_at": null
54+
}
55+
}
Lines changed: 55 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,55 @@
1+
{
2+
"schema_version": "1.4.0",
3+
"id": "GHSA-hf5p-q87m-crj7",
4+
"modified": "2026-04-16T21:14:33Z",
5+
"published": "2026-04-16T21:14:33Z",
6+
"aliases": [],
7+
"summary": "Junrar: Path Traversal (Zip-Slip) via Sibling Directory Name Prefix",
8+
"details": "### Summary\n\nA path traversal vulnerability in `LocalFolderExtractor` allows an attacker to write arbitrary files with attacker-controlled content into sibling directories when a crafted RAR archive is extracted.\n\n### Example\n\nGiven an extraction directory set to `/tmp/extract`, a crafted archive with an entry with the filename as `../extract_evil/file.txt` would be actually extracted to `/tmp/extract_evil/file.txt`.\n\n### Details\n\nThe `createDirectory()` and `createFile()` methods in`LocalFolderExtractor` validate extraction paths using a string prefix.",
9+
"severity": [
10+
{
11+
"type": "CVSS_V3",
12+
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N"
13+
}
14+
],
15+
"affected": [
16+
{
17+
"package": {
18+
"ecosystem": "Maven",
19+
"name": "com.github.junrar:junrar"
20+
},
21+
"ranges": [
22+
{
23+
"type": "ECOSYSTEM",
24+
"events": [
25+
{
26+
"introduced": "0"
27+
},
28+
{
29+
"fixed": "7.5.10"
30+
}
31+
]
32+
}
33+
]
34+
}
35+
],
36+
"references": [
37+
{
38+
"type": "WEB",
39+
"url": "https://github.com/junrar/junrar/security/advisories/GHSA-hf5p-q87m-crj7"
40+
},
41+
{
42+
"type": "PACKAGE",
43+
"url": "https://github.com/junrar/junrar"
44+
}
45+
],
46+
"database_specific": {
47+
"cwe_ids": [
48+
"CWE-22"
49+
],
50+
"severity": "MODERATE",
51+
"github_reviewed": true,
52+
"github_reviewed_at": "2026-04-16T21:14:33Z",
53+
"nvd_published_at": null
54+
}
55+
}

0 commit comments

Comments
 (0)