EUVD-2026-101667Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain valid share token and password
-
ExploitSubmit upload with existing filename
-
ExecutionServer accepts collision as replacement
-
ImpactOriginal file content silently overwritten
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization checks on every request
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires that an administrator has created an upload-enabled shared-folder link or an upload-only portal link; the attacker must possess the valid share token and any configured share password for that link, and must know (or guess) the exact filename of an existing file in the destination. The flaw also affects authenticated uploads via /api/upload/upload.php and authenticated upload-only users lacking edit authority over the target file. Limiting factors: the vulnerable public-link feature must be explicitly enabled and shared, the share token/password gate access, and impact is confined to overwriting existing files (no confidentiality exposure and no code execution); installations that do not expose upload-capable share links are not reachable via the unauthenticated path. |
| Impact | This is a genuine integrity-focused risk but not a drop-everything emergency. The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L, base 8.2) describes a low-complexity, no-user-interaction network attack with high integrity impact and low availability impact, and crucially no confidentiality impact - consistent with a silent file-overwrite rather than data theft or code execution. The PR:N rating treats the attacker as unauthenticated, which is technically accurate for the public shared-link path, but the description is explicit that a valid share token AND any configured share password are still required, so 'unauthenticated' here means 'no FileRise user account' rather than 'zero prerequisites' - defenders should weigh that. No EPSS score, SSVC decision, or KEV entry is present in the input, and there is no indication of public exploit code, so exploitation is currently theoretical. The weakness (CWE-862, Missing Authorization - create-vs-replace not enforced) is simple and well-understood, lowering the barrier to weaponization, but the real-world ceiling is limited: the product is a niche self-hosted tool and the attack overwrites rather than executes. Net: a credible, easily-exploited-if-exposed integrity flaw for anyone running public upload links, but moderate overall priority given no confirmed exploitation and limited product footprint. |
| Exploit ScenarioDerived | An organization shares a FileRise upload-enabled link (shared-folder or upload-only) with external partners, protected by a share token and password. A recipient who already has that token and password uploads a file using the exact name of an existing document, and FileRise silently replaces the original content while leaving the original uploader's metadata intact, enabling stealthy content tampering or defacement. No public exploit code is identified at time of analysis, and the attack requires only a crafted upload request of a colliding filename. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 14, 2026
File overwrite in FileRise prior to 3.18.0 allows an unauthenticated visitor who holds a valid upload-enabled shared-folder or upload-only link token - plus any configured share password - to re-upload a file using the exact name of an existing file and silently replace its contents while the original uploader metadata is preserved. The same missing replacement check affects ordinary authenticated uploads through /api/upload/upload.php and authenticated upload-only users who lack edit authority over the target file, so the outcome is a high-integrity, no-confidentiality loss (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L, 8.2). Exploitation requires that an administrator has actually created and shared an upload-capable link and that the attacker knows or guesses the target filename; impact is confined to overwriting existing files, with no data disclosure and no code execution path. No public exploit code was identified at time of analysis, and the vendor-released fix is FileRise 3.18.0.
RemediationAI
Upgrade to FileRise 3.18.0, the vendor-released patch that makes public shared-folder and portal uploads create-only on filename collisions and requires edit authority plus ownership, folder ownership, admin, or bypass-ownership before an authenticated upload can replace an existing file; the release is available at https://github.com/error311/FileRise/releases/tag/v3.18.0 and the specific patch is commit 9ed1a38f00918849dbda30f54291d1451ed80d11, with details in advisory GHSA-r787-5hp3-4874. If immediate upgrading is not possible, the effective compensating control is to remove exposure of the vulnerable entry points: revoke or delete upload-enabled shared-folder and upload-only portal links and regenerate any tokens that were distributed, accepting the loss of external upload functionality for those recipients; where upload links must remain, keep them read-only or non-upload and treat any previously received files as untrusted, and restrict or block access to /api/upload/upload.php from untrusted networks (for example via reverse-proxy rules), which will break legitimate authenticated uploads for remote users. Because overwritten content is silently destroyed while uploader metadata is retained, administrators who ran affected versions with active upload shares should also audit recently modified files against uploader metadata and restore originals from backups where a mismatch is found; note that the metadata-notation changes in 3.18.0 are handled transparently for existing folders, but heavily nested or space-containing folder names are the ones most affected by the accompanying metadata path collision fix.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
FileRise is a self-hosted, PHP-based web file manager supporting multi-file upload, editing, WebDAV and batch operations; the only CPE in scope is cpe:2.3:a:error311:filerise:*:*:*:*:*:*:*:*, i.e. all releases before the fix. The reported weakness class is CWE-862 (Missing Authorization): the upload handlers performed content writes without verifying that the caller was permitted to replace a pre-existing file, and without enforcing create-only semantics for public share and portal upload paths. The committed fix (9ed1a38f…) hardens the upload pipeline by making public shared-folder and portal uploads create-only when a destination filename already exists, and by requiring edit authority plus ownership, folder ownership, admin, or ownership-bypass before an authenticated upload may replace an existing file; collisions now return an explicit conflict/permission response and leave original content intact. The same commit also addresses a related metadata-path flaw in FileModel.php/FolderModel.php, where folder metadata filenames were derived with str_replace(['/', '\\', ' '], '-', ...) against the folder path, flattening distinct logical folders (for example separators and spaces) into the same _metadata.json name; a new FileRise\Support\MetadataPath helper produces collision-resistant, path-preserving filenames used consistently by uploads, file operations, WebDAV, ownership/read_own checks and background transfers, with existing metadata for collision-prone folders copied into the isolated filename on first access. The CVSS vector confirms network reachability, no privileges and no user interaction (PR:N/UI:N), integrity impact High with only partial availability impact and no confidentiality impact, matching an overwrite-only primitive.
Know when Filerise gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L
Network-reachable share links with low complexity and no account needed justify AV:N/AC:L/PR:N; silent file replacement gives I:H and A:L, with no data disclosure so C:N.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
FileRise is a self-hosted web-based file manager with multi-file upload, editing, and batch operations. Prior to 3.18.0, FileRise upload-enabled shared-folder and upload-only links do not reject a destination filename that already exists. An unauthenticated visitor with a valid share token and any configured share password can upload a file with the same name as an existing file and silently replace its content while the original uploader metadata remains. The same replacement gap affects ordinary authenticated uploads through /api/upload/upload.php and authenticated upload-only users who lack edit authority over the existing file. This issue is fixed in version 3.18.0.
Technical POC Analysis
Evidence note: the supplied evidence is the GHSA-r787-5hp3-4874 advisory plus reproduction steps.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
FileRise deployments older than 3.18.0 can silently overwrite the contents of existing files while preserving the original uploader's metadata. Anyone holding a shared upload link - or an authenticated user without edit rights on the target file - can replace a document with different content under the original name, undermining the trustworthiness of the files the organization relies on. Leadership should care because affected records, reports, or evidence stores may no longer reflect what was originally submitted, and the tampering leaves no obvious audit signal.
Apply vendor patch (upgrade to FileRise 3.18.0). Until the upgrade is complete, restrict or disable upload-enabled shared-folder and upload-only link tokens, rotate share passwords, monitor upload directories for content changes that preserve original uploader metadata, and review file integrity for previously shared upload locations.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
GitHub
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Malicious file upload attacks exploit insufficient validation when web applications accept user-provided files.
Unauthenticated directory traversal in FileRise prior to version 3.3.0 allows remote attackers to read arbitrary files f
Unauthenticated administrator account takeover in FileRise before 3.16.0 is possible via a path traversal flaw in the sh
FileRise versions before 3.3.0 contain an HTML injection vulnerability that allows authenticated users to manipulate the
FileRise is a self-hosted web-based file manager with multi-file upload, editing, and batch operations. Prior to 2.2.3,
FileRise, a self-hosted web file manager and WebDAV server, contains a critical hardcoded encryption key vulnerability i
Multi-factor authentication bypass in FileRise WebDAV prior to 3.16.0 allows an attacker who already holds a valid usern
FileRise, a self-hosted web file manager and WebDAV server, contains a path traversal vulnerability in its Resumable.js
Authentication bypass in FileRise versions before 3.23.0 lets a remote attacker log in as an existing local account - in
Online second-factor guessing against FileRise releases prior to 3.23.0 is permitted well beyond the intended limit beca
Authentication bypass in FileRise (CWE-290) lets unauthenticated remote attackers impersonate any account - including an
FileRise 1.4.0 exposes folder visibility and ownership decisions to authenticated low-privilege users because a regressi
Low-privilege users of FileRise versions prior to 1.4.0 can view, delete, or modify files owned by other users because t
Exploit-DB