Vikunja, an open-source self-hosted task management platform, suffers from an improper authorization vulnerability identified as CVE-2026-33668, classified under CWE-285 (Improper Authorization) and CWE-863 (Incorrect Authorization). The vulnerability affects all versions starting from 0.18.0 up to but excluding 2.2.1. The core issue lies in inconsistent enforcement of user account status checks across different authentication mechanisms. When a user account is disabled or locked, Vikunja enforces this status only during local login and JWT token refresh processes. However, three other authentication paths—API tokens, CalDAV basic authentication, and OpenID Connect—do not verify whether the user account is disabled or locked. Consequently, users with disabled or locked accounts can continue to access the API and synchronize data via these authentication methods. This flaw allows unauthorized access to the system's API and data synchronization features, potentially exposing sensitive task management data or enabling unauthorized modifications. The vulnerability requires no user interaction and can be exploited remotely with low attack complexity, as no elevated privileges or authentication bypass beyond the existing tokens or credentials are needed. The issue was addressed and patched in Vikunja version 2.2.1, which ensures consistent user status verification across all authentication paths. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N) indicates network attack vector, low complexity, no attack or user interaction required, privileges required are low, and high impact on integrity. There are no known exploits in the wild as of the publication date. This vulnerability highlights the importance of consistent authorization checks across all authentication mechanisms in multi-protocol systems.

The vulnerability allows disabled or locked user accounts to continue accessing Vikunja's API and synchronize data, bypassing intended access restrictions. This can lead to unauthorized data access, modification, or leakage of sensitive task management information. Organizations relying on Vikunja for task and project management may face data integrity issues, unauthorized task updates, or exposure of confidential project details. The flaw undermines trust in user account status enforcement, potentially allowing malicious insiders or compromised accounts to maintain access after being disabled. This can complicate incident response and user access management. The ease of exploitation and network accessibility increase the risk of automated or targeted attacks. While no known exploits exist currently, the vulnerability's presence in widely used open-source software could attract attackers. The impact is particularly significant for organizations with strict compliance requirements or sensitive operational data managed within Vikunja. Availability is also at risk if attackers disrupt synchronization or API operations. Overall, the vulnerability poses a high risk to confidentiality, integrity, and availability of task management data.

1. Upgrade Vikunja installations to version 2.2.1 or later immediately to apply the official patch that enforces consistent user status checks across all authentication methods. 2. Audit existing API tokens and revoke any associated with disabled or locked user accounts to prevent continued unauthorized access. 3. Restrict or disable less secure authentication methods such as CalDAV basic authentication if not strictly necessary, or enforce additional access controls on these paths. 4. Implement monitoring and alerting for API access patterns that involve disabled or locked accounts, focusing on unusual synchronization or API calls. 5. Enforce strict lifecycle management of user accounts, ensuring timely disabling and token revocation upon user deactivation. 6. Consider deploying Web Application Firewalls (WAFs) or API gateways that can enforce additional authorization checks or block suspicious authentication attempts. 7. Educate administrators and users about the importance of promptly disabling accounts and revoking credentials to reduce exposure windows. 8. Review and harden OpenID Connect configurations to ensure proper user status validation is enforced at the identity provider level if possible. These mitigations, combined with patching, will reduce the risk of exploitation and limit potential damage.