{"id":"CVE-2026-54766","aliases":[],"url":"https://o3.security/vulnerability/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.)","published":"2026-08-28T16:37:26Z","modified":"2026-08-28T16:45:06.910459595Z","cvss":null,"epss":null,"cisaKev":null,"exploitsKnown":null,"affectedPackages":[{"ecosystem":"Go","name":"code.vikunja.io/api","fixedVersion":"2.4.0"}],"fix":{"url":"https://github.com/go-vikunja/vikunja/pull/3239","label":"go-vikunja/vikunja#3239"},"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"}],"provenance":{"sources":["OSV.dev","FIRST.org (EPSS)"],"lastVerified":"2026-08-28T16:45:06.910459595Z"}}