CVE-2026-62376 — api

Summary

Vikunja stores password-reset, email-confirmation, and account-deletion tokens in the user_tokens 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:

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:

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/user_password_reset.go:120)
• TokenEmailConfirm (pkg/user/user_create.go:101, pkg/user/update_email.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

-- Attacker with DB read dumps all pending password-reset tokens:
SELECT u.email, t.token FROM user_tokens t
JOIN users u ON u.id = t.user_id 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": "<plaintext_from_db>", "new_password": "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.