It has been found an Insecure Direct Object Reference (IDOR) vulnerability in the FileBrowser application's share deletion functionality. This vulnerability allows any authenticated user with share permissions to delete other users' shared links without authorization checks. The impact is significant as malicious actors can disrupt business operations by systematically removing shared files and links. This leads to denial of service for legitimate users, potential data loss in collaborative environments, and …
The standard library net/http package dependency used by File Browser improperly accepts a bare LF as a line terminator in chunked data chunk-size lines. I can permit request smuggling if a net/http server is used in conjunction with a server that incorrectly accepts a bare LF as part of a chunk-ext. See https://nvd.nist.gov/vuln/detail/CVE-2025-22871 for more details.
File Browser’s authentication system issues long-lived JWT tokens that remain valid even after the user logs out. Please refer to the CWE's listed in this report for further reference and system standards. In summary, the main issue is: Tokens remain valid after logout (session replay attacks) In this report, I used docker as the documentation instruct: docker run \ -v filebrowser_data:/srv \ -v filebrowser_database:/database \ -v filebrowser_config:/config \ -p 8080:80 …
A Denial of Service (DoS) vulnerability exists in the file processing logic when reading a file on endpoint Filebrowser-Server-IP:PORT/files/{file-name} . While the server correctly handles and stores uploaded files, it attempts to load the entire content into memory during read operations without size checks or resource limits. This allows an authenticated user to upload a large file and trigger uncontrolled memory consumption on read, potentially crashing the server and making …
Files managed by the File Browser can be shared with a link to external persons. While the application allows protecting those links with a password, the implementation is error-prone, making an incidental unprotected sharing of a file possible.
In the web application, all users have a scope assigned, and they only have access to the files within that scope. The Command Execution feature of Filebrowser allows the execution of shell commands which are not restricted to the scope, potentially giving an attacker read and write access to all files managed by the server.
All user accounts authenticate towards a File Browser instance with a password. A missing password policy and brute-force protection makes it impossible for administrators to properly secure the authentication process.
The Command Execution feature of Filebrowser only allows the execution of shell command which have been predefined on a user-specific allowlist. The implementation of this allowlist is erroneous, allowing a user to execute additional commands not permitted.
URLs that are accessed by a user are commonly logged in many locations, both server- and client-side. It is thus good practice to never transmit any secret information as part of a URL. The Filebrowser violates this practice, since access tokens are used as GET parameters.
The file access permissions for files uploaded to or created from File Browser are never explicitly set by the application. The same is true for the database used by File Browser. On standard servers where the umask configuration has not been hardened before, this makes all the stated files readable by any operating system account.
The Markdown preview function of File Browser v2.32.0 is vulnerable to Stored Cross-Site-Scripting (XSS). Any JavaScript code that is part of a Markdown file uploaded by a user will be executed by the browser
The Command Execution feature of File Browser only allows the execution of shell command which have been predefined on a user-specific allowlist. Many tools allow the execution of arbitrary different commands, rendering this limitation void.