Compliance Impact

This vulnerability allows a user with Write permission on a shared project to escalate their privileges to Admin by reparenting the project under their own project tree. This unauthorized privilege escalation can lead to deletion of projects, management of sharing settings, and removal of other users' access.

Such unauthorized access and control over project data could potentially lead to violations of data protection regulations like GDPR and HIPAA, which require strict access controls and protection of sensitive information. The ability to delete projects and revoke access without proper authorization undermines compliance with these standards' requirements for data integrity, confidentiality, and accountability.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability involves a privilege escalation through reparenting projects in Vikunja when a user with Write permission changes the parent_project_id to a project they own, gaining Admin privileges. Detection involves monitoring for unauthorized or suspicious API calls that update the parent_project_id field of projects.

Specifically, you can look for POST or PATCH requests to the project update endpoint that include changes to the parent_project_id attribute, especially those made by users who only have Write permissions but not Admin.

Suggested commands or methods to detect this activity include:

• Inspect web server or application logs for HTTP requests updating projects with parent_project_id changes.
• Use network monitoring tools (e.g., tcpdump, Wireshark) to filter HTTP traffic for POST or PATCH requests to the project update API endpoints containing parent_project_id fields.
• Example command to search logs for such requests (assuming logs contain JSON or text with parent_project_id):
• grep -i 'parent_project_id' /path/to/vikunja/logs/access.log
• If using curl or API testing, verify if users with Write permission can successfully update parent_project_id by attempting a request like:
• curl -X POST -H "Authorization: Bearer <token>" -d '{"parent_project_id": <new_parent_id>}' https://<vikunja-server>/api/projects/<project_id>

Monitoring for unexpected permission escalations or project deletions following such reparenting actions can also help detect exploitation attempts.

Useful 0 Not Useful 0

Executive Summary

This vulnerability exists in Vikunja, an open-source self-hosted task management platform, prior to version 2.3.0. It involves the permission check when changing the parent project of a task. Specifically, the CanUpdate check only requires the user to have write permission on the new parent project. However, because Vikunja uses a recursive query to compute permissions up the project hierarchy, moving a project under a different parent changes the permission inheritance chain.

If a user has inherited write access from a parent project share and moves a child project under their own project tree, the system incorrectly resolves their ownership of the new parent as Admin on the moved project. This effectively escalates their permissions on that project.

This flaw was fixed in version 2.3.0 of Vikunja.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can lead to unauthorized privilege escalation. A user with inherited write access can gain admin-level permissions on a project by moving it under their own project tree. This elevated access allows them to modify, control, or potentially delete project data beyond their intended permissions.

Such unauthorized access can compromise the integrity and confidentiality of project data, potentially leading to data loss, unauthorized changes, or exposure of sensitive information.

Useful 0 Not Useful 0

Mitigation Strategies

To mitigate this vulnerability, upgrade Vikunja to version 2.3.0 or later, where the issue has been fixed.

Useful 0 Not Useful 0