CVE-2026-54766

Vikunja is an open-source self-hosted task management platform. From 0.21.0 until 2.4.0, the project duplication operation in pkg/models/project_duplicate.go allows an authenticated user who can read a source project to place its duplicate beneath an arbitrary target parent project. ProjectDuplicate.CanCreate calls parent.CanCreate on an unhydrated Project containing only the body supplied parent_project_id instead of calling parent.CanWrite, so the target parent write-permission check is skipped. The ordinary project creation path enforces that permission, but PUT /api/v1/projects/{project}/duplicate does not, allowing attacker-owned content to be injected into another user or team project hierarchy. This issue is fixed in version 2.4.0.

Vikunja is an open-source self-hosted task management platform. From 0.21.0 until 2.4.0, the project duplication operation in pkg/models/project_duplicate.go allows an authenticated user who can read a source project to place its duplicate beneath an arbitrary target parent project. ProjectDuplicate.CanCreate calls parent.CanCreate on an unhydrated Project containing only the body supplied parent_project_id instead of calling parent.CanWrite, so the target parent write-permission check is skipped. The ordinary project creation path enforces that permission, but PUT /api/v1/projects/{project}/duplicate does not, allowing attacker-owned content to be injected into another user or team project hierarchy. This issue is fixed in version 2.4.0.

Summary

The project-duplication endpoint fails to enforce write access to the target parent project. Any authenticated (non-link-share) user can duplicate a project they can read into any parent project on the instance, regardless of whether they have write access to that parent — injecting an attacker-owned project into another user's or team's project hierarchy.

Details

ProjectDuplicate.CanCreate (pkg/models/project_duplicate.go) is meant to require write access to the parent the duplicate is placed under — its own comment says "Parent project exists + user has write access". The implementation does neither correctly:

func (pd *ProjectDuplicate) CanCreate(s *xorm.Session, a web.Auth) (canCreate bool, err error) {
    pd.Project = &Project{ID: pd.ProjectID}
    canRead, _, err := pd.Project.CanRead(s, a)
    if err != nil || !canRead {
        return canRead, err
    }
    if pd.ParentProjectID == 0 {
        return canRead, err
    }
    // Parent project exists + user has write access to is (-> can create new projects)
    parent := &Project{ID: pd.ParentProjectID}
    return parent.CanCreate(s, a)   // <-- bug
}

Two defects compound here:

1. Wrong permission method. It calls parent.CanCreate ("may I create this project?") instead of parent.CanWrite ("may I create children inside this project?"). The latter is what the normal create path uses — POST /projects with a parent_project_id enforces parent.CanWrite via Project.CanCreate (pkg/models/project_permissions.go:196-199).

2. Unhydrated struct. parent is constructed as &Project{ID: pd.ParentProjectID} and never loaded from the database, so its in-memory ParentProjectID is always 0. Inside Project.CanCreate the only branch that performs any permission check is if p.ParentProjectID != 0 { return parent.CanWrite(...) } — which therefore never executes. Control falls through to the link-share check and then return true, nil. The result is true for any authenticated non-link-share user, for any ParentProjectID.

Nothing downstream re-checks: ProjectDuplicate.Create → CreateProject → checkProjectBeforeUpdateOrDelete (pkg/models/project.go:954) validates only that the parent exists, is not a pseudo-project, and introduces no cycle — no authorization.

Impact

An authenticated user can:

• Duplicate any project they can read (including their own) and attach the copy as a child of any parent project ID on the instance, with no write access to that parent.
• Inject an attacker-owned project into other users'/teams' project trees. The duplicate is owned by the attacker but appears inside the victim's hierarchy; members of the victim parent see it, and because Vikunja propagates parent access down the tree, they may inherit access to the injected project — enabling content injection / spam / phishing inside another tenant's workspace.

This is a bypass of the same parent-write guard that the ordinary create path enforces, so the duplicate route is an authorization hole for an operation that is otherwise correctly gated. The endpoint requires authentication; it does not expose or modify the victim's existing project data (the source is attacker-readable), so the impact is an integrity / access-control violation rather than confidentiality.

Proof of Concept

1. As user A, create or have read access to any project S (e.g. id 100).
2. Identify a parent project P (e.g. id 5) owned by user B, to which A has no access.
3. Call PUT /api/v1/projects/100/duplicate with body {"parent_project_id": 5}.
4. The request succeeds (201). A new project owned by A is created as a child of B's project 5, despite A having no write access to it. The equivalent POST /api/v1/projects with parent_project_id: 5 would be correctly rejected with 403.

Affected versions

Introduced with the namespace→project migration (commit fef253312, first released in v0.21.0) and present through…

