Vulnerabilities

Vulnerability · CVE-2026-111920

Vikunja: Explicit lower-permission share on a sub-project is silently overridden by an inherited parent permission (broken access control / privilege-management regression in v2.6.

Published Oct 9, 2026 · catalog updated Oct 18, 2026 · Vikunja: Explicit lower-permission share

Open the advisory

Exploitation likelihood is not on this record for CVE-2026-111920. A missing EPSS score is not a low risk. Compare Vikunja: Explicit lower-permission share with the linked advisory before you change production.

Severity

Medium5.4

Known exploitation

Not in CISA/VulnCheck KEV

EPSS

Not in the current FIRST EPSS dataset

Remediation

Advisory link

Affected products

Go code.vikunja.io/api

## Description ### Summary In Vikunja v2.6.0 the project-permission engine resolves a user's effective permission on a project as the **MAX over the entire reachable project subtree**. As a result, when a user has been granted a **higher** permission on a parent project and the owner *explicitly* shares a **child** project with that same user at a **lower** permission (an intended down-restriction), the explicit lower grant is **silently ignored** and the user receives the higher, inherited permission on the child. A user who was deliberately restricted to **read-only** on a sensitive sub-project can therefore modify it, delete it, and re-share it (including granting other users admin) - none of which the owner intended. This is a behavior regression from v2.5.0, whose engine used "nearest-ancestor-grant-wins" semantics that honored the explicit child grant. ### Details Effective permissions are computed by a single recursive CTE in ( ): For a parent where the user has a direct ADMIN(2) grant and a child (with ) where the user has a direct READ(0) grant, the CTE produces the rows , (direct grants) **and** (the parent grant propagated down the recursion). The final collapses the child to . The explicit READ grant on is discarded. In v2.5.0 the equivalent resolution used (nearest-ancestor wins), so the child's own direct grant took precedence and the down-restriction was honored. The switch to in v2.6.0 introduces the override. Code comments in describe the additive behavior as intentional ("a grant on a descendant can raise an inherited permission, never lower it"), so the maintainers may consider this working-as-intended - but it is a security-relevant regression that silently defeats an explicit, owner-configured access restriction, so it is reported here for a decision. ### PoC Target: (Vikunja v2.6.0). Owner: . Restricted collaborator: (id 2). Third party used to demonstrate re-sharing: . Note Vikunja's v1 REST convention: ** = create, = update**. All values belo