CVE-2026-111920

Vikunja 2.6.0 contains a broken access control flaw in getProjectAccessForUser (pkg/models/project_access.go), which resolves a user's effective project permission as the maximum over the project tree, silently overriding explicit lower-permission shares on sub-projects. A collaborator with write access on a parent project but read-only access to a child project can modify the child project's tasks and content.

Vikunja 2.6.0 contains a broken access control flaw in getProjectAccessForUser (pkg/models/project_access.go), which resolves a user's effective project permission as the maximum over the project tree, silently overriding explicit lower-permission shares on sub-projects. A collaborator with write access on a parent project but read-only access to a child project can modify the child project's tasks and content.

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 pkg/models/project_access.go (getProjectAccessForUser):

WITH RECURSIVE grants (project_id, permission) AS (
    SELECT project_id, MAX(permission) FROM (
        SELECT id AS project_id, 2 AS permission FROM projects WHERE owner_id = ?
        UNION ALL SELECT project_id, permission FROM users_projects WHERE user_id = ?
        UNION ALL SELECT tp.project_id, tp.permission FROM team_projects tp
                  INNER JOIN team_members tm ON tm.team_id = tp.team_id WHERE tm.user_id = ?
    ) direct_grants GROUP BY project_id
),
tree (id, permission) AS (
    SELECT p.id, g.permission FROM projects p INNER JOIN grants g ON g.project_id = p.id
    UNION
    SELECT p.id, t.permission FROM projects p INNER JOIN tree t ON p.parent_project_id = t.id
)
SELECT id, MAX(permission) AS permission FROM tree GROUP BY id

For a parent P where the user has a direct ADMIN(2) grant and a child C (with parent_project_id = P) where the user has a direct READ(0) grant, the tree CTE produces the rows (P,2), (C,0) (direct grants) and (C,2) (the parent grant propagated down the recursion). The final SELECT id, MAX(permission) ... GROUP BY id collapses the child to MAX(0, 2) = 2 (ADMIN). The explicit READ grant on C is discarded.

In v2.5.0 the equivalent resolution used ROW_NUMBER() OVER (... ORDER BY priority) (nearest-ancestor wins), so the child's own direct grant took precedence and the down-restriction was honored. The switch to MAX(...) in v2.6.0 introduces the override. Code comments in project_access.go 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: http://localhost:3456 (Vikunja v2.6.0). Owner: admin. Restricted collaborator: alice (id 2). Third party used to demonstrate re-sharing: bob. Note Vikunja's v1 REST convention: PUT = create, POST = update. All values below are the real, unredacted values from the run.

Step 1 - Log in as the owner (admin) and as the restricted collaborator (alice)

curl -s -X POST http://localhost:3456/api/v1/login -H 'Content-Type: application/json' \
  -d '{"username":"admin","password":"VikunjaLab123!"}'
curl -s -X POST http://localhost:3456/api/v1/login -H 'Content-Type: application/json' \
  -d '{"username":"alice","password":"AliceLab123!"}'

Real tokens issued:

admin: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3ODg4MDMzNzMsImlkIjoxLCJpc19hZG1pbiI6dHJ1ZSwianRpIjoiODY1ZmNjMDEtMDQ3Zi00NjM2LWI1M2QtNmU1MzliZTRhMDY4Iiwic2lkIjoiYTFhMDQ1YWYtOWMyMC00YmRmLWE2YzQtMjRmN2JkM2QwMDRlIiwidHlwZSI6MSwidXNlcm5hbWUiOiJhZG1pbiJ9.4l8vTEkB_gna717cNLc_tgOI_kUBcZMjKiZH6U8sPAg
alice:…

Vikunja 2.6.0 contains a broken access control flaw in getProjectAccessForUser (pkg/models/project_access.go), which resolves a user's effective project permission as the maximum over the project tree, silently overriding explicit lower-permission shares on sub-projects. A collaborator with write access on a parent project but read-only access to a child project can modify the child project's tasks and content.

Vikunja 2.6.0 contains a broken access control flaw in getProjectAccessForUser (pkg/models/project_access.go), which resolves a user's effective project permission as the maximum over the project tree, silently overriding explicit lower-permission shares on sub-projects. A collaborator with write access on a parent project but read-only access to a child project can modify the child project's tasks and content.

Vikunja 2.6.0 contains a broken access control flaw in getProjectAccessForUser (pkg/models/project_access.go), which resolves a user's effective project permission as the maximum over the project tree, silently overriding explicit lower-permission shares on sub-projects. A collaborator with write access on a parent project but read-only access to a child project can modify the child project's tasks and content.

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 pkg/models/project_access.go (getProjectAccessForUser):

WITH RECURSIVE grants (project_id, permission) AS (
    SELECT project_id, MAX(permission) FROM (
        SELECT id AS project_id, 2 AS permission FROM projects WHERE owner_id = ?
        UNION ALL SELECT project_id, permission FROM users_projects WHERE user_id = ?
        UNION ALL SELECT tp.project_id, tp.permission FROM team_projects tp
                  INNER JOIN team_members tm ON tm.team_id = tp.team_id WHERE tm.user_id = ?
    ) direct_grants GROUP BY project_id
),
tree (id, permission) AS (
    SELECT p.id, g.permission FROM projects p INNER JOIN grants g ON g.project_id = p.id
    UNION
    SELECT p.id, t.permission FROM projects p INNER JOIN tree t ON p.parent_project_id = t.id
)
SELECT id, MAX(permission) AS permission FROM tree GROUP BY id

For a parent P where the user has a direct ADMIN(2) grant and a child C (with parent_project_id = P) where the user has a direct READ(0) grant, the tree CTE produces the rows (P,2), (C,0) (direct grants) and (C,2) (the parent grant propagated down the recursion). The final SELECT id, MAX(permission) ... GROUP BY id collapses the child to MAX(0, 2) = 2 (ADMIN). The explicit READ grant on C is discarded.

In v2.5.0 the equivalent resolution used ROW_NUMBER() OVER (... ORDER BY priority) (nearest-ancestor wins), so the child's own direct grant took precedence and the down-restriction was honored. The switch to MAX(...) in v2.6.0 introduces the override. Code comments in project_access.go 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: http://localhost:3456 (Vikunja v2.6.0). Owner: admin. Restricted collaborator: alice (id 2). Third party used to demonstrate re-sharing: bob. Note Vikunja's v1 REST convention: PUT = create, POST = update. All values below are the real, unredacted values from the run.

Step 1 - Log in as the owner (admin) and as the restricted collaborator (alice)

curl -s -X POST http://localhost:3456/api/v1/login -H 'Content-Type: application/json' \
  -d '{"username":"admin","password":"VikunjaLab123!"}'
curl -s -X POST http://localhost:3456/api/v1/login -H 'Content-Type: application/json' \
  -d '{"username":"alice","password":"AliceLab123!"}'

Real tokens issued:

admin: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3ODg4MDMzNzMsImlkIjoxLCJpc19hZG1pbiI6dHJ1ZSwianRpIjoiODY1ZmNjMDEtMDQ3Zi00NjM2LWI1M2QtNmU1MzliZTRhMDY4Iiwic2lkIjoiYTFhMDQ1YWYtOWMyMC00YmRmLWE2YzQtMjRmN2JkM2QwMDRlIiwidHlwZSI6MSwidXNlcm5hbWUiOiJhZG1pbiJ9.4l8vTEkB_gna717cNLc_tgOI_kUBcZMjKiZH6U8sPAg
alice:…

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.0) in code.vikunja.io/api