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.

Affected: Go: code.vikunja.io/api

## Summary

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 s…