CVE-2026-35595: Vikunja Privilege Escalation Vulnerability

CVE-2026-35595 Overview

CVE-2026-35595 is a privilege escalation vulnerability affecting Vikunja, an open-source self-hosted task management platform. The vulnerability exists in the permission checking mechanism during project reparenting operations. Prior to version 2.3.0, the CanUpdate check in pkg/models/project_permissions.go only validates that a user has CanWrite permissions on the new parent project when changing parent_project_id. However, due to how Vikunja's permission model uses a recursive Common Table Expression (CTE) that traverses the project hierarchy to compute permissions, moving a project under a different parent fundamentally alters the permission inheritance chain. This allows an attacker with inherited Write access to escalate their privileges to Admin level by reparenting projects under their own project tree.

Critical Impact

Authenticated users with inherited Write access can escalate to Admin privileges on any project they can reparent, potentially gaining full control over sensitive task data and project configurations.

Affected Products

• Vikunja versions prior to 2.3.0
• Self-hosted Vikunja instances with shared project hierarchies
• Organizations using nested project structures with inherited permissions

Discovery Timeline

• 2026-04-10 - CVE CVE-2026-35595 published to NVD
• 2026-04-13 - Last updated in NVD database

Technical Details for CVE-2026-35595

Vulnerability Analysis

This privilege escalation vulnerability (CWE-269: Improper Privilege Management) stems from an authorization bypass in Vikunja's project permission handling. The core issue lies in the insufficient validation performed during project reparenting operations. When a user attempts to move a project to a different parent, the application only checks if the user has Write permissions on the target parent project, failing to account for the cascading permission changes that occur due to the recursive permission inheritance model.

Vikunja's permission system calculates user access levels by walking up the project hierarchy using a recursive CTE query. When a project's parent is changed, this fundamentally alters which permissions are inherited. An attacker who has inherited Write access from a parent project share can exploit this by moving a child project under a project tree they own. Once the project is under their ownership hierarchy, the recursive CTE resolves their ownership as Admin (permission level 2) on the moved project, effectively bypassing the intended access controls.

Root Cause

The root cause is located in pkg/models/project_permissions.go at lines 139-148, where the CanUpdate check validates only CanWrite permissions on the new parent project without considering the permission inheritance implications. The permission model's reliance on a recursive CTE to walk up the project hierarchy means that changing a project's parent fundamentally transforms which permissions apply to that project. The authorization logic fails to recognize that reparenting is not merely a structural change but a security-significant operation that can alter effective permissions.

Attack Vector

The attack exploits the network-accessible API with low complexity, requiring only authenticated access with inherited Write permissions. An attacker would:

1. Identify a project where they have inherited Write access through a parent project share
2. Create or identify a project tree where they have ownership/Admin privileges
3. Use the project update API to change the parent_project_id of the target project to point to their owned project
4. The recursive CTE now resolves the attacker's ownership of the new parent as Admin access on the moved project
5. The attacker gains full Admin control over the moved project and potentially its child projects

The vulnerability is exploited through the standard project update API endpoint by modifying the parent_project_id field. For detailed technical information, refer to the GitHub Security Advisory GHSA-2vq4-854f-5c72.

Detection Methods for CVE-2026-35595

Indicators of Compromise

• Unexpected changes to parent_project_id values in project records
• Audit logs showing project reparenting operations by users with only inherited Write access
• Users with elevated privileges on projects they previously had limited access to
• Unusual permission inheritance patterns in project hierarchies

Detection Strategies

• Monitor API calls to project update endpoints for parent_project_id modifications
• Implement logging for all project hierarchy changes with before/after permission states
• Alert on project reparenting operations where the user's permission level increases post-operation
• Review audit trails for patterns of projects being moved under user-owned project trees

Monitoring Recommendations

• Enable detailed audit logging for all project modification operations
• Track permission level changes across project hierarchy modifications
• Monitor for users accessing projects at Admin level where they previously had Write access
• Implement real-time alerting on project structural changes in sensitive project trees

How to Mitigate CVE-2026-35595

Immediate Actions Required

• Upgrade Vikunja to version 2.3.0 or later immediately
• Audit project hierarchies for unauthorized reparenting operations
• Review user permission levels on projects that have been recently moved
• Consider temporarily restricting project reparenting capabilities for non-admin users until patched

Patch Information

The vulnerability has been fixed in Vikunja version 2.3.0. The patch is available through the GitHub Release Version 2.3.0. The specific fix can be reviewed in the GitHub Commit Update and the associated GitHub Pull Request.

Workarounds

• Disable or restrict project reparenting functionality at the application or API gateway level until patching is complete
• Implement additional authorization checks at the reverse proxy level for project update operations
• Review and limit the use of inherited permissions through parent project shares
• Consider flattening project hierarchies to reduce reliance on permission inheritance

# Configuration example
# Verify current Vikunja version
vikunja version

# Upgrade to patched version 2.3.0
# For Docker deployments:
docker pull vikunja/vikunja:2.3.0
docker-compose down && docker-compose up -d

# Review audit logs for suspicious reparenting operations
grep -i "parent_project_id" /var/log/vikunja/audit.log

# Restart Vikunja service after upgrade
systemctl restart vikunja