fix(decryptpdf): prevent path traversal in multer filename callback

[sebastiondev]

Vulnerability Summary

The /decryptpdf endpoint in apps/OpenSignServer/cloud/customRoute/decryptpdf.js is vulnerable to path traversal (CWE-22) through the file.originalname field in the multer diskStorage configuration.

When a file is uploaded via POST /decryptpdf, multer's diskStorage callback uses file.originalname directly as the filename:

filename(req, file, cb) {
    cb(null, file.originalname);
}

The originalname property is taken directly from the Content-Disposition header in the multipart upload and is fully attacker-controlled. An attacker can set it to a value like ../../malicious.js to write files outside the intended exports directory, potentially overwriting application code, configuration files, or other sensitive data on the server.

The /decryptpdf route is mounted in customApp.js without any authentication middleware — the Express app uses only cors() and body parsers, with no auth gates on this route. This means the vulnerability is exploitable by any unauthenticated client with network access to the server.

Severity: High — unauthenticated arbitrary file write.

Proof of Concept

An attacker can upload a file with a traversal payload in the filename to write outside the exports directory:

curl -X POST http://localhost:8080/decryptpdf \
  -F "file=@test.pdf;filename=../../overwrite-target.txt" \
  -F "password=anything"

This causes multer to write the uploaded content to exports/../../overwrite-target.txt, which resolves to overwrite-target.txt two directories above the exports folder. Depending on the deployment layout, this can overwrite application source files, .env configuration, package.json, or other files the Node.js process user has write access to.

The route is defined at apps/OpenSignServer/cloud/customRoute/customApp.js:19:

app.post('/decryptpdf', decryptUpload.single('file'), decryptpdf);

Fix Description

The fix wraps file.originalname in path.basename() to strip any directory components:

cb(null, path.basename(file.originalname));

path.basename() extracts only the final filename segment, so ../../malicious.js becomes malicious.js, and the file is written into the intended exports directory. This is the standard Node.js mitigation for this class of vulnerability and has no impact on legitimate uploads, since valid filenames contain no directory separators.

Testing

• Verified that path.basename('../../etc/passwd') returns 'passwd' (directory components stripped).
• Verified that path.basename('normal-file.pdf') returns 'normal-file.pdf' (no change for clean filenames).
• Confirmed the fix does not alter the rest of the decryptpdf logic — only the filename callback is modified.
• The change is minimal: one new import (path from node:path) and one wrapped call.

Adversarial Review

Before submitting, we considered whether existing protections would prevent exploitation. The Express app in customApp.js applies no authentication middleware — only cors() and body parsers — so the endpoint is reachable by any network client. Multer does not sanitize originalname by design (it documents this as the caller's responsibility). The exports destination directory is a relative path, making traversal straightforward. No other server-side validation or sandboxing prevents the file write. The vulnerability is exploitable as described.

---

_{Submitted by Sebastion — autonomous open-source security research from Foundation Machines. Free for public repos via the Sebastion AI GitHub App.}

[vercel]

@sebastiondev is attempting to deploy a commit to the prafull 's projects Team on Vercel.

A member of the Team first needs to authorize it.