CVE-2026-35596
SQL Operator Precedence Bug in Vikunja Allows Unauthorized Label Access
Publication date: 2026-04-10
Last updated on: 2026-04-17
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| vikunja | vikunja | to 2.3.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-863 | The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability exists in Vikunja, an open-source self-hosted task management platform, in versions prior to 2.3.0. It is caused by a SQL operator precedence bug in the hasAccessToLabel function. Due to this bug, any authenticated user can read any label that has at least one task associated with it, even if they do not have access to the project that the label belongs to.
As a result, sensitive label information such as titles, descriptions, colors, and creator details can be exposed to unauthorized users. This issue was fixed in version 2.3.0.
How can this vulnerability impact me? :
The vulnerability allows any authenticated user to access label information that they should not be able to see. This can lead to unauthorized disclosure of potentially sensitive information contained in label titles, descriptions, colors, and creator information.
While the impact is limited to information disclosure (confidentiality), it does not affect the integrity or availability of the system.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, you should upgrade Vikunja to version 2.3.0 or later, where the SQL operator precedence bug in the hasAccessToLabel function has been fixed.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability in Vikunja prior to version 2.3.0 allows any authenticated user to read label metadataβincluding titles, descriptions, colors, and creator informationβof labels linked to at least one task, regardless of project access permissions. This results in unauthorized disclosure of potentially sensitive information across project boundaries.
Such unauthorized information disclosure can lead to non-compliance with data protection standards and regulations like GDPR and HIPAA, which require strict access controls and confidentiality of personal and sensitive data. Exposure of label metadata and creator user information may violate confidentiality requirements and increase the risk of data breaches.
The vulnerability is classified under CWE-863 (Incorrect Authorization), indicating a failure in enforcing proper access controls, which is a critical aspect of regulatory compliance.
The fix implemented in version 2.3.0 corrects the SQL query logic to ensure that label permissions are accurately derived only from tasks the caller can legitimately access, preventing unauthorized label data exposure and helping maintain compliance with relevant standards.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by attempting to access label information from the Vikunja API as an authenticated user without proper project access. Specifically, one can test if labels linked to tasks in inaccessible projects are exposed.
A practical approach is to enumerate label IDs and try to read their metadata (title, description, color, creator info) via API calls to see if unauthorized access is possible.
Since labels have sequential integer IDs, you can script requests to the label read endpoint and check if labels from projects you do not have access to are returned.
Example command using curl (replace <TOKEN> with your authentication token and <BASE_URL> with your Vikunja server URL):
- curl -H "Authorization: Bearer <TOKEN>" "<BASE_URL>/api/v1/labels/<LABEL_ID>"
Automate this by iterating over a range of LABEL_IDs to detect if labels from unauthorized projects are accessible.
If labels are accessible despite lack of project permissions, the system is vulnerable.