All vulnerabilities
CVE-2026-62376GHSA-r6w9-259g-gwrvGO-2026-6748

code.vikunja.io/api: Vikunja: Plaintext storage of password-reset/email-confirm tokens in database enables account takeover on DB read access

go-vikunja code.vikunja.io/apigoLibraries & packages
CVSS
8.1High
ExploitationPublic exploit codeCISA's assessment says proof of concept code is public, assessed 13 Oct 2026. Not in the KEV catalogCISA via CVE List
Exploit odds (EPSS)0.21%Chance of exploitation activity in the next 30 days, higher than 11% of CVEs. Scored 23 Oct 2026FIRST EPSS
Fixed in2.4.0Fixed versionGitHub
Published9 Oct 2026Updated 19 Oct 2026CVE List

What fixes it

  • 2.4.0code.vikunja.io/api, goGitHubgo get code.vikunja.io/api@v2.4.0
  • 2.4.0code.vikunja.io/api, GoOSVgo get code.vikunja.io/api@v2.4.0

A fixed version on one release line is not the upgrade target for every line. Check your exact version and any vendor backports.

Description

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.

Text from GitHub Advisory Database

Affected versions 3

  • code.vikunja.io/api, go<= 2.3.0GitHub
  • vikunjaaffected: < 2.4.0CVE List
  • code.vikunja.io/api, Gofrom first release, fixed in 2.4.0OSV

References 6