CVE-2026-62376: Vikunja Token Storage Information Disclosure

CVE-2026-62376 Overview

Vikunja is an open-source self-hosted task management platform. Versions prior to 2.4.0 store password-reset, email-confirmation, and account-deletion tokens in the user_tokens database table in plaintext. An attacker who gains read access to the database through a backup leak, misconfigured storage, or SQL-level exposure can immediately use pending tokens to take over user accounts without knowing passwords. The flaw is tracked as [CWE-312: Cleartext Storage of Sensitive Information]. Vikunja version 2.4.0 fixes the issue by hashing these tokens at rest.

Critical Impact
Any read-only exposure of the Vikunja database allows attackers to hijack accounts by replaying unhashed password-reset, email-confirmation, and account-deletion tokens.

Affected Products

Vikunja self-hosted task management platform, all versions prior to 2.4.0
The user_tokens table in Vikunja's database schema
Deployments exposing Vikunja database backups or snapshots to third parties

Discovery Timeline

2026-10-09 - CVE-2026-62376 published to the National Vulnerability Database (NVD)
2026-10-16 - Last updated in NVD database

Technical Details for CVE-2026-62376

Vulnerability Analysis

Vikunja issues short-lived tokens for three sensitive account workflows: password reset, email confirmation, and account deletion. In vulnerable versions, these tokens are generated and persisted directly to the user_tokens table without hashing. Because the stored value equals the value sent to the user by email, anyone with read access to that row can replay the token against the Vikunja API and complete the corresponding workflow.

The practical consequence is full account takeover against users with a pending reset or deletion request. Attackers never need the victim's password or email credentials. Exploitation does require database read access, which raises attack complexity, but common exposure paths include leaked backups, misconfigured object storage, SQL injection in adjacent components, and shared-hosting snapshots.

Root Cause

The root cause is a design decision in pkg/models/sessions.go and the user deletion flow in pkg/user/delete.go, where token values were persisted using the same string that was emailed to the user. The patch in commit 3a0ea15d reworks token handling so the database stores only a sha256 digest while the plaintext (ClearTextToken) is used solely for the outbound notification.

Attack Vector

An attacker with read access to the Vikunja database queries the user_tokens table for unexpired entries. Each row contains a token kind (reset, confirm, delete) and the exact value the Vikunja API expects. The attacker submits the token to the matching endpoint and gains control over the targeted account.

// Patch excerpt: pkg/user/delete.go
// Before the fix, the raw stored token was emailed to the user, meaning
// the database value and the confirmation link value were identical.
return notifications.Notify(user, &AccountDeletionConfirmNotification{
    User:         user,
-   ConfirmToken: token.Token,
+   ConfirmToken: token.ClearTextToken,
}, s)

Source: Vikunja Commit 3a0ea15d

Detection Methods for CVE-2026-62376

Indicators of Compromise

Unexpected successful password-reset or account-deletion confirmations for users who did not initiate them.
Authentication events immediately following a token redemption from an unfamiliar IP address or user agent.
Access to database backups, snapshots, or storage buckets containing the user_tokens table that cannot be attributed to a known administrator.
Rows in user_tokens whose values match tokens appearing in web request logs for /api/v1/user/password/reset or related endpoints.

Detection Strategies

Audit application logs for password-reset or account-deletion flows that complete without a preceding user-initiated request.
Correlate database export, backup, or replication events with subsequent token-redemption API calls.
Review access logs on object storage holding Vikunja database dumps for unauthorized GET requests.

Monitoring Recommendations

Alert on any read access to database backups outside the scheduled maintenance window.
Monitor the Vikunja API for high-rate requests to /api/v1/user/password/token and /api/v1/user/confirm endpoints.
Track account state transitions (deletion requested, email changed, password reset) and surface anomalies to the security team.

How to Mitigate CVE-2026-62376

Immediate Actions Required

Upgrade Vikunja to version 2.4.0 or later, which hashes tokens at rest and includes the migration that clears existing plaintext tokens.
Invalidate all pending password-reset, email-confirmation, and account-deletion tokens if the database may have been exposed.
Rotate database credentials and audit who has had read access to database backups since the vulnerable version was deployed.
Notify users and require password resets for any account that had a pending token during the exposure window.

Patch Information

The fix is delivered in Vikunja release v2.4.0. The relevant commits are 00fd2c6155, which adds migration 20260719145922 to clear existing plaintext tokens, and 3a0ea15d8c, which hashes new tokens using SHA-256 before storing them. Full details are in GitHub Security Advisory GHSA-r6w9-259g-gwrv.

Workarounds

Restrict network and filesystem access to the Vikunja database to only the application host and trusted operators.
Encrypt database backups at rest and enforce strict access controls on the storage location.
Manually truncate the user_tokens table during maintenance to minimize the window of exposure until the upgrade is complete.

bash

# After upgrading to v2.4.0, verify the migration ran and the
# user_tokens table no longer contains plaintext values.
sqlite3 vikunja.db "SELECT id, kind, length(token) FROM user_tokens;"

# Expected: token length matches the SHA-256 hex digest (64 chars),
# not the shorter plaintext token length used in versions < 2.4.0.