Vikunja EUVD-2026-95994

Exploitation requires two preconditions. First, the attacker must already have read access to the Vikunja backend database - via a leaked/unsecured backup, misconfigured or publicly exposed storage, or a secondary SQL-level exposure such as SQL injection - because the vulnerability is plaintext storage of tokens in the user_tokens table, not a directly reachable network flaw. Second, a target account must have a pending password-reset, email-confirmation, or account-deletion token (kind IN (1,2,3)) that is still within its 24-hour validity window; accounts with no outstanding token cannot be taken over this way. Limiting factors: the whole attack is gated on an out-of-band database compromise, the 24-hour token lifetime bounds the usable token set, and CalDAV tokens are unaffected because they are already bcrypt-hashed. No Vikunja application authentication or user interaction is needed for the token-redemption step itself.

This is a genuine high-impact flaw but a conditional one, and the signals should be read together rather than at face value. The CVSS base score of 8.1 is driven by full C:H/I:H/A:H account takeover (including admin accounts) over a network vector, but it correctly carries AC:H because exploitation is not self-contained: the attacker must FIRST obtain read access to the database out-of-band (leaked backup, misconfigured/exposed storage, or a secondary SQL injection). The AV:N/PR:N/UI:N metrics describe only the second stage - redeeming a stolen plaintext token against the public reset API with no Vikunja authentication or user interaction - so the network-unauthenticated framing is accurate for that stage but presupposes a prior database compromise. A PoC (SQL dump query plus a curl reset request) is published in the GHSA advisory, so working exploit steps are public. There is no CISA KEV listing and no EPSS score was supplied in the input; absent those, there is no evidence of active or widespread exploitation, and the dependency on an existing DB breach makes mass automated exploitation unlikely. Net: treat as a real but second-order priority - the severity materializes only for operators who have also suffered a database exposure, with a 24-hour token-lifetime window limiting the set of usable tokens.

An attacker who obtains a leaked Vikunja database backup or exploits a separate SQL injection reads the user_tokens table, where password-reset tokens are stored in plaintext. Because the advisory publishes a working PoC (a SELECT to dump tokens followed by a curl POST to /api/v1/user/password/reset), the attacker can immediately submit any pending reset token to set a new password and seize the account - including admin accounts - without knowing the original password. The high attack complexity reflects the prerequisite database read access rather than any difficulty in the token redemption itself.