OpenList EUVD-2026-58087

Exploitation requires a valid authenticated OpenList session where the account has been explicitly granted rename permission on at least one directory - a normal (non-admin) user role plus rename permission is sufficient, as confirmed by the GHSA advisory PoC. The attacker must supply traversal segments (e.g., ../../) in the src_name field of the batch rename payload. Exploitation is limited by: (1) rename permission must be granted by an admin - it is not a default; (2) the attacker must be able to guess or enumerate target file paths relative to their base path using traversal depth; (3) the operation is a rename rather than a read, so raw file content is not exfiltrated - only file integrity is violated and existence is disclosed via response codes. This vulnerability has no impact on deployments where no user has been granted rename permission.

The CVSS 3.1 score of 7.6 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L) aligns well with the described behavior. Network attack vector is correct for an HTTP API endpoint. Low privilege accurately reflects that a normal authenticated account with rename permission - not admin access - is sufficient. High integrity impact captures the ability to rename (effectively destroy or displace) files outside the attacker's authorized directory, including files owned by other users. Low confidentiality impact reflects the side-channel: success or error responses reveal whether a guessed out-of-scope path exists. Low availability impact captures targeted file disruption without systemic service denial. No CISA KEV listing exists, and EPSS data was not provided; however, the GHSA advisory contains a step-by-step PoC requiring only standard HTTP requests, making exploitation trivial once rename permission is granted. Real-world impact is highest in multi-tenant OpenList deployments where distinct users share a server with different base-path boundaries. No conflicting signals between the CVSS vector and the description were identified.

An authenticated OpenList user with rename permission sends a POST to /api/fs/batch_rename with src_dir set to a directory they legitimately control and src_name set to ../../other_team/sensitive_report.pdf. The server authorizes the request against the constrained src_dir, but path.Clean resolves the concatenated path to /other_team/sensitive_report.pdf, which lies outside the attacker's base. The file is then renamed to the attacker-specified new_name, effectively deleting it from the victim's namespace; the success or error response additionally discloses whether the targeted path existed. A proof-of-concept requiring only standard HTTP tooling is embedded in GHSA-95cv-r8x4-vh75.