CVE-2026-33668: Vikunja Auth Bypass Vulnerability

CVE-2026-33668 Overview

CVE-2026-33668 is an authentication bypass vulnerability in Vikunja, an open-source self-hosted task management platform. The vulnerability exists in versions 0.18.0 through 2.2.0, where user account status checks (disabled or locked) are inconsistently enforced across different authentication mechanisms. While local login and JWT token refresh paths properly verify user status, three other authentication paths—API tokens, CalDAV basic auth, and OpenID Connect—fail to validate whether a user account is disabled or locked, allowing unauthorized continued access.

Critical Impact

Disabled or locked user accounts can continue accessing the Vikunja API and syncing data through API tokens, CalDAV basic auth, or OpenID Connect authentication, completely bypassing account restrictions intended to revoke access.

Affected Products

• Vikunja versions 0.18.0 through 2.2.0
• Vikunja installations using API token authentication
• Vikunja installations with CalDAV or OpenID Connect enabled

Discovery Timeline

• 2026-03-24 - CVE-2026-33668 published to NVD
• 2026-03-25 - Last updated in NVD database

Technical Details for CVE-2026-33668

Vulnerability Analysis

This vulnerability is classified under CWE-285 (Improper Authorization), which occurs when an application fails to properly enforce access control restrictions. In Vikunja's case, the authorization logic for checking user account status was implemented inconsistently across different authentication entry points.

When administrators disable or lock a user account in Vikunja, the expectation is that the user immediately loses all access to the platform. However, the status verification was only implemented on two authentication paths: local login and JWT token refresh. This creates a significant security gap where users with pre-existing API tokens, CalDAV credentials, or valid OpenID Connect sessions can continue operating as if their accounts were never restricted.

The vulnerability is particularly concerning in enterprise environments where account disabling is often used as part of employee offboarding procedures or incident response workflows. A terminated employee or compromised account could potentially continue exfiltrating task data, project information, and other sensitive content stored in Vikunja.

Root Cause

The root cause of this vulnerability is an incomplete implementation of user status validation across Vikunja's authentication middleware. The developers implemented account status checks for the primary authentication flow (local login and JWT refresh) but failed to apply the same validation logic to alternative authentication mechanisms.

Specifically, the API token authentication handler, CalDAV basic auth handler, and OpenID Connect callback handler were missing the necessary calls to verify that the authenticated user's account is in an active, unlocked state before granting access to protected resources.

Attack Vector

The attack vector for this vulnerability requires network access and low-privilege authentication. An attacker or former authorized user would need to have obtained valid authentication credentials through one of the vulnerable paths before their account was disabled. The attack scenario typically unfolds as follows:

A user with a valid API token, CalDAV configuration, or active OpenID Connect session has their account disabled by an administrator. Despite the account being marked as disabled or locked in Vikunja's user management system, the user can continue making authenticated API requests, syncing CalDAV calendars, or maintaining their OpenID Connect session. This allows continued read and write access to tasks, projects, and other data the user had permissions to access.

The vulnerability does not require user interaction and can be exploited remotely over the network. The impact is primarily on data integrity, as unauthorized users can continue modifying data they should no longer have access to.

Detection Methods for CVE-2026-33668

Indicators of Compromise

• API requests from users whose accounts are marked as disabled or locked in the database
• CalDAV sync activity (PROPFIND, REPORT, PUT, DELETE requests) from disabled user accounts
• OpenID Connect authenticated sessions for users who should have been revoked
• Audit log entries showing data modifications by users after their account status changed to disabled

Detection Strategies

• Implement log correlation between Vikunja authentication logs and user status change events to identify access after account lockout
• Monitor for API token usage patterns that continue after administrative account status changes
• Review CalDAV access logs for activity from accounts that were recently disabled
• Audit OpenID Connect session tokens against current user account status in Vikunja

Monitoring Recommendations

• Enable verbose authentication logging in Vikunja to capture all authentication method usage
• Set up alerting for any successful authentication events from users marked as disabled in the user management system
• Periodically audit active API tokens and CalDAV configurations against current user account status
• Implement real-time monitoring of authentication events with correlation to user status database records

How to Mitigate CVE-2026-33668

Immediate Actions Required

• Upgrade Vikunja to version 2.2.1 or later immediately
• Revoke all API tokens for users whose accounts have been disabled or locked
• Invalidate CalDAV credentials for disabled user accounts
• Review OpenID Connect configurations and ensure session revocation is properly synchronized
• Audit access logs to identify any unauthorized access that may have occurred through the vulnerable authentication paths

Patch Information

Vikunja version 2.2.1 addresses this vulnerability by implementing consistent user status validation across all authentication mechanisms. The fix ensures that API token authentication, CalDAV basic auth, and OpenID Connect authentication all verify that the user account is active and unlocked before granting access.

Multiple commits address this issue, including fixes documented in the GitHub Security Advisory GHSA-94xm-jj8x-3cr4. The Vikunja v2.2.2 release changelog provides additional information about the security improvements.

Workarounds

• Manually revoke all API tokens for any disabled or locked user accounts
• Disable CalDAV integration temporarily if immediate patching is not possible
• Configure your identity provider to revoke OpenID Connect sessions when Vikunja account status changes
• Implement network-level access controls to restrict API access from known disabled user IP addresses
• Monitor authentication logs closely until the patch can be applied

# Configuration example
# Verify your Vikunja version and upgrade if vulnerable
vikunja version
# Expected output should show 2.2.1 or higher

# Review current API tokens in the database for disabled users
# (PostgreSQL example - adjust for your database)
psql -d vikunja -c "SELECT u.username, t.token_id, t.created 
FROM api_tokens t 
JOIN users u ON t.owner_id = u.id 
WHERE u.status != 'active';"

# After upgrading, restart the Vikunja service
systemctl restart vikunja