Skip to content

GHSA-r6w9-259g-gwrv CVE-2026-62376 GO-2026-6748

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

High Go
Severity
8.1 / 10
High · CVSS 3.1
Exploit chance (EPSS)
0.28%
Chance of exploitation in the next 30 days. Higher than 20.02% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-312 Cleartext Storage of Sensitive Information
CWE-916 Use of Password Hash With Insufficient Computational Effort
Fix
2.4.0
Upgrade code.vikunja.io/api to this version or later

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.

Affected versions

Go

PackageVulnerableFixed in
code.vikunja.io/api
< 2.4.0
2.4.0
code.vikunja.io/api
all versions
No fix yet

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

code.vikunja.io/api Go → 2.4.0

go
go get code.vikunja.io/api@v2.4.0 && go mod tidy

Severity breakdown

CVSS 3.1 8.1

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Attack vector
Network
Attack complexity
High
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Weakness

CWE-312: Cleartext Storage of Sensitive Information

The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.

How to prevent it
  • Implementation, System Configuration, Operation: When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to encrypt the data at rest. [REF-1297] [REF-1299] [REF-1301]
  • Implementation, System Configuration, Operation: In some systems/environments such as cloud, the use of "double encryption" (at both the software and hardware layer) might be required, and the developer might be solely responsible for both layers, instead of shared responsibility with the administrator of the broader system/environment.

CWE-916: Use of Password Hash With Insufficient Computational Effort

The product generates a hash for a password, but it uses a scheme that does not provide a sufficient level of computational effort that would make password cracking attacks infeasible or expensive.

How to prevent it
  • Architecture and Design: Use an adaptive hash function that can be configured to change the amount of computational effort needed to compute the hash, such as the number of iterations ("stretching") or the amount of memory required. Some hash functions perform salting automatically. These functions can significantly increase the overhead for a brute force attack compared to intentionally-fast functions such as MD5. For example, rainbow table attacks can become infeasible due to the high computing overhead. Finally, since computing power gets faster and cheaper over time, the technique can be reconfigured to increase the workload without forcing an entire replacement of the algorithm in use. Some hash functions that have one or more of these desired properties include bcrypt [REF-291], scrypt [REF-292], and PBKDF2 [REF-293]. While there is active debate about which of these is the most effective, they are all stronger than using salts with hash functions with very little computing overhead. Note that using these functions can have an impact on performance, so they require special consideration to avoid denial-of-service attacks. However, their configurability provides finer control over how much CPU and memory is used, so it could be adjusted to suit the environment's needs.
  • Implementation, Architecture and Design: When using industry-approved techniques, use them correctly. Don't cut corners by skipping resource-intensive steps (CWE-325). These steps are often essential for preventing common attacks.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-m687-p538-r5hp
Vikunja: Permissive Cross-domain Security Policy trusts every localhost origin which should not be trusted
Medium Also affects code.vikunja.io/api
GHSA-fmmf-xq98-g327
Vikunja: Write-level project members can delete admin-tier link shares through an unloaded permission check
Medium Also affects code.vikunja.io/api
GHSA-pjr3-86v4-5p7w
Vikunja: Explicit lower-permission share on a sub-project is silently overridden by an inherited parent permission (broken access control / privilege-management regression in v2.6.0)
Medium Also affects code.vikunja.io/api
GHSA-hjx8-qv73-f7cm
Vikunja: Webhooks and link shares survive every revocation path, so a removed collaborator keeps a live feed
High Also affects code.vikunja.io/api
GHSA-fprf-r6rv-xg99
Vikunja: Saved filter creation with an empty filter string recalculates task positions across all tenants
Medium Also affects code.vikunja.io/api
GHSA-4hv6-xc92-j86g
Vikunja: WebSocket authentication ignores server-side session state, so revoked sessions keep receiving live pushes
High Also affects code.vikunja.io/api
GHSA-w2ch-4xgr-22ww
Vikunja: Task relation deletion does not check read access to the other task, allowing cross-project relation removal
Low Also affects code.vikunja.io/api
GHSA-8wvg-r2j4-3737
Vikunja: Assignee email addresses disclosed to read-only project members via the task assignees endpoint
Medium Also affects code.vikunja.io/api
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor