FileBrowser is an open-source web file manager that lets teams upload, delete, preview, and edit files in a specific directory from the browser. With over 32,000 stars and 3,600 forks on GitHub, it’s a popular choice for self-hosted setups where teams want tight control over their data stack, including many Web3 builders.
As part of a routine internal review (Hacken uses FileBrowser for several internal services), dApp auditor Bogdan Bodisteanu identified a critical authorization flaw in FileBrowser’s share deletion logic. The issue is now tracked as CVE-2025-64523 with a High (7.2) CVSS score and affects versions prior to 2.45.1.
How Bogdan Discovered CVE-2025-64523
Because FileBrowser sits in Hacken’s internal stack, the security review focused on access control around actions that modify or delete resources. The goal was simple: make sure that tools plugged into our infrastructure respect strict authorization boundaries.
Bogdan used a white-box approach, walking through the source code of critical access control paths. In particular, he traced how the application handled one sensitive piece of user input: the share ID hash that identifies shared links.
Following that input path led directly to the share deletion handler. There, Bogdan found that FileBrowser trusted the hash alone and did not verify who actually owned the share before deleting it. That missing ownership check is what ultimately became CVE-2025-64523.
Technical Review and Findings
The core issue was isolated to the /http/share.go file, specifically within the shareDeleteHandler function. The function processes requests to delete a shared link by consuming only the unique share hash from the request path.
Hacken’s analysis confirmed:
- A critical authorization bypass vulnerability in the share deletion logic. The handler executes the d.store.Share.Delete(hash) operation without first performing a validation step to ensure that the link.UserID associated with the provided hash matches the ID (d.user.ID) of the currently authenticated user.
- Missing Object-Level Access Control (OLAC): By failing to implement this mandatory authorization check, the system implicitly grants any authenticated user with basic share permissions the ability to delete any existing share link, regardless of ownership.
This results in a severe failure in access control enforcement, violating the principle of least privilege, which is necessary for secure multi-user environments.
Real-World Impact for Teams Using FileBrowser
This vulnerability is high-impact because it compromises data availability and collaboration within the application:
- Disruption of Shared Data Access: Unauthorized deletion of shared links causes an immediate loss of access to shared resources for legitimate users. This action severely disrupts ongoing projects and collaborative workflows, and could plausibly act as a denial-of-service attack on shared services.
- Compromised Collaboration and Data Accessibility: The unexpected removal of critical shared links (e.g., reports, logs, runbooks) results in teams losing necessary context. This significantly slows down collaboration and can temporarily compromise the availability of time-sensitive or regulatory-mandated data.
- Violation of Least Privilege: By enabling a standard user with basic share permissions to delete shares created by other users, the vulnerability allows unauthorized destructive capability against resources they do not own. This fundamental failure in Object-Level Access Control (OLAC) violates the principle of least privilege, which is essential for secure multi-user environments.
For Web3 teams that use FileBrowser to share node logs, validator configs, incident reports, or compliance documents, this kind of bug can quietly undermine incident response and operational reliability at the worst possible time.
How the FileBrowser Team Fixed It
The vulnerability was promptly communicated with detailed remediation guidance to the FileBrowser development team. The fix was implemented by adding the necessary Object-Level Access Control (OLAC).
Specifically, the shareDeleteHandler function was updated to first retrieve the share link based on the provided hash and then verify that the link.UserID matches the ID of the authenticated user making the deletion request. If the IDs do not match, the request is rejected with an authorisation error.
This change restores the expected guarantee: only the rightful owner (or an administrator) can delete a shared link.
If you run FileBrowser, you should update to version 2.45.1 or later as soon as possible. Versions prior to 2.45.1 are vulnerable to this authorization bypass.
Lessons for Web3 Builders
While FileBrowser itself isn’t a Web3 protocol, the pattern behind CVE-2025-64523 is very common in Web3 stacks:
- Admin panels for smart contracts and validators.
- Internal dashboards for transaction monitoring or risk scoring.
- Self-hosted tools used by exchanges, wallets, and infrastructure providers.
In all of these, a “delete by ID/hash” endpoint that doesn’t validate ownership is one missed check away from becoming an Insecure Direct Object Reference (IDOR).
The core lesson is simple: a cryptographic-looking identifier (hash, UUID, etc.) is not an access control mechanism. Ownership validation must still happen server-side on every state-changing operation.
Access Control Hygiene Checklist
- Always validate ownership: Whenever an action is performed on an object (read, write, delete), the server must explicitly check if the requesting user is the owner of that object before executing the action.
- Do not trust client input: Never rely on the client or the unique identifier (e.g., hash or ID) alone for authorization. The check must be performed server-side by comparing the resource owner's ID with the session user's ID.
- Audit delete and edit functions: Focus security audits specifically on functions that modify or destroy data, as these are the most common vectors for destructive IDOR and authorization bypass flaws.
- Extend this to third-party tools: Internal tools you self-host (like FileBrowser) are still part of your attack surface. Track their CVEs and review their access control logic, especially for destructive actions.
Conclusion
CVE-2025-64523 is a clear reminder that IDs and hashes are not a substitute for authorization checks. Even in mature, widely used open-source projects, a single missing ownership validation can give regular users destructive powers over other users’ data.
If someone ran the same playbook Bogdan used on your stack today – mapping “delete/update by ID” endpoints and trying cross-user operations – what would they find?
About Bogdan Bodisteanu
Bogdan is an ethical hacker with over eight years of field experience. Since 2022, he has performed multiple penetration tests and security audits for decentralized applications at Hacken. He is credited as the reporter for CVE-2025-64523 in the GitHub Advisory Database.
About Hacken
Hacken is an end-to-end blockchain security and compliance partner for digital asset businesses. The team combines deep Web3 expertise with enterprise-grade security practices and globally recognized certifications to help projects secure smart contracts, infrastructure, and operations.
