GHSA-94XM-JJ8X-3CR4
Vulnerability from github – Published: 2026-03-25 21:10 – Updated: 2026-03-25 21:10Summary
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:
- Local/LDAP login (
pkg/routes/api/v1/login.go:74) — prevents issuing new JWTs - 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.
Impact
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.
Proof of Concept
- Create a user and generate an API token.
- Disable the user account via the admin API or CLI.
- Make an API request using the API token:
bash curl -H "Authorization: Bearer tk_<token>" https://vikunja.example/api/v1/user - The request succeeds with a 200 response despite the account being disabled.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.2.0"
},
"package": {
"ecosystem": "Go",
"name": "code.vikunja.io/api"
},
"ranges": [
{
"events": [
{
"introduced": "0.18.0"
},
{
"fixed": "2.2.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33668"
],
"database_specific": {
"cwe_ids": [
"CWE-285"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-25T21:10:05Z",
"nvd_published_at": "2026-03-24T16:16:34Z",
"severity": "HIGH"
},
"details": "## Summary\n\nWhen 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 \u2014 API tokens, CalDAV basic auth, and OpenID Connect \u2014 do not verify user status, allowing disabled or locked users to continue accessing the API and syncing data.\n\n## Details\n\nUser status (`StatusDisabled`, `StatusAccountLocked`) is checked in only two places:\n\n1. **Local/LDAP login** (`pkg/routes/api/v1/login.go:74`) \u2014 prevents issuing new JWTs\n2. **JWT token refresh** (`pkg/routes/api/v1/login.go:247`) \u2014 prevents refreshing expired JWTs\n\nThree other authentication paths fetch the user from the database via `GetUserByID` but never inspect the returned user\u0027s status:\n\n### 1. API Token Authentication (`pkg/routes/api_tokens.go:76-103`)\n\nAPI tokens are long-lived (up to years) and have no refresh cycle. A disabled user\u0027s API tokens remain fully functional until they expire naturally.\n\n### 2. CalDAV Basic Auth (`pkg/routes/caldav/auth.go`)\n\nThe 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.\n\n### 3. OpenID Connect Callback (`pkg/modules/auth/openid/openid.go`)\n\nThe OIDC callback issues a fresh JWT token after validating the identity provider\u0027s response but does not check whether the Vikunja user account is disabled. If the user\u0027s identity provider session is still active, they receive a valid JWT despite being disabled in Vikunja.\n\n## Impact\n\nAn administrator who disables a user account expects that user to be immediately locked out. In practice:\n\n- **API tokens**: The user retains full API access for the remaining lifetime of any issued API tokens \u2014 potentially months or years.\n- **CalDAV**: The user can continue reading and writing tasks/events via any CalDAV client.\n- **OIDC**: The user can obtain a fresh, fully valid JWT by re-authenticating through their identity provider, completely bypassing the account disable.\n\n## Proof of Concept\n\n1. Create a user and generate an API token.\n2. Disable the user account via the admin API or CLI.\n3. Make an API request using the API token:\n ```bash\n curl -H \"Authorization: Bearer tk_\u003ctoken\u003e\" https://vikunja.example/api/v1/user\n ```\n4. The request succeeds with a 200 response despite the account being disabled.",
"id": "GHSA-94xm-jj8x-3cr4",
"modified": "2026-03-25T21:10:05Z",
"published": "2026-03-25T21:10:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-94xm-jj8x-3cr4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33668"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/commit/033922309f492996c928122fb49b691339199c35"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/commit/04704e0fde4b027039cf583110cee7afe136fc1b"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/commit/0b04768d830c80e9fde1b0962db1499cc652da0e"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/commit/fd452b9cb6457fd4f9936527a14c359818f1cca7"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-vikunja/vikunja"
},
{
"type": "WEB",
"url": "https://vikunja.io/changelog/vikunja-v2.2.2-was-released"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "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",
"type": "CVSS_V4"
}
],
"summary": "Vikunja Allows Disabled/Locked User Accounts to Authenticate via API Tokens, CalDAV, and OpenID Connect"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.