Skip to content

[SECURITY] Critical Path Traversal (CWE-22) in FileStorageService #1363

@pulkit1245

Description

@pulkit1245

Vulnerability Description

While auditing the codebase, I discovered a Path Traversal vulnerability (CWE-22) in FileStorageService.java.

The methods storeFile, loadFileAsResource, deleteFile, and getFile resolve file paths using user-supplied input (such as filePath or category). Although the service calls .normalize() on the paths, it fails to verify whether the final resolved path remains within the intended fileStorageLocation directory.

Because Path.resolve() combined with normalize() can resolve relative directory traversals (e.g., ../), an attacker can craft payloads that break out of the upload directory, allowing them to access, write, or delete arbitrary files on the host filesystem that the Java process has access to.

I am participating in GSSoC '26 and would like to be assigned this issue. I already have a fix ready that enforces a .startsWith(this.fileStorageLocation) boundary check.

Impact

This vulnerability has a critical impact on the system:

  1. Information Disclosure: An attacker could exploit the loadFileAsResource() endpoint to read arbitrary files from the server, such as /etc/passwd, ssh keys, or internal configuration files containing secrets.
  2. Data Deletion: The deleteFile() method could be abused to delete critical system files or other users' legal documents.
  3. Remote Code Execution (RCE) / System Compromise: Through storeFile(), an attacker could write a malicious file to an arbitrary location (e.g., overwriting a script, adding an SSH authorized key, or dropping a web shell in a public directory), potentially leading to complete server compromise.

Reproduction Steps

  1. Identify any API endpoint that utilizes FileStorageService.loadFileAsResource(filePath).
  2. Send a request to this endpoint with a payload containing traversal sequences, for example: ../../../../../../../../etc/passwd or ..%2F..%2F..%2F..%2Fetc%2Fpasswd depending on URL encoding requirements.
  3. The server resolves this path starting from the upload directory, normalizes it backwards to the system root, and then attempts to read the passwd file.
  4. The server returns the contents of /etc/passwd instead of a 404 error, proving that it has traversed outside the intended storage boundary.

Severity Level

Critical

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions