Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
4DescriptionGitHub Advisory
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.
AnalysisAI
Vikunja versions 0.18.0 through 2.2.0 contain an authentication bypass vulnerability where disabled or locked user accounts can continue accessing the system through alternative authentication mechanisms. The vulnerability affects the go-vikunja/vikunja product across all matching versions, allowing attackers with knowledge of valid but disabled account credentials to maintain API access, CalDAV synchronization, and OpenID Connect sessions despite administrative account lockdown. While no CVSS score or EPSS data is available from official sources, the vulnerability represents a critical authorization control failure (CWE-285) with high real-world impact in multi-tenant or regulated environments where account disabling is a primary access revocation mechanism.
Technical ContextAI
Vikunja implements multiple authentication pathways for user access: local login with JWT token refresh, API token authentication, CalDAV basic authentication, and OpenID Connect federation. The vulnerability stems from inconsistent security enforcement across these paths—the local login and JWT refresh mechanisms properly check user account status (enabled/disabled), but the API token, CalDAV, and OIDC authentication handlers lack equivalent validation. This is classified as CWE-285 (Improper Authorization) because the application performs authentication checks but fails to properly enforce authorization policy (account status) consistently across all code paths. The affected product is identified via CPE cpe:2.3:a:go-vikunja:vikunja:*:*:*:*:*:*:*:* and manifests as a synchronization protocol implementation flaw where alternative protocols bypass the central user status verification mechanism.
RemediationAI
Immediately upgrade Vikunja to version 2.2.1 or later, which implements consistent account status verification across all authentication pathways including API tokens, CalDAV, and OpenID Connect handlers. Refer to the GitHub Security Advisory at https://github.com/go-vikunja/vikunja/security/advisories/GHSA-94xm-jj8x-3cr4 for upgrade instructions. As an interim mitigation for critical environments where immediate upgrade is not feasible, administratively revoke API tokens for any users whose accounts have been disabled or locked, and restrict CalDAV and OIDC access through network-level controls or a reverse proxy that validates user status independently. Additionally, audit access logs for any API, CalDAV, or OIDC activity from accounts that have been disabled or locked to detect potential unauthorized access during the window before patching.
Same weakness CWE-285 – Improper Authorization
View allSame technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: High| Product | Status |
|---|---|
| openSUSE Leap 15.6 | Fixed |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Fixed |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Fixed |
| openSUSE Leap 15.5 | Fixed |
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-14913
GHSA-94xm-jj8x-3cr4