CVE-2026-62376: Vikunja: Plaintext storage of password-reset/email-confirm tokens in database enables account takeover on DB read access
Summary
Vikunja stores password-reset, email-confirmation, and account-deletion tokens in the usertokens table in plaintext. If an attacker gains read access to the database through a backup leak, misconfigured storage, or SQL-level exposure, they can immediately use pending tokens to take over user accounts without knowing passwords.
Details
pkg/user/token.go — genToken() stores the raw random string directly: go func genToken(u User, kind TokenKind) (Token, error) { tokenStr, err := utils.CryptoRandomString(tokenSize) ... return &Token{ UserID: u.ID, Kind: kind, Token: tokenStr, // stored as-is, no hashing }, nil }
Lookup also uses plaintext equality: go func getToken(s xorm.Session, token string, kind TokenKind) (t Token, err error) { has, err := s.Where("kind = ? AND token = ?", kind, token).Get(t) }
Affected token types: - TokenPasswordReset (pkg/user/userpasswordreset.go:120) - TokenEmailConfirm (pkg/user/usercreate.go:101, pkg/user/updateemail.go:88) - TokenAccountDeletion (pkg/user/delete.go:102)
Note: CalDAV tokens correctly use generateHashedToken with bcrypt — the same protection is absent for the above types.
PoC
sql -- Attacker with DB read dumps all pending password-reset tokens: SELECT u.email, t.token FROM usertokens t JOIN users u ON u.id = t.userid WHERE t.kind = 1;
-- Then takes over any account: curl -X POST https://vikunja.example.com/api/v1/user/password/reset \ -H 'Content-Type: application/json' \ -d '{"token": "<plaintextfromdb>", "newpassword": "AttackerPass1!"}'
Impact
Any read access to the database (leaked backup, cloud misconfiguration, secondary SQLi) allows an attacker to take over every user account with a pending reset token within the 24-hour token lifetime. Full account takeover including admin accounts.
Fix
Replace genToken with generateHashedToken for TokenPasswordReset, TokenEmailConfirm, and TokenAccountDeletion. Update the corresponding lookup to use bcrypt comparison (bcrypt.CompareHashAndPassword) rather than direct SQL equality, mirroring the existing CalDAV token implementation in the same file.
If possible, please apply for a CVE number when posting.
Other sources
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 usertokens table in plaintext. If an attacker gains read access to the database through a backup leak, misconfigured storage, or SQL-level exposure, they can immediately use pending tokens to take over user accounts without knowing passwords. Version 2.4.0 fixes the issue.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/code.vikunja.io/apito a version that resolves this vulnerability.Fixed in 2.4.0 - Upgrade
Upgrade
Vikunjato a version that resolves this vulnerability.Fixed in 2.4.0
Event History
Frequently Asked Questions
Who is exposed to account takeover from this issue?
Instances running a version prior to 2.4.0 are exposed if an attacker can obtain read access to the Vikunja database, such as through a leaked backup, misconfigured storage, or SQL-level exposure. Only accounts with pending password-reset, email-confirmation, or account-deletion tokens are directly affected by the disclosed token exposure.
What does an attacker need to exploit it?
The attacker needs read access to the database and access to a pending token in the user_tokens table. They do not need to know the affected user's password, and the token can be used immediately.
How can I determine whether my instance is affected?
Check the Vikunja version and whether it is earlier than 2.4.0. On affected versions, review whether database backups, storage locations, or SQL access may have exposed the user_tokens table while tokens were pending.
What should be done if an affected database may have been exposed?
Upgrade to version 2.4.0. Because pending plaintext tokens may be usable immediately after a database read exposure, treat exposed password-reset, email-confirmation, and account-deletion tokens as potentially compromised.