GHSA-r6w9-259g-gwrv: SQL Injection
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.
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 - Compensating control
For TokenPasswordReset, TokenEmailConfirm, and TokenAccountDeletion, replace genToken with generateHashedToken so tokens are stored hashed, and update getToken lookup to use bcrypt.CompareHashAndPassword instead of direct SQL token equality, mirroring the existing CalDAV token implementation.