Vikunja is an open-source self-hosted task management platform. From 0.21.0 until 2.4.0, the project duplication operation in pkg/models/project_duplicate.go allows an authenticated user who can read a source project to place its duplicate beneath an arbitrary target parent project. ProjectDuplicate.CanCreate calls parent.CanCreate on an unhydrated Project containing only the body supplied parent_project_id instead of calling parent.CanWrite, so the target parent write-permission check is skipped. The ordinary project creation path enforces that permission, but PUT /api/v1/projects/{project}/duplicate does not, allowing attacker-owned content to be injected into another user or team project hierarchy. This issue is fixed in version 2.4.0.

Vikunja is an open-source self-hosted task management platform. From 0.21.0 until 2.4.0, the project duplication operation in pkg/models/project_duplicate.go allows an authenticated user who can read a source project to place its duplicate beneath an arbitrary target parent project. ProjectDuplicate.CanCreate calls parent.CanCreate on an unhydrated Project containing only the body supplied parent_project_id instead of calling parent.CanWrite, so the target parent write-permission check is skipped. The ordinary project creation path enforces that permission, but PUT /api/v1/projects/{project}/duplicate does not, allowing attacker-owned content to be injected into another user or team project hierarchy. This issue is fixed in version 2.4.0.

Summary

The project-duplication endpoint fails to enforce write access to the target parent project. Any authenticated (non-link-share) user can duplicate a project they can read into any parent project on the instance, regardless of whether they have write access to that parent — injecting an attacker-owned project into another user's or team's project hierarchy.

Details

ProjectDuplicate.CanCreate (pkg/models/project_duplicate.go) is meant to require write access to the parent the duplicate is placed under — its own comment says "Parent project exists + user has write access". The implementation does neither correctly:

func (pd *ProjectDuplicate) CanCreate(s *xorm.Session, a web.Auth) (canCreate bool, err error) {
    pd.Project = &Project{ID: pd.ProjectID}
    canRead, _, err := pd.Project.CanRead(s, a)
    if err != nil || !canRead {
        return canRead, err
    }
    if pd.ParentProjectID == 0 {
        return canRead, err
    }
    // Parent project exists + user has write access to is (-> can create new projects)
    parent := &Project{ID: pd.ParentProjectID}
    return parent.CanCreate(s, a)   // <-- bug
}

Two defects compound here:

1. Wrong permission method. It calls parent.CanCreate ("may I create this project?") instead of parent.CanWrite ("may I create children inside this project?"). The latter is what the normal create path uses — POST /projects with a parent_project_id enforces parent.CanWrite via Project.CanCreate (pkg/models/project_permissions.go:196-199).

2. Unhydrated struct. parent is constructed as &Project{ID: pd.ParentProjectID} and never loaded from the database, so its in-memory ParentProjectID is always 0. Inside Project.CanCreate the only branch that performs any permission check is if p.ParentProjectID != 0 { return parent.CanWrite(...) } — which therefore never executes. Control falls through to the link-share check and then return true, nil. The result is true for any authenticated non-link-share user, for any ParentProjectID.

Nothing downstream re-checks: ProjectDuplicate.Create → CreateProject → checkProjectBeforeUpdateOrDelete (pkg/models/project.go:954) validates only that the parent exists, is not a pseudo-project, and introduces no cycle — no authorization.

Impact

An authenticated user can:

• Duplicate any project they can read (including their own) and attach the copy as a child of any parent project ID on the instance, with no write access to that parent.
• Inject an attacker-owned project into other users'/teams' project trees. The duplicate is owned by the attacker but appears inside the victim's hierarchy; members of the victim parent see it, and because Vikunja propagates parent access down the tree, they may inherit access to the injected project — enabling content injection / spam / phishing inside another tenant's workspace.

This is a bypass of the same parent-write guard that the ordinary create path enforces, so the duplicate route is an authorization hole for an operation that is otherwise correctly gated. The endpoint requires authentication; it does not expose or modify the victim's existing project data (the source is attacker-readable), so the impact is an integrity / access-control violation rather than confidentiality.

Proof of Concept

1. As user A, create or have read access to any project S (e.g. id 100).
2. Identify a parent project P (e.g. id 5) owned by user B, to which A has no access.
3. Call PUT /api/v1/projects/100/duplicate with body {"parent_project_id": 5}.
4. The request succeeds (201). A new project owned by A is created as a child of B's project 5, despite A having no write access to it. The equivalent POST /api/v1/projects with parent_project_id: 5 would be correctly rejected with 403.

Affected versions

Introduced with the namespace→project migration (commit fef253312, first released in v0.21.0) and present through…