If you run your own private file-sharing server to avoid sending sensitive documents through Dropbox or Google Drive, there is a chance an anonymous stranger on the internet can quietly rewrite that server's brain — and you would never know until it was too late.
Who Should Be Worried
PsiTransfer is a popular open-source alternative to commercial file-sharing services, favored by privacy-conscious individuals, small businesses, legal teams, journalists, and IT departments who want to keep sensitive file transfers on infrastructure they control. It runs on virtually any operating system and is deployed using Docker, making it a common choice for self-hosted home labs and internal corporate tools alike.
The project has tens of thousands of Docker pulls and is actively recommended across self-hosting communities on Reddit, GitHub, and Hacker News. While there are no official figures on total deployments, the combination of its ease of setup and growing distrust of cloud providers means real-world exposure is significant. Any deployment running a version older than 2.4.3 — released in response to this vulnerability — is potentially at risk.
The practical impact is severe: a successful attacker gains the ability to run any code they want on your server, under the same permissions as the application itself. That means stolen files, backdoors, ransomware, or silent surveillance of everything passing through your private file-sharing system.
How the Attack Works — No Jargon Required
Imagine a locked mailroom where the guard checks your badge by reading the name tag on your jacket — but the person sorting packages in the back room reads the name sewn inside the collar. If you wear a jacket that says Security on the outside but has Executive Suite stitched inside, you can fool the guard while the package ends up somewhere it should never go. That is essentially what this vulnerability allows.
PsiTransfer lets users upload files in chunks, a common technique for handling large files reliably. To do this, it exposes a web address — a URL — where upload chunks can be sent. The application's security check reads the URL in one way (its encoded form, where special characters like slashes are written as %2F), and sees nothing suspicious. But the part of the software that actually writes the file to disk decodes that URL first, turning %2F back into a real slash — and suddenly the file path points somewhere completely different than intended. With the right sequence of characters in the URL, an attacker can walk right out of the designated upload folder and write a file anywhere the application has permission to touch.
Here is where it gets genuinely alarming. If the server has been configured — as many deployments are — with an upload folder whose name begins with conf, the attacker can use this trick to drop a file called config.production.js directly into the application's root directory. PsiTransfer is built on Node.js, and Node.js automatically loads that configuration file every time the application starts. The attacker just has to wait for a routine server restart, a scheduled maintenance window, or even trigger a crash themselves — and their code runs with the full authority of the application. No password. No account. No trace in the login logs, because there was never a login.
The Technical Detail That Matters
Security researchers will recognize this as a path traversal via URL-decoding inconsistency — specifically, a mismatch between the encoded req.path used for validation and the decoded req.params.uploadId used by the downstream tus protocol handler for the actual file write operation. This class of vulnerability — where security controls and execution engines consume the same input through different parsing pipelines — is notoriously difficult to catch in code review and is increasingly common in applications that layer protocol handlers on top of framework routing. The flaw carries a CVSS score of 7.5 (HIGH) and requires zero authentication to exploit.
Has Anyone Been Attacked Yet?
As of the time of writing, there is no confirmed evidence of active exploitation in the wild. The vulnerability was responsibly disclosed and a patched version was published before widespread public technical details were released, which is the best-case scenario for defenders. The flaw was discovered and reported through PsiTransfer's GitHub security advisory process, and the maintainers acted swiftly to issue version 2.4.3.
However, "not exploited yet" is a shrinking window, not a clean bill of health. Vulnerabilities of this class — unauthenticated file write leading to code execution — are exactly the kind that automated scanning tools and opportunistic threat actors pick up within days of public disclosure. The combination of a self-hosted privacy tool (whose users may be less likely to monitor security bulletins closely) and a no-authentication-required exploit makes this a target with a particular appeal for attackers looking for persistent footholds in private infrastructure.
What You Need to Do Right Now
-
Update to PsiTransfer version 2.4.3 immediately. This is the patched release. If you are running via Docker, pull the latest image (
docker pull psitrax/psitransfer:latest) and restart your container. If you installed from source, check out thev2.4.3tag from the official GitHub repository and redeploy. Do this before anything else. -
Audit your upload directory configuration. Check your environment variables or config file for the value of
PSITRANSFER_UPLOAD_DIR. If the final folder name in that path starts with the lettersconf— for example, a path ending in/conf,/configs, or/configuration— your deployment was in the highest-risk category for this specific attack. Inspect your application root directory for any unexpected.jsfiles, particularly anything namedconfig.production.js,config.development.js, or similar. If you find anything suspicious, treat your server as compromised and rotate all credentials that application had access to. - Restrict network access to your PsiTransfer instance if a full update is not immediately possible. Place the application behind a VPN, firewall rule, or reverse proxy with IP allowlisting so that only trusted users can reach the upload endpoint. This does not fix the vulnerability but it eliminates anonymous internet access — meaning an attacker would have to already be inside your network to exploit it. This is a temporary measure only. The update is the only real fix.