CVE-2026-119657 in FilePress
Summary
by MITRE • 10/30/2026
FilePress through 3.0.1 contains a missing authorization vulnerability in dzz/pichome/library that allows authenticated users to manage other libraries' folders because checkuserperm_by_uid only checks membership of any library. Attackers who know another library's appid or folder id can invoke folder.php operations like deletefolder and rename, or rightdata.php getfolderdata, to delete, modify, or read foreign folders.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in FilePress versions up to 3.0.1 represents a critical failure in access control mechanisms within the application's library management subsystem. Specifically located in the dzz/pichome/library module, this flaw stems from an insufficient authorization check performed by the function checkuserperm_by_uid. While the system correctly verifies that a user is a member of some library to grant basic authentication and initial access, it fails to validate whether the specific resource being accessed belongs to the authenticated user or their designated group. This logical error creates a situation where valid credentials are leveraged to perform actions on resources outside the intended scope, effectively bypassing granular permission controls that should restrict users to their own data silos.
From a technical perspective, the core issue lies in the logic of the authorization middleware which relies solely on general library membership rather than specific resource ownership or explicit permission grants for individual folders. When an authenticated user initiates operations such as deleting a folder via deletefolder, renaming it through rename, or retrieving metadata using getfolderdata from rightdata.php, the backend processes these requests without verifying that the target folder's appid or folder id corresponds to assets owned by the requesting user. This oversight allows for direct object reference manipulation where an attacker who has discovered or guessed another library's identifier can interact with those resources as if they were their own. The absence of a secondary validation step ensures that any valid session token is sufficient to execute privileged operations on arbitrary folders within the system.
The operational impact of this vulnerability is significant, particularly in multi-tenant environments where FilePress might be used by multiple distinct teams or organizations sharing an instance. An attacker can exploit this flaw to delete critical data belonging to other users, leading to permanent loss of information and disruption of business operations. Furthermore, the ability to rename folders allows for social engineering attacks or confusion within shared workspaces, potentially masking malicious activities or disrupting file organization structures. The capability to read folder data via getfolderdata exposes sensitive metadata about other libraries, which can be used for further reconnaissance to identify more valuable targets or understand organizational hierarchies and project statuses without direct access to the files themselves.
This vulnerability aligns with CWE-269, Improper Privilege Management, as it involves a user possessing privileges that exceed their intended role regarding specific resources. It also maps directly to MITRE ATT&CK technique T1078, Valid Accounts, specifically in the context of lateral movement or data exfiltration within an application environment where valid credentials are used to access unauthorized objects. The exploitation path is straightforward and does not require complex payload construction, relying instead on simple HTTP requests with manipulated parameters for appid or folder id.
Mitigation strategies should focus immediately on patching the checkuserperm_by_uid function to enforce strict ownership verification before allowing any modification or read operations. Developers must ensure that every API endpoint handling resource manipulation validates that the requesting user's ID matches the owner ID of the target resource, not just their membership in a broader library group. In addition to code fixes, implementing role-based access control (RBAC) with explicit permissions for each action on specific resources will provide defense-in-depth. Administrators should also enforce strict input validation and ensure that application logs monitor for unusual patterns of folder access across different libraries to detect potential exploitation attempts early.