CVE-2026-104110 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.24.0, FileRise Pro /api/pro/portals/get.php returns a configured client portal's full internal record to an unauthenticated caller who knows or guesses the portal slug. The response includes the internal storage folder path, client contact email, form settings, and upload-policy details, while the separate publicMeta.php endpoint intentionally exposes only curated branding data. Exploitation requires the Pro add-on and at least one configured portal. This issue is fixed in version 3.24.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/15/2026
FileRise is a self-hosted web-based file management solution that provides features such as multi-file upload, editing capabilities, and batch operations for managing digital assets. The software includes an add-on module known as FileRise Pro which introduces client portal functionality allowing administrators to create dedicated spaces for specific clients or groups. These portals are designed to facilitate secure file sharing and collaboration by exposing curated branding data through a public endpoint while keeping sensitive configuration details restricted. However, prior to version 3.24.0, the architecture of these internal APIs contained a critical access control flaw that undermined the intended separation between public-facing information and private administrative settings.
The core technical vulnerability lies in the improper implementation of authorization checks on the /api/pro/portals/get.php endpoint within the FileRise Pro add-on. This API route is responsible for retrieving detailed configuration data associated with specific client portals identified by a unique slug identifier. While the application correctly restricts access to this resource based on authentication, it fails to verify whether the authenticated user has permission to view the portal in question or if the request should be entirely denied without credentials. Consequently, an unauthenticated attacker who can guess or enumerate valid portal slugs can send requests directly to this endpoint and receive a comprehensive response containing sensitive internal records. The system treats any request with a known slug as valid regardless of the caller's identity, effectively bypassing authentication requirements for data retrieval operations.
The operational impact of this vulnerability is significant due to the breadth of information exposed in the API response. An attacker gaining access through this flaw can obtain the full internal record of a configured client portal, which includes the absolute path to the internal storage folder where files are physically stored on the server filesystem. This disclosure provides critical intelligence for further attacks such as local file inclusion or directory traversal if other vulnerabilities exist within the application's file handling logic. Additionally, the response reveals client contact email addresses, form settings used for data collection portals, and detailed upload-policy configurations including size limits, allowed file types, and quota restrictions. The exposure of these details allows attackers to profile organizational structures, identify potential targets for phishing or social engineering attacks using harvested email addresses, and understand system constraints that might be exploited in subsequent stages of an attack chain.
This vulnerability is classified under CWE-284 Improper Access Control as it represents a failure to enforce proper restrictions on unauthenticated users regarding sensitive resources. From the perspective of the MITRE ATT&CK framework, this behavior aligns with Discovery techniques such as T1078 Valid Accounts if authentication was partially bypassed or more accurately T1592 Gather Victim Host Information where an attacker collects data about a target environment to plan further actions. The distinction between the publicMeta.php endpoint which intentionally exposes only curated branding data and the get.php endpoint highlights that the exposure of internal records is not by design but rather a result of insufficient input validation and authorization logic in the API handler.
To mitigate this vulnerability, organizations running FileRise Pro versions prior to 3.24.0 must upgrade immediately to version 3.24.0 or later where the access control mechanisms have been corrected to properly enforce authentication requirements on all sensitive endpoints. Until an update can be applied, administrators should consider implementing network-level controls such as firewall rules or reverse proxy configurations that restrict direct external access to the /api/pro/portals/get.php path while allowing legitimate traffic through authenticated channels only. Additionally, monitoring server logs for unusual patterns of requests targeting portal slugs with non-authenticated sessions can help detect exploitation attempts in real time. It is also advisable to review any exposed data from past incidents and rotate credentials or notify affected clients if sensitive information such as email addresses was potentially compromised during the period when the vulnerability existed.