CVE-2026-54766

Vikunja has a project duplication bypasses write-permission check on the target parent project

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
}

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.

The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions. Typical impact: unauthorized data access or execution of privileged operations.

Kodem intelligence

Already deployed Kodem?

In ProjectDuplicate.CanCreate, check write access to the parent directly:

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.)

1. What is CVE-2026-54766? CVE-2026-54766 is a medium-severity incorrect authorization vulnerability in code.vikunja.io/api (go), affecting versions >= 0.21.0, <= 2.3.0. It is fixed in 2.4.0. The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions.
2. Which versions of code.vikunja.io/api are affected by CVE-2026-54766? code.vikunja.io/api (go) versions >= 0.21.0, <= 2.3.0 is affected.
3. Is there a fix for CVE-2026-54766? Yes. CVE-2026-54766 is fixed in 2.4.0. Upgrade to this version or later.
4. Is CVE-2026-54766 exploitable, and should I be worried? Whether CVE-2026-54766 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
5. What actually determines whether CVE-2026-54766 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
6. How do I fix CVE-2026-54766? Upgrade code.vikunja.io/api to 2.4.0 or later.