Key points
- CVE-2026-61843 has a CVSS score of 8.2, rated as high severity.
- The flaw affects shared folders and upload-only links in FileRise versions before 3.18.0.
- Version 3.18.0 fixes the issue by rejecting uploads that match existing filenames.
FileRise, a self-hosted web-based file manager, has released version 3.18.0 to address a high severity vulnerability. The flaw allows users with valid share tokens to silently replace existing files without altering original metadata.
What happened
The National Vulnerability Database records CVE-2026-61843 with a CVSS base score of 8.2, categorising it as high severity. The underlying weakness is classified as CWE-862.
Prior to version 3.18.0, the software failed to reject destination filenames that already existed in upload-enabled shared folders or upload-only links. An unauthenticated visitor possessing a valid share token and any configured share password could upload a file sharing the same name as an existing one. This action silently replaced the original content while retaining the original uploader metadata.
The replacement gap also impacted ordinary authenticated uploads through the /api/upload/upload.php endpoint. Authenticated users with upload-only permissions, who lacked edit authority over the existing file, could trigger the same behaviour. The source material states that this issue is fixed in version 3.18.0.
Why it matters
Organisations using FileRise for document management face data integrity risks if they operate versions older than 3.18.0. The ability to replace files without changing metadata means that standard file system timestamps or user ownership attributes may not indicate tampering.
According to the NVD record, the flaw allows silent content replacement. This means that a legitimate file could be swapped for different content by anyone with a valid share link. The lack of metadata change complicates forensic analysis, as the file appears unchanged to casual observers or automated monitoring tools that rely on modification dates.
The vulnerability affects both unauthenticated visitors with share tokens and authenticated users with limited permissions. This broadens the attack surface, as even low-privilege accounts can overwrite critical documents. Teams must verify their current version to determine if they are exposed to this specific logic flaw.
What happens next
- Verify the installed FileRise version on all managed servers.
- Identify any instances running versions prior to 3.18.0.
- Plan an upgrade to version 3.18.0 or later.
- Review file integrity logs for unexpected content changes.
Patch priority
Teams usually prioritise systems exposed to untrusted networks or public links. Check whether your FileRise instances serve external users or partner organisations. If so, schedule the update immediately. Test the upgrade in a staging environment first to ensure compatibility with existing workflows. Back up current configurations and data before applying the patch. If an immediate update is not possible, restrict share link access and monitor for unusual upload activity.
What to do and how to stay safe: FileRise
- Audit all FileRise installations to confirm the version number.
- Disable or revoke existing shared links if an immediate patch is not feasible.
- Monitor upload logs for files with unchanged metadata but altered content.
- Apply version 3.18.0 once the vendor provides an update to resolve the flaw.
Step-by-step guide: Patch Management: Definition, Purpose and Operational Reality
General security guidance from the AppSec Scoop newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
What is the CVSS score for CVE-2026-61843?
The CVSS score is 8.2, which is rated as high severity.
Which FileRise versions are affected by this vulnerability?
All versions prior to 3.18.0 are affected by this issue.
Is there a fix available for this vulnerability?
Yes, the issue is fixed in version 3.18.0.
