CVE-2026-54766: Code.vikunja.io/api Vikunja Has A Project Duplication Vulnerability

MODERATE
Advisory Identifier: GHSA-f27p-pw2p-9pr4
CWE-285 CWE-863
Published
Advisory Summary

CVE-2026-54766 is a MODERATE vikunja has a project duplication vulnerability (CWE-285: Improper Authorization) affecting Code.vikunja.io/api libraries in the Go ecosystem. The issue involves vikunja has a project duplication bypasses write-permission check on the target parent project. Remediation is available by upgrading affected packages to version 2.4.0.

CVE-2026-54766 at a Glance

CVE Identifier CVE-2026-54766
GHSA Identifier GHSA-f27p-pw2p-9pr4
Severity MODERATE
CVSS v3.1 Base Score N/A
CWE Classification CWE-285: Improper Authorization
Affected Product Code.vikunja.io/api
Package Ecosystem Go
Published Date
Last Updated

How to Fix CVE-2026-54766

To remediate this vulnerability, upgrade all affected Code.vikunja.io/api dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

code.vikunja.io/api fixed: 2.4.0
Upgrade code.vikunja.io/api to 2.4.0
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for code.vikunja.io/api

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-54766, inspect your project dependencies for Code.vikunja.io/api:

inspect dependencies for code.vikunja.io/api

Analyze the terminal output to locate any version of Code.vikunja.io/api in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 2.4.0), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-285: Improper Authorization, where the product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action. In Code.vikunja.io/api, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## 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: ```go 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 the latest release (v2.3.0). The shared model also backs the new `/api/v2` duplication route under review, so any v2 release would inherit the same flaw unless fixed in the model. ## Recommended Fix In `ProjectDuplicate.CanCreate`, check write access to the parent directly: ```go parent := &Project{ID: pd.ParentProjectID} return parent.CanWrite(s, a) ``` `Project.CanWrite` loads the project from the database and evaluates real permissions, fixing both the wrong-method and the unhydrated-struct defects at once and matching the documented contract. (It also rejects archived parents, which is desirable.)

CVE-2026-54766 Affected Code.vikunja.io/api Versions

1 component(s)
Fixed Versions:
2.4.0
Product / Package Ecosystem Affected Versions Fixed Version
code.vikunja.io/api
Go
≥ 0.21.0
< 2.4.0
2.4.0

References

Frequently Asked Questions

What is CVE-2026-54766?
CVE-2026-54766 is a security vulnerability in Code.vikunja.io/api involving Vikunja has a project duplication bypasses write-permission check on the target parent project under CWE-285: Improper Authorization.
Which Code.vikunja.io/api versions are affected?
Affected versions include releases prior to 2.4.0 across affected packages: code.vikunja.io/api.
What version fixes CVE-2026-54766?
Upgrading to 2.4.0 (or the latest patched release for your respective branch) resolves the vulnerability.
Is code.vikunja.io/api affected?
Yes, code.vikunja.io/api is affected in releases prior to 2.4.0. Upgrade your dependency to 2.4.0 or later.
What CWE is associated with CVE-2026-54766?
CVE-2026-54766 is classified under CWE-285: Improper Authorization (The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.).
How can I check Go dependencies for CVE-2026-54766?
Run the dependency tree command: 'inspect dependencies for code.vikunja.io/api'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-f27p-pw2p-9pr4",
  "modified" : "2026-08-28T16:37:26Z",
  "published" : "2026-08-28T16:37:26Z",
  "aliases" : [ "CVE-2026-54766" ],
  "summary" : "Vikunja has a project duplication bypasses write-permission check on the target parent project",
  "details" : "## Summary\n\nThe 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.\n\n## Details\n\n`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:\n\n```go\nfunc (pd *ProjectDuplicate) CanCreate(s *xorm.Session, a web.Auth) (canCreate bool, err error) {\n    pd.Project = &Project{ID: pd.ProjectID}\n    canRead, _, err := pd.Project.CanRead(s, a)\n    if err != nil || !canRead {\n        return canRead, err\n    }\n    if pd.ParentProjectID == 0 {\n        return canRead, err\n    }\n    // Parent project exists + user has write access to is (-> can create new projects)\n    parent := &Project{ID: pd.ParentProjectID}\n    return parent.CanCreate(s, a)   // <-- bug\n}\n```\n\nTwo defects compound here:\n\n1. **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`).\n\n2. **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`.\n\nNothing 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.\n\n## Impact\n\nAn authenticated user can:\n\n- 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.\n- 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.\n\nThis 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.\n\n## Proof of Concept\n\n1. As user A, create or have read access to any project `S` (e.g. id 100).\n2. Identify a parent project `P` (e.g. id 5) owned by user B, to which A has **no** access.\n3. Call `PUT /api/v1/projects/100/duplicate` with body `{\"parent_project_id\": 5}`.\n4. 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.\n\n## Affected versions\n\nIntroduced with the namespace→project migration (commit `fef253312`, first released in v0.21.0) and present through the latest release (v2.3.0). The shared model also backs the new `/api/v2` duplication route under review, so any v2 release would inherit the same flaw unless fixed in the model.\n\n## Recommended Fix\n\nIn `ProjectDuplicate.CanCreate`, check write access to the parent directly:\n\n```go\nparent := &Project{ID: pd.ParentProjectID}\nreturn parent.CanWrite(s, a)\n```\n\n`Project.CanWrite` loads the project from the database and evaluates real permissions, fixing both the wrong-method and the unhydrated-struct defects at once and matching the documented contract. (It also rejects archived parents, which is desirable.)",
  "severity" : [ {
    "type" : "CVSS_V4",
    "score" : "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "code.vikunja.io/api"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0.21.0"
      }, {
        "fixed" : "2.4.0"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 2.3.0"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-f27p-pw2p-9pr4"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/go-vikunja/vikunja/pull/3239"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/go-vikunja/vikunja/commit/d911caaa11c748c3abc6b98b3189afea2677bcb0"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/go-vikunja/vikunja"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/go-vikunja/vikunja/releases/tag/v2.4.0"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-285", "CWE-863" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-08-28T16:37:26Z",
    "nvd_published_at" : null
  }
}