CVE-2026-35595: 
NixOS vulnerability analysis and mitigation

CVE-2026-35595 is a privilege escalation vulnerability in Vikunja, an open-source self-hosted task management platform, allowing a user with Write-level access to escalate their permissions to Admin by reparenting a shared project under a project they own. It affects all versions prior to 2.3.0 (≤ 2.2.2). The vulnerability was published on April 10, 2026, and fixed in version 2.3.0 released on April 9, 2026. It carries a CVSS v3.1 base score of 8.3 (High) (GitHub Advisory).

The root cause is improper privilege management (CWE-269) in the CanUpdate check at pkg/models/project_permissions.go:139-148, which only requires CanWrite on the new parent project when changing parent_project_id, rather than requiring Admin-level access. Vikunja's permission model uses a recursive Common Table Expression (CTE) that walks up the project hierarchy to compute permissions; when a project is reparented, the CTE resolves the attacker's ownership of the new parent as Admin (permission level 2) on the moved project. An attacker with inherited Write access (e.g., via a parent project share) can exploit this with a single authenticated API call — POST /api/v1/projects/{id} with a modified parent_project_id — to escalate to Admin on the target project. The fix moves the Admin gate into UpdateProject rather than CanUpdate, requiring Admin on both the moved project and the destination parent whenever parent_project_id is set to a non-zero value (GitHub Advisory, Fix PR).

Successful exploitation allows any authenticated user with Write permission on a shared project to escalate to full Admin on that project, enabling them to delete the project (destroying all tasks, attachments, and history), remove other users' access, and manage sharing settings. The victim loses all access to the affected project (receiving 404 responses), resulting in high confidentiality and integrity impact and low availability impact. This affects any Vikunja deployment where Write access has been shared with collaborators, making it a significant risk in multi-user or team environments (GitHub Advisory).

1. Reconnaissance: Identify a target Vikunja instance running version ≤ 2.2.2. Obtain or register an account that has been granted Write (permission=1) access to a shared project owned by a victim.
2. Enumerate project IDs: Use GET /api/v1/projects with the attacker's credentials to identify the ID of the shared child project (e.g., id=4) to which Write access was inherited.
3. Create attacker-owned root project: Send PUT /api/v1/projects with the attacker's token to create a new project under the attacker's own tree (e.g., {"title": "Attacker Root"}) and note its ID (e.g., id=5).
4. Verify initial access denial: Confirm the attacker cannot delete the target project: DELETE /api/v1/projects/4 → expected 403 Forbidden.
5. Exploit reparenting: Send POST /api/v1/projects/4 with payload {"title": "Secret Child", "parent_project_id": 5} using the attacker's token. The CanUpdate check only verifies Write on the new parent (which the attacker owns), so this returns 200 OK.
6. Achieve Admin escalation: The recursive CTE now resolves the attacker's ownership of project 5 as Admin on project 4. Send DELETE /api/v1/projects/4 → 200 OK. The victim's project is deleted and they receive 404 on subsequent access (GitHub Advisory).

• Network/API Logs: POST /api/v1/projects/{id} requests from a non-owner user that change parent_project_id to a project they own, followed shortly by DELETE /api/v1/projects/{id} returning 200 OK from the same user.
• Application Logs: Unexpected project deletion events where the deleting user is not the original project owner; audit log entries showing a project's parent changed to a project owned by a different user.
• Behavioral: A user account that previously received 403 Forbidden on project deletion suddenly succeeds with 200 OK after a reparent operation; victim users reporting sudden 404 errors on previously accessible projects.
• API Activity: Unusual sequence of PUT /api/v1/projects (create attacker root), POST /api/v1/projects/{shared_project_id} (reparent), and DELETE /api/v1/projects/{shared_project_id} within a short time window from the same authenticated session (GitHub Advisory).

Upgrade Vikunja to version 2.3.0 or later, which requires Admin permission on both the moved project and the destination parent when changing parent_project_id to a non-zero value. No configuration-based workaround is available for unpatched versions; the only effective mitigation is upgrading. Administrators should also audit project sharing settings and review API access logs for suspicious reparenting activity on shared projects (GitHub Advisory, v2.3.0 Release).

The vulnerability was discovered and reported by aisafe.io and credited to researcher adrgs. The Vikunja maintainer (kolaente) merged the fix on April 9, 2026, the same day it was reported, and released version 2.3.0 with 11 total security fixes, noting that "updating soon is highly recommended." The NixOS security tracker also flagged the issue for the nixpkgs package (v2.3.0 Release, Fix PR).