LeafWiki CVE-2026-53528

Exploitation requires a valid LeafWiki account with editor-level permissions - PR:L in CVSS terms. The attack targets the asset rename endpoint specifically; read/write access to that endpoint is gated on the editor role. The LeafWiki server process must have read (and rename/move) access to the target sensitive file for the traversal to succeed; if the process is correctly sandboxed to its own directory, the traversal finds no sensitive files to move. No special network position, no user interaction from another party, and no non-default configuration are required beyond holding editor credentials. The primary limiting factors are: (1) editor-role membership is required and should not be granted to untrusted users, and (2) a properly least-privileged process account eliminates the reachable file set even when the vulnerability is triggered.

The NVD CVSS 3.1 score of 8.8 with vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H correctly characterizes the core mechanics: network-reachable, no special conditions, editor-level credentials only, no user interaction. The C:H/I:H/A:H impact triad is defensible because a single rename operation targeting the application's SQLite or similar database simultaneously exposes its contents (C:H), destroys the running application's data integrity (I:H), and renders the wiki inoperable (A:H). No EPSS score is present in the provided intelligence, and the CVE is absent from CISA KEV, so active exploitation is not confirmed - the real-world risk is therefore driven by the low barrier for any credentialed insider or compromised editor account rather than by observed threat-actor activity. The PR:L prerequisite is the primary limiting factor: in small or tightly managed deployments where editor access is restricted to fully trusted personnel, risk is materially reduced. In broader multi-user or open-registration deployments, the editor credential requirement provides minimal protection and the issue should be treated as critical.

An attacker with a legitimate LeafWiki editor account uses the asset rename API to supply a traversal path (e.g., '../../app.db') as the source and a valid page asset name as the destination. The server moves the application database into that page's asset folder, and the attacker retrieves it via a standard HTTP GET to the asset URL - no elevated privileges, no server-side code execution, and no additional tooling required. No public exploit code has been identified at time of analysis, but the technique is straightforward for anyone with editor access and knowledge of common LeafWiki deployment layouts.