Vikunja is an open-source, self-hosted task management platform that supports multiple authentication methods including local login, JWT token refresh, API tokens, CalDAV basic authentication, and OpenID Connect. CVE-2026-33668 is an improper authorization vulnerability classified under CWE-285 (Improper Authorization) and CWE-863 (Incorrect Authorization). The vulnerability exists in versions from 0.18.0 up to 2.2.1, where the system enforces user account status checks (such as disabled or locked states) only during local login and JWT token refresh authentication flows. However, three other authentication paths—API tokens, CalDAV basic auth, and OpenID Connect—do not verify whether a user account is disabled or locked. This oversight allows users whose accounts have been disabled or locked to continue accessing the API and synchronizing data through these alternative authentication methods. The vulnerability is remotely exploitable without user interaction or prior authentication (low privileges are required), and it can lead to unauthorized access to sensitive task management data, potentially impacting confidentiality and integrity. The CVSS 4.0 score is 7.1 (high severity), reflecting network attack vector, low attack complexity, no privileges required, no user interaction, and high impact on integrity. The issue was publicly disclosed on March 24, 2026, and fixed in Vikunja version 2.2.1 by enforcing user status verification consistently across all authentication methods.

This vulnerability allows disabled or locked user accounts to bypass intended access restrictions via API tokens, CalDAV basic auth, and OpenID Connect authentication methods. Organizations relying on Vikunja for task and project management could face unauthorized data access, leading to potential exposure of sensitive project information, unauthorized modifications, or data synchronization with compromised accounts. This undermines the integrity and confidentiality of organizational data. Since the flaw affects multiple authentication methods, attackers or malicious insiders could maintain persistent access even after account disabling or locking, complicating incident response and remediation efforts. The vulnerability could also facilitate lateral movement within an organization’s infrastructure if Vikunja is integrated with other systems. Although no known exploits are reported in the wild yet, the low complexity and remote exploitability make this a significant risk for organizations using affected versions.

The primary mitigation is to upgrade Vikunja to version 2.2.1 or later, where the vulnerability is patched by enforcing user status checks across all authentication methods. Until upgrade is possible, organizations should consider disabling or restricting the use of API tokens, CalDAV basic auth, and OpenID Connect authentication methods to prevent bypass of user status checks. Implement monitoring and alerting on unusual API token usage or synchronization activity from disabled or locked accounts. Review and tighten user account management policies to ensure timely disabling and auditing of accounts. Employ network segmentation and access controls to limit Vikunja API exposure. Additionally, conduct regular security assessments and penetration testing focused on authentication and authorization mechanisms to detect similar weaknesses.