CVE-2026-57491 in FileRise
Summary
by MITRE • 10/14/2026
FileRise is a self-hosted web-based file manager with multi-file upload, editing, and batch operations. Prior to 3.16.0, FileRise archive extraction does not apply UploadNamePolicy::isAllowedForWrite() before ZipArchive::extractTo() writes entries into the destination directory. An authenticated user with upload and extract permissions can place a blocked extension such as a PHP-family file inside a ZIP and cause it to be written to disk even when normal uploads reject that filename. Post-extraction metadata pruning does not remove the blocked file, so deployments that execute uploaded content may permit code execution. This issue is fixed in version 3.16.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/14/2026
FileRise operates as a self-hosted web-based file management solution designed to facilitate multi-file uploads, editing capabilities, and batch operations for users managing digital assets within an organizational or personal infrastructure. The software relies on strict access controls and filename validation policies to ensure that only permitted file types are stored in designated directories, thereby preventing the execution of malicious scripts by underlying server environments such as Apache or Nginx with PHP modules. In versions prior to 3.16.0, a critical architectural flaw exists within the archive extraction workflow where the system fails to enforce security policies during the decompression process. Specifically, when an authenticated user possessing upload and extract permissions submits a ZIP file containing entries with blocked extensions, such as PHP scripts or other executable formats, the application utilizes the ZipArchive::extractTo() function without first invoking UploadNamePolicy::isAllowedForWrite(). This omission bypasses the standard validation logic that is applied during direct single-file uploads, allowing prohibited files to be written directly to the web-accessible destination directory.
The technical root cause of this vulnerability lies in the inconsistent application of security controls between different input vectors within the same software component. While the upload mechanism correctly checks file extensions against a whitelist or blacklist defined by UploadNamePolicy::isAllowedForWrite(), the archive extraction routine assumes that all entries within an uploaded ZIP are safe, ignoring the possibility that attackers can bypass filename restrictions by packaging malicious payloads inside compressed archives. This discrepancy creates a path for unauthorized code execution if the server is configured to interpret and execute files with specific extensions located in these directories. Furthermore, the vulnerability is exacerbated by post-extraction metadata pruning mechanisms which fail to identify and remove these blocked files after they have been written to disk. Consequently, even if subsequent operations attempt to sanitize the directory state, the malicious artifacts remain present and accessible, effectively neutralizing any defensive measures intended to clean up temporary or processed uploads.
The operational impact of this flaw is severe for deployments that execute uploaded content, as it allows an authenticated attacker to achieve remote code execution on the target server. By uploading a ZIP file containing a PHP script with a blocked extension, such as shell.php or backdoor.php, and triggering the extraction process, the attacker can place executable code directly into a web-accessible path. If the server configuration permits interpretation of these files, the attacker gains full control over the application context, potentially leading to complete system compromise, data exfiltration, lateral movement within the network, or defacement of the service. This vulnerability aligns with CWE-434, which describes the unrestricted upload of file with dangerous type, and is further contextualized by MITRE ATT&CK technique T1505.003, known as Web Shell: ASPX, indicating that attackers can deploy web shells to maintain persistent access. The failure to validate inputs during archive extraction also reflects CWE-829, where inclusion of a function from an untrusted source occurs due to improper validation of external data before use in security-critical functions.
To mitigate this vulnerability and prevent similar issues in future deployments, it is imperative that organizations upgrade FileRise to version 3.16.0 or later, which addresses the logic gap by ensuring that UploadNamePolicy::isAllowedForWrite() is applied consistently during archive extraction operations. For environments where immediate patching is not feasible, administrators should implement strict web server configurations that prevent execution of scripts in upload directories, such as using Apache directives to deny script execution for specific file types or employing Content Security Policy headers to restrict inline code execution. Additionally, implementing a secondary validation layer at the infrastructure level, such as scanning uploaded archives with antivirus software before extraction and ensuring that post-extraction cleanup routines rigorously remove any files not matching allowed extensions, can provide defense-in-depth against this class of vulnerabilities. Regular audits of file handling logic across all application endpoints are recommended to identify other potential inconsistencies in security policy enforcement.