CVE-2026-111918 in Vikunja
Summary
by MITRE • 10/17/2026
Vikunja from 1.0.0-rc0 before 2.7.0 contains an improper authorization vulnerability in RecalculateTaskPositions that allows authenticated users with zero accessible projects to write task_positions rows for all tasks instance-wide. Attackers can delete their Inbox after repointing default_project_id, then create empty-filter saved filters to persist cross-tenant references and amplify writes for denial of service.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/17/2026
The vulnerability identified in Vikunja versions prior to 2.7.0 represents a critical failure in access control mechanisms within the RecalculateTaskPositions function. This flaw allows authenticated users, even those with zero accessible projects or effectively no legitimate permissions on any specific task list, to manipulate database records across the entire instance. The core technical issue lies in the insufficient validation of user privileges during the execution of position recalculation logic. Instead of restricting write operations to tasks associated with projects explicitly granted to the requesting user, the application fails to enforce proper authorization checks against the target resources. This results in a classic Broken Access Control scenario where an attacker can bypass intended security boundaries and perform actions that should be restricted based on their role or project membership status.
From a technical perspective, this improper authorization flaw enables attackers to write task_positions rows for all tasks instance-wide rather than limiting changes to authorized scopes. By exploiting the RecalculateTaskPositions endpoint, malicious actors can alter the structural ordering of tasks in databases they do not own. This capability is particularly dangerous because it allows for the manipulation of data integrity and availability without requiring elevated privileges or successful credential theft beyond initial authentication. The vulnerability effectively treats all task records as accessible to any authenticated user when this specific function is invoked, disregarding the multi-tenant isolation principles that should separate different users' project spaces.
The operational impact of this vulnerability extends beyond simple unauthorized modifications. Attackers can leverage this access control failure to execute denial-of-service attacks against other tenants or the system itself. One documented attack vector involves deleting a user's Inbox by repointing the default_project_id, which disrupts normal workflow and data visibility for legitimate users. Furthermore, attackers can create empty-filter saved filters that persist cross-tenant references. These persistent objects serve as amplification mechanisms, allowing the attacker to trigger repeated write operations or maintain stateful access points that facilitate further unauthorized modifications. This capability significantly degrades system reliability and compromises the confidentiality of task structures across different user groups.
In terms of industry standards classification, this vulnerability aligns with CWE-269 Improper Privilege Management and more specifically CWE-862 Missing Authorization. The ability to perform actions without proper permission checks is a fundamental breach in application security logic. Additionally, from the perspective of the MITRE ATT&CK framework, this behavior corresponds to T1078 Valid Accounts, as it relies on existing authentication credentials but abuses them for unauthorized access control evasion. It also reflects aspects of T1496 Resource Hijacking if used to consume system resources through amplified writes or denial-of-service conditions caused by the manipulation of task positions and filter states.
To mitigate this vulnerability, organizations running Vikunja must upgrade immediately to version 2.7.0 or later, where these access control checks have been corrected. Until an upgrade is feasible, administrators should monitor for unusual patterns in database write operations, particularly those involving the RecalculateTaskPositions endpoint from users with minimal project permissions. Implementing strict input validation and ensuring that all data modification endpoints verify ownership of the target resources against the authenticated user's permission set are essential defensive measures. Regular security audits focusing on authorization logic across multi-tenant applications can help identify similar flaws before they are exploited in production environments.