CVE-2026-33668

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.

Details

User status (StatusDisabled, StatusAccountLocked) is checked in only two places:

1. Local/LDAP login (pkg/routes/api/v1/login.go:74), prevents issuing new JWTs
2. JWT token refresh (pkg/routes/api/v1/login.go:247), prevents refreshing expired JWTs

Three other authentication paths fetch the user from the database via GetUserByID but never inspect the returned user's status:

1. API Token Authentication (pkg/routes/api_tokens.go:76-103)

API tokens are long-lived (up to years) and have no refresh cycle. A disabled user's API tokens remain fully functional until they expire naturally.

2. CalDAV Basic Auth (pkg/routes/caldav/auth.go)

The CalDAV basic auth handler validates credentials but does not check user status before granting access. A disabled user with valid credentials or a CalDAV token can continue syncing calendars and tasks.

3. OpenID Connect Callback (pkg/modules/auth/openid/openid.go)

The OIDC callback issues a fresh JWT token after validating the identity provider's response but does not check whether the Vikunja user account is disabled. If the user's identity provider session is still active, they receive a valid JWT despite being disabled in Vikunja.

Proof of Concept

1. Create a user and generate an API token.
2. Disable the user account via the admin API or CLI.
3. Make an API request using the API token:

   curl -H "Authorization: Bearer tk_<token>" https://vikunja.example/api/v1/user
   

4. The request succeeds with a 200 response despite the account being disabled.

An administrator who disables a user account expects that user to be immediately locked out. In practice:

• API tokens: The user retains full API access for the remaining lifetime of any issued API tokens, potentially months or years.
• CalDAV: The user can continue reading and writing tasks/events via any CalDAV client.
• OIDC: The user can obtain a fresh, fully valid JWT by re-authenticating through their identity provider, completely bypassing the account disable.

Kodem intelligence

1. What is CVE-2026-33668? CVE-2026-33668 is a high-severity security vulnerability in code.vikunja.io/api (go), affecting versions >= 0.18.0, <= 2.2.0. It is fixed in 2.2.1.
2. Which versions of code.vikunja.io/api are affected by CVE-2026-33668? code.vikunja.io/api (go) versions >= 0.18.0, <= 2.2.0 is affected.
3. Is there a fix for CVE-2026-33668? Yes. CVE-2026-33668 is fixed in 2.2.1. Upgrade to this version or later.
4. Is CVE-2026-33668 exploitable, and should I be worried? Whether CVE-2026-33668 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
5. What actually determines whether CVE-2026-33668 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
6. How do I fix CVE-2026-33668? Upgrade code.vikunja.io/api to 2.2.1 or later.