FilePress EUVD-2026-114073

Exploitation requires an authenticated FilePress account that is a member of at least one library (PR:L); the flaw is that checkuserperm_by_uid in dzz/pichome/library.php checks membership of ANY library rather than the specific target library. The attacker must additionally know the target's library appid or folder id to invoke folder.php operations (deletefolder, rename) or rightdata.php getfolderdata - this ID-knowledge requirement (reflected as AT:P in the input vector) is the primary limiting factor and means exploitation is not fully unauthenticated or against a defaulted anonymous visitor. There is no user-interaction requirement. Limiting factors: attacker needs valid credentials and must discover or enumerate foreign appid/folder identifiers; if those identifiers are unguessable, practical exploitation narrows to attackers who already have visibility into them.

This is a genuinely low-priority issue despite being a real authorization flaw, and the signals are largely consistent. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N) and the low base score of 2.3 both point to a limited-impact IDOR: the attacker must already be an authenticated FilePress user (PR:L), and an Attack Requirement is present (AT:P) because the attacker must first know another library's appid or folder id, which is not attacker-controlled by default. Impact is capped at low confidentiality, integrity and availability (VC:L/VI:L/VA:L) with no scope change - a logged-in user can read, rename or delete folders belonging to another library, but cannot achieve code execution or full system compromise. The vuln.today decision label is 'monitor', not 'act_now' or 'emergency', which aligns with the low score. No EPSS score and no KEV listing are present in the input, so there is no evidence of active exploitation or high exploitation probability; absence of these is not itself a red flag for a low-severity authorization bug. A public PoC/writeup reference exists (hackmd) but is not verified as working exploit code. No signals here conflict; the only soft point is AT:P, which rests on the assumption that library appid/folder ids are not easily enumerable - if they are predictable or discoverable, real-world exploitability rises.

An attacker registers or already holds a normal authenticated account on a FilePress (≤3.0.1) instance, making them a member of at least one library. Because checkuserperm_by_uid only verifies membership of any library rather than the target library, they craft requests to folder.php (e.g. deletefolder or rename) or rightdata.php getfolderdata using another library's appid/folder id, then delete, modify, or read folders they should not access. A public writeup/PoC reference exists describing this IDOR, but it is not verified as working exploit code.