CVE-2026-111921 in Vikunja
Summary
by MITRE • 10/17/2026
Vikunja 0.13.0 before 2.7.0 contains an incorrect authorization vulnerability that allows project members with Write permission to delete admin-tier link shares because the delete permission check reads an unloaded share object. Attackers can send DELETE requests to the v1 or v2 projects shares endpoints with sequential share IDs to revoke admin links and invalidate existing share sessions.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
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 logic, specifically categorized under CWE-862 Missing Authorization. This flaw arises from an incorrect implementation of permission checks within the application's backend architecture when handling requests related to link shares associated with projects. The core technical issue stems from the server-side processing of DELETE operations on share endpoints, where the authorization mechanism fails to properly load or validate the full context of the target resource before determining if the requesting user has sufficient privileges. In a secure implementation, any operation that modifies administrative settings or revokes high-privilege access tokens must verify that the actor possesses explicit admin-level rights for that specific project. However, in this vulnerable version, the code path responsible for deleting shares does not correctly associate the share object with its corresponding permission tier during the validation phase.
This architectural deficiency allows users who have been granted Write permissions on a project to exploit the logic gap by sending HTTP DELETE requests to either the v1 or v2 projects shares endpoints. By targeting specific share identifiers, these lower-privileged actors can bypass the intended security boundaries and successfully delete link shares that were created with admin-tier privileges. The vulnerability is particularly insidious because it does not require complex exploitation techniques; rather, it relies on a straightforward interaction with the API where attackers may need to send sequential requests if they do not already know the specific IDs of the admin-level share links. This simplicity makes automated scanning and exploitation relatively easy for malicious actors who have gained initial access to any project within the Vikunja instance.
The operational impact of this vulnerability is significant, as it directly compromises the integrity and confidentiality mechanisms provided by administrative link shares. Admin-tier link shares typically allow individuals without direct user accounts in the system to view or interact with sensitive project data under strict controls. By allowing write-permission users to revoke these links, an attacker can disrupt legitimate access for authorized external parties, leading to potential denial of service conditions for those relying on such sharing arrangements. Furthermore, invalidating existing share sessions effectively breaks ongoing workflows and may cause data loss if dependent processes rely on continuous access through these specific tokens. This erosion of trust in the permission model undermines the overall security posture of multi-tenant task management environments where granular control over external collaboration is essential.
From a threat intelligence perspective, this vulnerability aligns with ATT&CK technique T1078 Valid Accounts, as it leverages legitimate user credentials to perform unauthorized administrative actions. It also reflects aspects of T1530 Data from Information Repositories if the revoked shares were used for sensitive data distribution. To mitigate this risk, organizations running Vikunja must immediately upgrade to version 2.7.0 or later, where the authorization logic has been corrected to ensure that share deletion operations strictly validate admin-level permissions against the correct resource context. Until an update is applied, administrators should restrict write access to only those users who absolutely require it and monitor API logs for unusual patterns of DELETE requests targeting share endpoints. Implementing strict input validation and ensuring that all permission checks load the complete object state before evaluation are critical steps in preventing similar authorization bypasses in other components of the application.