CVE-2026-111919 in Vikunja
Summary
by MITRE • 10/17/2026
Vikunja 0.22.0 before 2.7.0 contains an improper access revocation vulnerability that allows removed collaborators to keep receiving project data through webhooks they created. Former collaborators keep receiving task titles and descriptions through their webhook, including content created after their access was revoked.
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 identified security flaw in Vikunja versions prior to 2.7.0 represents a critical failure in the lifecycle management of user permissions and associated system integrations. Specifically, this vulnerability falls under the category of Improper Access Revocation, which is formally classified as CWE-613 in the Common Weakness Enumeration standard. This type of flaw occurs when an application fails to properly remove or disable access controls for a user who has had their privileges revoked, leading to unauthorized continued access to sensitive resources. In this specific instance, the vulnerability manifests within the webhook subsystem, which is designed to allow external services to receive real-time notifications about changes in project data.
The technical root cause lies in the persistence of active webhook endpoints associated with users whose accounts or collaborator status have been terminated by an administrator. When a user is removed as a collaborator from a Vikunja project, the system correctly updates their access rights for direct interactions such as viewing tasks or editing content. However, the backend logic fails to invalidate or disable any webhooks that were previously registered and activated by that specific user account. Consequently, these dormant webhook endpoints remain active in the server's event dispatching mechanism, continuing to trigger on project events just as they did when the user was an authorized collaborator.
The operational impact of this vulnerability is significant for organizations relying on Vikunja for task management and data privacy compliance. Former collaborators continue to receive HTTP POST requests containing sensitive project information, including task titles, descriptions, and potentially other metadata depending on configuration settings. This means that even after a user has been explicitly removed from the system due to role changes or security concerns, they retain an indirect channel through which they can monitor ongoing activities within the project. For teams handling confidential business strategies, personal data, or regulated information, this constitutes a serious confidentiality breach as it allows ex-employees or unauthorized actors to maintain surveillance over active workflows without their knowledge or consent.
This behavior also aligns with aspects of the MITRE ATT&CK framework, particularly techniques related to Exfiltration Over Alternative Protocol and Collection via Webhooks. Attackers who have previously gained legitimate access could create webhooks before being detected or removed, ensuring that they retain a persistent backdoor for data exfiltration even after their primary credentials are disabled. This persistence mechanism undermines the effectiveness of standard incident response procedures that focus solely on credential revocation without auditing associated integrations and automated notifications.
To mitigate this vulnerability, administrators must upgrade to Vikunja version 2.7.0 or later, where the issue has been resolved by ensuring that webhook endpoints are automatically disabled when a user is removed from a project or their account is deactivated. In environments running older versions prior to an immediate patch deployment, manual intervention is required. Administrators should audit existing webhooks and manually delete any entries associated with users who no longer have active permissions within the system. Additionally, implementing strict monitoring of webhook traffic can help detect anomalous activity from deprecated endpoints until a permanent fix is applied. Regular reviews of integration points and automated notification systems are essential to prevent similar access control failures in other modules of the application.