Description

Vikunja is an open-source self-hosted task management platform. From 2.3.0 until 2.4.0, a user with Write but not Admin permission on a shared child project can detach it from its parent hierarchy by submitting parent_project_id equal to 0 to POST /api/v1/projects/{project}. The Project.CanUpdate authorization check in pkg/models/project_permissions.go and UpdateProject logic in pkg/models/project.go only gate nonzero parent values, while UpdateProject always persists parent_project_id, so the explicit zero value bypasses the Admin requirement introduced for CVE-2026-35595. Detachment severs the recursive permission-inheritance chain and can disrupt the owner’s hierarchy and inherited collaborator access. This issue is fixed in version 2.4.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-08-28T20:18:23.613Z",
  "pubdate": "2026-08-28T20:18:23.613Z",
  "executiveSummary": "Vikunja versions 2.3.0 through 2.4.0 are vulnerable to an improper authorization flaw that allows unauthorized modification of project hierarchy.\nA user with 'Write' permissions, but lacking 'Admin' privileges, can exploit this vulnerability to detach a child project from its parent hierarchy by submitting a zero-value parent_project_id.\nThis vulnerability, which bypasses security controls intended for CVE-2026-35595, effectively severs recursive permission inheritance chains.\nThe primary risk is the loss of project governance, potential unauthorized data exposure or isolation of project resources, and disruption of inherited collaborator access.\nExploitation requires authenticated access with at least 'Write' project-level permissions.\nThe issue has been remediated in version 2.4.0.",
  "technicalDetails": "The vulnerability resides in the interaction between the project permission checks in pkg/models/project_permissions.go and the project update logic in pkg/models/project.go.\nThe root cause is an inconsistent validation of the parent_project_id field when processing POST /api/v1/projects/{project} requests. While the application intends to restrict hierarchical modifications to Administrative users—a constraint introduced as a security measure for CVE-2026-35595—the logic in Project.CanUpdate only performs validation on non-zero parent_project_id values.\nWhen a user submits a parent_project_id of 0, the authorization gate effectively skips the requirement for Admin-level verification because the conditional check ignores zero-value inputs. Consequently, the UpdateProject function proceeds to execute the database persistence layer, setting the parent_project_id to 0 regardless of the user's lack of sufficient administrative privileges.\nThe attack flow proceeds as follows: 1) An attacker with 'Write' access identifies a project that is currently a child of another project. 2) The attacker crafts a request to the POST /api/v1/projects/{project} endpoint. 3) The attacker sets the payload parameter parent_project_id to 0. 4) The backend service processes the request, failing to trigger the necessary permission checks because of the zero-value exception in the validation logic. 5) The system updates the database, setting the project's parent relationship to null, thereby 'detaching' it from its parent.\nThe post-exploitation impact is significant due to the nature of permission inheritance in Vikunja. By severing the link, the project is removed from the parent hierarchy, which causes an immediate breakdown in inherited collaborator access and ownership visibility. This can lead to unauthorized data isolation, where the attacker effectively assumes control over a project that should have been managed within a restricted parent organizational structure. Because the application logic does not strictly sanitize the input when the ID is zero, this bypass allows non-privileged users to modify architectural dependencies that are critical to the platform's security model."
}