Between versions 2.3.0 and 2.4.0, Vikunja allowed a user with Write permissions on a shared child project, but not Admin, to remove that project from its parent hierarchy by sending a POST request to /api/v1/projects/{project} with parent_project_id set to zero. The permission check in Project.CanUpdate only rejects non‑zero parent values while the UpdateProject function writes the parent_project_id regardless of its content, allowing the write‑only user to bypass the intended Admin requirement. The action severs the recursive permission‑inheritance chain, disrupting the owner’s hierarchy and inherited collaborator access, and is identified as a CWE‑862 authorization bypass.

This weakness exists in the open‑source self‑hosted task management platform Vikunja, implemented in the go‑vikunja:vikunja codebase. All releases from 2.3.0 up through (but not including) 2.4.0 are affected. Any instance running those versions is potentially vulnerable.

The CVSS score of 4.3 reflects moderate severity, corresponding to an exploit that requires authenticated access with Write permissions on a child project. The EPSS score is not available, and the vulnerability is not listed in CISA's KEV catalog, suggesting limited documented exploitation. Attackers, however, can trigger this behavior by sending a crafted POST request to the project update endpoint with parent_project_id=0, resulting in unauthorized detachment of the project and loss of inherited permissions. Because the action requires pre‑existing Write access, the risk is mitigated by restricting those permissions; nonetheless, any write‑level user on a shared child project could potentially use this vector.