CVE-2026-91981 in Vikunja
Summary
by MITRE • 09/15/2026
Vikunja versions before 2.6.0 fail to properly validate link-share tokens in the v2 API user search endpoints. Attackers with a read-only share link can enumerate project users via the projects endpoint and confirm arbitrary usernames exist via the global search endpoint.
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 vulnerability identified in Vikunja versions prior to 2.6.0 represents a critical authentication bypass within the application's v2 API, specifically affecting endpoints responsible for user enumeration through link-share mechanisms. The core technical flaw lies in the insufficient validation of access tokens associated with read-only shared links. While these shares are intended to grant limited visibility into specific project data, the implementation fails to enforce strict scope boundaries when processing requests against the projects endpoint and the global search functionality. This architectural oversight allows an attacker possessing a valid but restricted share token to execute queries that exceed the permissions granted by that token, effectively elevating their access privileges from read-only project viewing to broader user discovery capabilities.
From a technical perspective, this issue manifests as an Authorization Bypass through User-Controlled Key mechanism, aligning with CWE-284 in the Common Weakness Enumeration standards. The vulnerability exploits the lack of proper context checking within the API handlers for user search operations. When an authenticated request is made using a share token, the backend logic incorrectly associates this limited credential set with broader system-wide queries rather than restricting them to the specific project scope defined by the share link. Consequently, attackers can leverage the projects endpoint to list users associated with shared tasks and utilize the global search endpoint to verify the existence of arbitrary usernames within the Vikunja instance. This behavior indicates a failure in implementing proper access control checks that distinguish between resource-specific permissions and system-level administrative functions.
The operational impact of this vulnerability is significant, primarily due to its role as an information disclosure vector that facilitates further attacks. By enabling user enumeration, attackers can build accurate lists of valid usernames within the target organization or instance. This intelligence is highly valuable for subsequent credential stuffing campaigns, targeted phishing efforts known as spear-phishing, and social engineering attacks where knowledge of specific employee names increases credibility. Furthermore, confirming the existence of administrative accounts through these endpoints allows adversaries to prioritize their attack vectors against high-value targets. The ability to enumerate users without requiring full authentication credentials lowers the barrier to entry for attackers, making this vulnerability particularly dangerous in environments where weak passwords or reused credentials are prevalent among staff members.
This behavior is also consistent with ATT&CK technique T1087, Account Discovery, which describes adversaries exploring accounts and permissions within a system to identify potential targets for lateral movement or privilege escalation. In the context of Vikunja, while direct lateral movement may not be applicable in the same way as an operating system environment, the discovery phase is crucial for planning targeted attacks against specific individuals who hold sensitive data or administrative rights. The vulnerability essentially turns a collaborative task management tool into a reconnaissance platform for malicious actors seeking to map out user hierarchies and identify potential entry points within an organization's digital infrastructure.
To mitigate this risk, organizations running Vikunja must immediately upgrade to version 2.6.0 or later, where the developers have addressed the token validation logic in the affected API endpoints. Until upgrading is feasible, administrators should consider implementing network-level controls such as Web Application Firewalls that can detect and block anomalous enumeration patterns originating from share tokens. Additionally, enforcing strict password policies and multi-factor authentication for all user accounts will reduce the effectiveness of any follow-on attacks derived from this information disclosure. Regular audits of API access logs are also recommended to identify any potential exploitation attempts where unusual volumes of search requests or project listings occur via shared link credentials.