Skip to content
Wednesday, October 21, 2026AboutContactRSS
Vikunja Database Flaw Exposes Reset Tokens; 2.4.0 Patch Stops Account Hijacking via Plaintext Credentials
Vulnerabilities

Vikunja Database Flaw Exposes Reset Tokens; 2.4.0 Patch Stops Account Hijacking via Plaintext Credentials

The open-source task manager Vikunja fixed a high-severity flaw where plaintext tokens in the database allowed attackers to hijack accounts without passwords.

Key points

  • Vikunja versions prior to 2.4.0 stored password-reset and account-deletion tokens in plaintext within the user_tokens database table.
  • An attacker with read access to the database could extract these tokens and immediately take over user accounts, including administrator privileges.
  • Version 2.4.0 resolves CVE-2026-62376 by implementing hashed token storage, aligning security practices with existing CalDAV token handling.

The open-source task management platform Vikunja released version 2.4.0 to address a high-severity vulnerability, CVE-2026-62376, involving the insecure storage of sensitive authentication tokens. According to the NVD record, the flaw allows attackers to bypass password requirements if they gain read access to the application’s database. The issue stems from plaintext storage of tokens used for critical account actions, creating a direct path to full account takeover for any user with a pending token.

Root cause

The vulnerability originates in the `pkg/user/token.go` file, specifically within the `genToken()` function. According to the GitHub advisory GHSA-r6w9-259g-gwrv, this function generates a random string for tokens but stores the raw value directly in the `user_tokens` table without hashing. The code assigns the `tokenStr` variable to the `Token` field as-is, bypassing cryptographic protection. This design choice contrasts with how Vikunja handles CalDAV tokens, which correctly use a `generateHashedToken` function with bcrypt for secure storage.

The application relies on plaintext equality lookups to validate these tokens. The `getToken` function queries the database using a direct string match against the `token` column. Because the stored value is identical to the token sent to the user, an attacker does not need to reverse-engineer or crack the token. The NVD classifies this weakness under CWE-312 and CWE-916, highlighting the failure to protect sensitive data during storage.

Attack path

An attacker needs only read access to the Vikunja database to exploit this flaw. According to the GitHub advisory, this access could come from a leaked database backup, misconfigured cloud storage, or a secondary SQL injection vulnerability. Once inside, the attacker can execute a simple SQL query to join the `user_tokens` and `users` tables. This query extracts the email addresses associated with active password-reset tokens, which are identified by a specific kind ID.

With the plaintext token and target email, the attacker can immediately reset the user’s password. The advisory provides a proof-of-concept using a curl command that posts the stolen token and a new password to the API endpoint. This action works within the 24-hour lifetime of the token. The impact includes full account takeover for any user with a pending reset, confirmation, or deletion token, including administrators.

Affected versions

  • Vikunja versions prior to 2.4.0 are vulnerable to CVE-2026-62376.
  • The package `go code.vikunja.io/api` is affected in all versions up to and including 2.3.0.
  • Version 2.4.0 contains the fix and is not vulnerable.

Mitigation

  • Update Vikunja to version 2.4.0 or later to apply the official patch that hashes tokens before storage.
  • Rotate all user passwords immediately if you cannot update the software and suspect database exposure.
  • Audit database access controls to ensure only necessary services can read the `user_tokens` table.
  • Monitor database backup logs and storage configurations to prevent accidental exposure of sensitive data.

Background: Account takeover

Account takeover fraud occurs when attackers hijack your credentials to access personal or financial services. They use stolen data, social engineering, or weak security questions to bypass defenses. You stop this by enforcing hardware-based multi-factor authentication, monitoring session logs, and treating password resets as the highest-risk activity.

Read the full guide: Account Takeover Fraud: How Attackers Steal Identities and How You Stop It

What to do and how to stay safe: Vikunja

  • Check your Vikunja installation version and upgrade to 2.4.0 if you are running any prior release.
  • Restrict database read permissions to the minimum required for application operation to limit exposure.
  • Monitor server logs for unusual API calls to password reset or account deletion endpoints.
  • Verify that database backups are encrypted and stored in secure, access-controlled locations.

Step-by-step guide: Detect Database Exposure: Signs, Logs, and Hidden Risks

General security guidance from the NetSec Observer newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Does this vulnerability allow remote code execution?

No, this vulnerability allows account takeover by exploiting plaintext tokens stored in the database, not remote code execution.

Are CalDAV tokens affected by this plaintext storage issue?

No, CalDAV tokens correctly use hashed storage with bcrypt, so they are not vulnerable to this specific plaintext extraction method.

What is the CVSS score for CVE-2026-62376?

The NVD rates CVE-2026-62376 as having a CVSS score of 8.1, which is classified as high severity.

Sources

  1. GitHub Advisory Database
  2. CVE Program
VikunjaCVE-2026-62376plaintext storageaccount takeoveropen source

Related stories

Account Takeover Fraud: How Attackers Steal Identities and How You Stop It

Account takeover fraud rarely involves hacking servers; it usually exploits weak recovery flows and human trust in familiar login prompts.