CVE-2026-33668
Received Received - Intake
Improper Authentication in Vikunja Allows Disabled Users API Access

Publication date: 2026-03-24

Last updated on: 2026-03-27

Assigner: GitHub, Inc.

Description
Vikunja is an open-source self-hosted task management platform. Starting in version 0.18.0 and prior to version 2.2.1, when a user account is disabled or locked, the status check is only enforced on the local login and JWT token refresh paths. Three other authentication paths β€” API tokens, CalDAV basic auth, and OpenID Connect β€” do not verify user status, allowing disabled or locked users to continue accessing the API and syncing data. Version 2.2.1 patches the issue.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-24
Last Modified
2026-03-27
Generated
2026-05-07
AI Q&A
2026-03-24
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
vikunja vikunja From 0.18.0 (inc) to 2.2.1 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-285 The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.
CWE-863 The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2026-33668 is a security vulnerability in the Vikunja open-source task management platform affecting versions from 0.18.0 up to 2.2.0. The issue arises because when a user account is disabled or locked, the system only enforces this status check during local login and JWT token refresh. However, three other authentication methodsβ€”API tokens, CalDAV basic authentication, and OpenID Connectβ€”do not verify if the user is disabled or locked. This allows disabled or locked users to continue accessing the API and syncing data, effectively bypassing account restrictions.

The root cause is that the user status checks were missing or incomplete in these authentication paths, allowing unauthorized access. The vulnerability was fixed in version 2.2.1 by adding explicit checks for disabled or locked user status in all authentication methods, ensuring that such users are rejected by default.


How can this vulnerability impact me? :

[{'type': 'paragraph', 'content': 'This vulnerability can have significant security impacts by allowing disabled or locked user accounts to continue accessing the system through API tokens, CalDAV synchronization, and OpenID Connect authentication. Specifically:'}, {'type': 'list_item', 'content': 'Disabled or locked users can still make API requests using previously issued API tokens, which may remain valid for long periods.'}, {'type': 'list_item', 'content': 'Such users can continue syncing calendars and tasks via CalDAV basic authentication without restriction.'}, {'type': 'list_item', 'content': 'Users can re-authenticate via OpenID Connect and obtain valid JWT tokens despite their account being disabled or locked.'}, {'type': 'paragraph', 'content': "This means administrators' attempts to immediately lock out users by disabling accounts are ineffective, potentially leading to unauthorized access, data leakage, or misuse of system resources."}] [4]


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

[{'type': 'paragraph', 'content': 'This vulnerability involves disabled or locked user accounts still being able to authenticate and access the system via API tokens, CalDAV basic authentication, and OpenID Connect, bypassing intended restrictions.'}, {'type': 'paragraph', 'content': 'To detect this vulnerability on your system, you should monitor authentication attempts and API usage for disabled or locked user accounts. Specifically, check if API tokens or CalDAV requests are succeeding for users whose accounts have been disabled or locked.'}, {'type': 'paragraph', 'content': 'Suggested commands or approaches include:'}, {'type': 'list_item', 'content': "Query your Vikunja database or user management system to list users with status 'disabled' or 'locked'."}, {'type': 'list_item', 'content': 'Monitor API logs for requests authenticated with API tokens belonging to disabled or locked users.'}, {'type': 'list_item', 'content': 'Check CalDAV authentication logs for successful authentications by disabled or locked users.'}, {'type': 'list_item', 'content': 'Review OpenID Connect authentication logs to verify if disabled or locked users are obtaining JWT tokens.'}, {'type': 'paragraph', 'content': 'Since the vulnerability is related to missing user status checks in certain authentication paths, you can also test by attempting to authenticate using API tokens, CalDAV, or OIDC with a disabled or locked user account and observe if access is granted.'}] [4, 2]


What immediate steps should I take to mitigate this vulnerability?

The immediate and recommended 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 paths.

Until the upgrade can be applied, consider the following steps:

  • Manually revoke or expire API tokens for disabled or locked users to prevent continued API access.
  • Temporarily disable or restrict CalDAV and OpenID Connect authentication mechanisms if possible.
  • Monitor and audit authentication logs to detect and block unauthorized access by disabled or locked accounts.

These steps help reduce the risk of unauthorized access while awaiting the official patch.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart