Summary
FileRise fails to properly authorize uploads when the destination filename already exists, allowing a new upload to silently replace the existing file. The issue can affect visitors using valid upload-enabled share links, as well as authenticated users whose upload permissions do not include editing the existing file.
FileRise fails to properly authorize uploads when the destination filename already exists, allowing a new upload to silently replace the existing file. The issue can affect visitors using valid upload-enabled share links, as well as authenticated users whose upload permissions do not include editing the existing file.
Affected context
The vulnerability occurs in FileRise deployments before the issue was fixed, when upload-enabled shared folders, upload-only links, or authenticated upload endpoints accept a filename that matches an existing file. It is particularly risky where users can upload content but are not intended to modify files already stored in the destination, because the upload operation may bypass the authorization boundary associated with the existing file.
The vulnerability occurs in FileRise deployments before the issue was fixed, when upload-enabled shared folders, upload-only links, or authenticated upload endpoints accept a filename that matches an existing file. It is particularly risky where users can upload content but are not intended to modify files already stored in the destination, because the upload operation may bypass the authorization boundary associated with the existing file.
Exploit preconditions
- Attack surface: Web-based file upload functionality, including shared-folder links, upload-only links, and authenticated upload endpoints.
- Required access: An unauthenticated visitor needs a valid share token and any configured share password; ordinary authenticated uploads require an account with upload access.
- Trigger point: Submitting an upload whose destination filename matches an existing file.
- Why exploitation is possible: The upload workflow does not reliably reject filename collisions or enforce authorization to replace the existing file, allowing upload permission to function as overwrite permission.
- Attack surface: Web-based file upload functionality, including shared-folder links, upload-only links, and authenticated upload endpoints.
- Required access: An unauthenticated visitor needs a valid share token and any configured share password; ordinary authenticated uploads require an account with upload access.
- Trigger point: Submitting an upload whose destination filename matches an existing file.
- Why exploitation is possible: The upload workflow does not reliably reject filename collisions or enforce authorization to replace the existing file, allowing upload permission to function as overwrite permission.
Why this happens
The underlying defect is a missing authorization check, mapped to CWE-862: Missing Authorization. The application validates whether a requester may upload to a location but does not consistently evaluate whether that requester is authorized to replace the specific file already present at the destination. Treating a filename collision as an ordinary upload rather than a separate, privileged modification operation creates an insecure authorization boundary and can preserve misleading original uploader metadata.
The underlying defect is a missing authorization check, mapped to CWE-862: Missing Authorization. The application validates whether a requester may upload to a location but does not consistently evaluate whether that requester is authorized to replace the specific file already present at the destination. Treating a filename collision as an ordinary upload rather than a separate, privileged modification operation creates an insecure authorization boundary and can preserve misleading original uploader metadata.
Potential impact
- An attacker may replace the contents of an existing file without the owner's editing authority.
- Stored documents, shared resources, or operational data could be altered or destroyed.
- Users may consume tampered content while seeing metadata associated with the original uploader.
- File integrity, collaboration workflows, and audit assumptions could be undermined.
- Repeated overwrites could support denial of service or data poisoning scenarios.
- An attacker may replace the contents of an existing file without the owner's editing authority.
- Stored documents, shared resources, or operational data could be altered or destroyed.
- Users may consume tampered content while seeing metadata associated with the original uploader.
- File integrity, collaboration workflows, and audit assumptions could be undermined.
- Repeated overwrites could support denial of service or data poisoning scenarios.
General mitigation guidance
Mitigation generally focuses on treating replacement as a distinct, authorized action rather than as a normal upload.
Common defensive patterns include:
- Rejecting destination filename collisions by default unless explicit replacement authority is present.
- Performing object-level authorization checks against the existing file before any overwrite operation.
- Separating upload, create, edit, and replace permissions in the authorization model.
- Using server-side canonical identifiers and controlled rename behavior rather than trusting client-provided filenames.
- Preserving reliable audit records for replacement attempts and successful modifications.
- Applying least privilege to shared-link and upload-only identities, including write-only or create-only semantics where appropriate.
- Making collision handling secure by default and requiring an explicit, authorized workflow for replacement.
Mitigation generally focuses on treating replacement as a distinct, authorized action rather than as a normal upload.
Common defensive patterns include:
- Rejecting destination filename collisions by default unless explicit replacement authority is present.
- Performing object-level authorization checks against the existing file before any overwrite operation.
- Separating upload, create, edit, and replace permissions in the authorization model.
- Using server-side canonical identifiers and controlled rename behavior rather than trusting client-provided filenames.
- Preserving reliable audit records for replacement attempts and successful modifications.
- Applying least privilege to shared-link and upload-only identities, including write-only or create-only semantics where appropriate.
- Making collision handling secure by default and requiring an explicit, authorized workflow for replacement.
How teams detect issues like this
Detection can combine static analysis, code review, runtime monitoring, and policy enforcement.
- Review upload handlers for filename-based overwrite behavior and for authorization checks that occur only at directory or share level.
- Search for file-save, move, rename, or replacement operations that execute without checking the existing object's owner or permissions.
- Add tests covering filename collisions across anonymous share users, upload-only users, and authenticated users without edit rights.
- Monitor logs for repeated uploads targeting existing filenames, especially from shared-link identities.
- Enforce application policies requiring separate authorization for create and replace actions.
- Automated code review and security scanning tools may help identify upload paths that write over existing objects without object-level authorization.
Detection can combine static analysis, code review, runtime monitoring, and policy enforcement.
- Review upload handlers for filename-based overwrite behavior and for authorization checks that occur only at directory or share level.
- Search for file-save, move, rename, or replacement operations that execute without checking the existing object's owner or permissions.
- Add tests covering filename collisions across anonymous share users, upload-only users, and authenticated users without edit rights.
- Monitor logs for repeated uploads targeting existing filenames, especially from shared-link identities.
- Enforce application policies requiring separate authorization for create and replace actions.
- Automated code review and security scanning tools may help identify upload paths that write over existing objects without object-level authorization.
