| Package | Affected versions | Patched versions |
|---|---|---|
| code.vikunja.io/api | ≥ 0.18.0, < 2.2.1≥ 0.18.0 | 2.2.1 |
| vikunja | ≥ 0.18.0, < 2.2.1 | 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.
User status (StatusDisabled, StatusAccountLocked) is checked in only two places:
pkg/routes/api/v1/login.go:74) — prevents issuing new JWTspkg/routes/api/v1/login.go:247) — prevents refreshing expired JWTsThree other authentication paths fetch the user from the database via GetUserByID but never inspect the returned user's status:
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.
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.
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.
An administrator who disables a user account expects that user to be immediately locked out. In practice:
curl -H "Authorization: Bearer tk_<token>" https://vikunja.example/api/v1/user
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site free