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:
- 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.
- Data Deletion: The
deleteFile() method could be abused to delete critical system files or other users' legal documents.
- 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
- Identify any API endpoint that utilizes
FileStorageService.loadFileAsResource(filePath).
- 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.
- 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.
- 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
Vulnerability Description
While auditing the codebase, I discovered a Path Traversal vulnerability (CWE-22) in
FileStorageService.java.The methods
storeFile,loadFileAsResource,deleteFile, andgetFileresolve file paths using user-supplied input (such asfilePathorcategory). Although the service calls.normalize()on the paths, it fails to verify whether the final resolved path remains within the intendedfileStorageLocationdirectory.Because
Path.resolve()combined withnormalize()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:
loadFileAsResource()endpoint to read arbitrary files from the server, such as/etc/passwd, ssh keys, or internal configuration files containing secrets.deleteFile()method could be abused to delete critical system files or other users' legal documents.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
FileStorageService.loadFileAsResource(filePath).../../../../../../../../etc/passwdor..%2F..%2F..%2F..%2Fetc%2Fpasswddepending on URL encoding requirements.passwdfile./etc/passwdinstead of a 404 error, proving that it has traversed outside the intended storage boundary.Severity Level
Critical