CVE-2026-35595
Permission Escalation in Vikunja via Project Reparenting Flaw
Publication date: 2026-04-10
Last updated on: 2026-04-17
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| vikunja | vikunja | to 2.3.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-269 | The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
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.
How can this vulnerability impact me? :
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.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, upgrade Vikunja to version 2.3.0 or later, where the issue has been fixed.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
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.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
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.