CVE-2026-91984 in Vikunja
Summary
by MITRE • 09/15/2026
Vikunja before 2.6.0 fails to validate that user-supplied project_view_id in task-position requests belongs to the task's project. Authenticated attackers can insert task position rows into arbitrary other tenant project views via POST or PUT task-position endpoints.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified in Vikunja versions prior to 2.6.0 represents a critical failure in server-side object reference validation, specifically within the API endpoints responsible for managing task positioning. This flaw allows authenticated attackers to manipulate data integrity by inserting task position records into project views that do not belong to their assigned tenant or workspace. The core technical issue lies in the application's handling of the user-supplied project_view_id parameter during POST and PUT requests related to task positions. Instead of verifying that this identifier corresponds to a view associated with the specific project containing the target task, the backend logic accepts any validly formatted ID provided by the client. This lack of cross-reference validation creates an authorization bypass where the system trusts the input without confirming its logical consistency with existing database constraints or ownership models.
From a security architecture perspective, this flaw is classified under CWE-284 Improper Access Control and CWE-913 Improper Control of Dynamically-Managed Resources Identifier. The vulnerability stems from insufficient server-side validation of resource identifiers, which violates the principle of least privilege by allowing users to interact with resources outside their designated scope. In a multi-tenant SaaS environment like Vikunja, maintaining strict isolation between tenants is paramount for data privacy and security. By failing to ensure that the project_view_id matches the context of the task being modified, the application effectively breaks this isolation boundary. An attacker who has obtained valid credentials can exploit this logic error to write data into arbitrary views across different projects or even potentially other tenants if the database schema allows such cross-tenant references without proper row-level security checks.
The operational impact of this vulnerability is significant for both data integrity and potential lateral movement within the application's logical structure. Attackers can inject false task positions, leading to corrupted user interfaces where tasks appear in incorrect contexts or workflows are disrupted by misplaced items. More critically, depending on how downstream processes handle these injected records, an attacker might be able to trigger unintended side effects such as notification spam, workflow state corruption, or even privilege escalation if other parts of the application rely on task position data for access decisions. This manipulation undermines trust in the platform's reliability and exposes sensitive project structures to unauthorized modification by any authenticated user with minimal effort.
This behavior aligns closely with MITRE ATT&CK technique T1078 Valid Accounts, as it requires initial authentication but exploits a logic flaw rather than credential theft. It also relates to T1564 Hidden Files and Directories if the injected data is used to obscure legitimate activity or disrupt audit trails. The exploitation vector involves sending crafted HTTP POST or PUT requests with manipulated JSON payloads containing arbitrary project_view_id values. Since the vulnerability exists in the API layer, it can be exploited remotely over the network without requiring physical access or complex social engineering tactics beyond basic authentication acquisition.
Mitigation for this issue requires immediate patching to version 2.6.0 or later where the validation logic has been corrected. For organizations unable to upgrade immediately, implementing a Web Application Firewall rule that inspects task-position API requests and validates that the project_view_id matches an expected range associated with the authenticated user's active projects can provide temporary protection. Additionally, developers should enforce strict server-side checks for all resource identifiers in multi-tenant applications, ensuring that every request is validated against both ownership records and referential integrity constraints within the database schema to prevent similar logic flaws in other endpoints.