CVE-2026-91983 in Vikunja
Summary
by MITRE • 09/15/2026
Vikunja before 2.6.0 contains an API token scope bypass vulnerability in task read endpoints where authorization fails to inspect query string parameters. Attackers with limited token scopes can use the expand parameter to access restricted data like comments, reactions, and time entries without proper permission verification.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/15/2026
The identified security flaw resides within the Vikunja application prior to version 2.6.0, specifically affecting the API endpoints responsible for reading task data. This vulnerability represents a critical authorization bypass that allows attackers with limited or restricted token scopes to access sensitive information beyond their permitted boundaries. The core of the issue lies in how the authentication and authorization middleware processes incoming HTTP requests. While the system correctly validates the user's identity through the provided API token, it fails to adequately inspect query string parameters when determining what data should be returned. This oversight creates a significant gap between the intended access control policies and their actual enforcement during runtime operations.
From a technical perspective, the vulnerability exploits the expand parameter commonly used in RESTful APIs to include related resources within a single response payload. In this specific implementation, developers likely assumed that if the base task resource was accessible under the current token's scope, then any associated sub-resources requested via expansion would also be implicitly authorized. However, the authorization logic does not recursively validate permissions for these nested or expanded entities such as comments, reactions, and time entries. Consequently, an attacker can append specific query parameters to a valid request URL, triggering the server to fetch and return detailed information about related objects that require higher privileges to view normally. This mechanism effectively circumvents the granular access control model designed by the application architects.
The operational impact of this vulnerability is substantial for organizations relying on Vikunja for project management and task tracking. Since comments often contain sensitive discussions, reactions may reveal user activity patterns or internal communications, and time entries can expose detailed work logs including billable hours and specific timestamps, unauthorized access to these elements compromises both confidentiality and integrity. Attackers with even minimal read permissions on tasks could potentially exfiltrate a comprehensive view of project dynamics, team interactions, and labor metrics without triggering standard security alerts associated with direct permission violations. This undermines the principle of least privilege, allowing lateral movement within the application's data structure based solely on parameter manipulation rather than brute force or credential theft.
This flaw aligns closely with CWE-284 Improper Access Control, as it involves a failure to enforce proper restrictions on an authorized user regarding access to specific resources. Furthermore, from the perspective of the MITRE ATT&CK framework, this behavior is characteristic of T1078 Valid Accounts combined with techniques for privilege escalation or data exfiltration through API abuse. The attack vector relies on exploiting misconfigured authorization logic rather than breaking encryption or compromising system integrity directly, making it a sophisticated yet straightforward exploitation path against web applications that do not rigorously validate permissions at every level of resource hierarchy.
To mitigate this vulnerability, organizations must upgrade to Vikunja version 2.6.0 or later where the issue has been addressed by implementing stricter validation logic for expanded resources. Until an update is applied, administrators should consider restricting API access through network-level controls such as firewalls or reverse proxies that limit exposure of sensitive endpoints. Additionally, auditing existing API tokens and ensuring they adhere to strict scope limitations can reduce the blast radius if exploitation occurs. Developers reviewing similar codebases should ensure that authorization checks are performed not just on top-level resources but also recursively on all nested objects requested via expansion parameters, thereby enforcing consistent access control policies across the entire data model structure.