LeafWiki CVE-2026-53527

Exploitation requires a valid, authenticated LeafWiki user account on the target instance - any role (e.g., 'viewer') is sufficient. The vulnerability is present in default configurations of affected versions; no special feature flag or non-default setting is needed. Limiting factors include: instances that have disabled public registration and restrict account creation to trusted users are at lower practical risk, since an attacker must first obtain account credentials. Authentication is confirmed required by the CVSS PR:L metric and the vendor description. Instances without any untrusted users are not at meaningful risk from this specific vector.

The NVD-assigned CVSS 3.1 score of 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) accurately reflects the ease and impact of exploitation - low attack complexity, no user interaction, and full CIA impact upon gaining administrative control. The key limiting factor is PR:L: exploitation is gated behind a valid authenticated session, meaning unauthenticated attackers cannot directly exploit this flaw. No KEV listing exists and no public exploit code has been identified, so this is not currently under mass exploitation. However, the attack is trivially executable by any user with an account, and the lack of a KEV listing should not breed complacency on instances with open registration. Instances restricted to a small set of trusted users carry substantially lower practical risk, as stated in the vendor advisory. EPSS data is not available in the provided intelligence; exploitation probability should be considered moderate given the low technical barrier for authenticated users.

An attacker registers or obtains a low-privileged LeafWiki account (e.g., with 'viewer' role) on a target instance. They craft an authenticated API request to the user update endpoint, supplying a role value of 'admin' in the request body alongside their own account identifier. The server applies the update without enforcing role-assignment authorization, granting the attacker full administrative access to the wiki instance. No public exploit code is known at time of analysis, but the attack requires no specialized tooling beyond an HTTP client.