Summary

The POST /delete endpoint uses a user-controlled filename value to construct a filesystem path and deletes it via unlink without sufficient validation. By supplying path traversal sequences (e.g., ../), an attacker can delete arbitrary files outside the intended uploads directory, limited only by the permissions of the server process.

Details

Vulnerability type: Path Traversal leading to Arbitrary File Deletion

Data flow (high level):

• Source: filename from the JSON body of POST /delete
• Sink: fs.unlink(<userUploadsDir> + <filename>) (or equivalent concatenation/interpolation)
• Issue: No canonicalization / allowlisting / boundary check is performed on filename. Inputs containing traversal sequences (e.g., ../../..) can cause the resolved path to point outside userUploadsDir, enabling deletion of arbitrary files.

Preconditions observed during testing:

• A valid authenticated session was used, and a jobId cookie was present.
• The request succeeded when jobId was set to 1 in the request, suggesting the value may be trusted directly from the client.

PoC

Validated on a local instance. The following steps demonstrate deleting a file outside the uploads directory (example: /tmp/test inside Docker/container).

1. Create a test file in the container/host environment (example shown conceptually):

   • Create /tmp/test (e.g., touch /tmp/test)

2. Log in to obtain session cookies:

    curl -i -c cookies.txt -L \
      -X POST http://localhost:3000/login \
      -d "email=test@test.pl&password=1qaz@WSX"

3. Trigger deletion via path traversal:

    curl -b cookies.txt -b "jobId=1" \
      -H "Content-Type: application/json" \
      -X POST http://localhost:3000/delete \
      -d '{"filename":"../../../../../../../../tmp/test"}'

Expected result:

• The server performs unlink() on the resolved path and /tmp/test is removed (assuming the server process has permission).

Impact

An authenticated attacker (or any attacker able to reach POST /delete and satisfy/bypass its session requirements) can delete arbitrary files accessible to the server process. This can cause:

• Integrity impact: deletion of application data, configuration, or other files
• Availability impact: service disruption or permanent data loss (e.g., deleting DB files, uploaded content, logs, etc.)

The practical impact depends on the deployment’s filesystem permissions and containerization, but the issue is inherently high risk due to arbitrary file deletion capability.