PT-2026-35297 · Npm · Psitransfer

Published

2026-04-16

·

Updated

2026-04-16

CVSS v3.1

7.5

High

VectorAV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H

Summary

The 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.

Details

Observed 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.
The 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.
The 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.
On 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.

PoC

  1. 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.
  2. Send a PATCH request directly to the upload endpoint:
http
PATCH /files/..%2Fconfig.production.js HTTP/1.1
Host: target
Tus-Resumable: 1.0.0
Upload-Offset: 0
Content-Type: application/offset+octet-stream

module.exports = {}; require('fs').writeFileSync('/tmp/psitransfer-rce-proof', 'owned');
  1. Observe that the response is 404 Not Found, but /opt/psitransfer/config.production.js is created and contains the attacker-controlled payload.
  2. Restart the PsiTransfer process, or wait for the next routine restart under the same NODE ENV.
  3. Observe that /tmp/psitransfer-rce-proof is created during startup, confirming server-side JavaScript execution from the injected config.production.js.

Impact

The 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.

Fix

Path traversal

Found an issue in the description? Have something to add? Feel free to write us 👾
dbugs@ptsecurity.com

Weakness Enumeration

CWE-22

Related Identifiers

GHSA-533Q-W4G6-5586

Affected Products

Psitransfer