CVE-2026-62376

Executive Summary

CVE-2026-62376 is a plaintext storage of sensitive authentication tokens (CWE-312) in Vikunja, an open-source self-hosted task management platform. Versions prior to 2.4.0 store password-reset, email-confirmation, and account-deletion tokens in the user_tokens table in cleartext. Any actor who obtains read access to the database — via a leaked backup, misconfigured storage, or SQL-level exposure — can immediately replay pending tokens to take over user accounts without knowing any passwords. The vulnerability carries a CVSS v3.1 base score of 8.1 (High) and affects all self-hosted Vikunja deployments running releases before 2.4.0.

Technical Analysis

Vikunja is a self-hosted task and project management application, frequently deployed on-premises or in customer-controlled cloud infrastructure. In versions prior to 2.4.0, the application persists several classes of security-sensitive tokens in the user_tokens database table:

• Password-reset tokens
• Email-confirmation tokens
• Account-deletion tokens

Per the CVE description, these tokens are stored in plaintext rather than as hashed or otherwise irreversible values. This is a direct instance of CWE-312 (Cleartext Storage of Sensitive Information). The security boundary that normally protects these secrets is the access control of the application layer combined with database confidentiality. Because the tokens are not hashed, the database contents are themselves a usable credential store: there is no additional cryptographic step between reading a row and using the token.

The attack surface is therefore not the Vikunja web endpoint itself, but rather any channel that exposes database read access:

• Leaked or publicly accessible backups (e.g., an unauthenticated object-storage bucket, an exposed volume snapshot, or a misconfigured dump endpoint).
• Misconfigured storage where database files or dumps are reachable by unintended parties.
• SQL-level exposure — for example, a separate SQL injection flaw, an exposed database port, or overly broad database grants to a lower-trust principal.

The CVSS v3.1 vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H reflects this: the network attack vector is rated High complexity because the attacker must first obtain out-of-band read access to the token store; no privileges or user interaction are required once that access exists; and a successful replay yields High confidentiality, integrity, and availability impact. Tokens that control account deletion and email confirmation additionally allow permanent account manipulation and identity-control actions beyond simple login.

The root cause is the loss of defense-in-depth. A correctly designed system hashes reset/confirmation/deletion tokens so that database exposure alone does not permit account takeover; Vikunja prior to 2.4.0 did not. Version 2.4.0 fixes the issue. No public proof-of-concept or exploit code exists, and there is no evidence of in-the-wild exploitation as of this report; the exploit chain below is inferred from the vulnerability class.

Exploitation Scenarios

No public PoC is available; the attack chain is inferred from the vulnerability class (cleartext storage of authentication tokens) and the described exposure channels. The steps below stay at the vulnerability-class level and use only artifacts named in the CVE description.

1. Reconnaissance / target identification. The attacker identifies a Vikunja deployment (self-hosted, typically reachable over HTTP/HTTPS) and determines whether it is running a version prior to 2.4.0. In parallel, or separately, the attacker looks for a path to database read access: exposed backup artifacts, publicly reachable storage containing database dumps, or an independent SQL-level exposure affecting the same instance.

2. Trigger of the flaw class. The flaw requires no special input to the Vikunja application itself. Once the attacker obtains read access to the database — through a backup leak, misconfigured storage, or SQL-level exposure — they query the user_tokens table and read the pending password-reset, email-confirmation, and account-deletion tokens directly in cleartext.

3. Payload / execution method (vulnerability-class level). Because the tokens are stored unhashed, the attacker does not need to crack, brute-force, or reverse them. The attacker selects a token belonging to a targeted account and presents it to the corresponding Vikunja flow (password reset or email confirmation) as if they were the legitimate recipient. The application, unable to distinguish the attacker from the true token holder, accepts the token and performs the associated action.

4. Post-exploitation impact. With a password-reset token, the attacker sets a new password and takes over the account without knowing the original credentials, then authenticates normally. Email-confirmation and account-deletion tokens permit further account-level actions, including identity/email control and destructive or disruptive account operations. If the compromised account holds administrative rights or broad project access, the effect can extend across the tenant's projects and data. The operator gains full access to the victim account (High C/I/A) consistent with the CVSS vector.

A key characteristic of this class is the silent nature of the theft: reading tokens from a database does not generate the authentication anomalies normally associated with credential attacks, which is why token-at-rest protection and monitoring for anomalous reset flows matter.

Impact Assessment

• Confidentiality (High): Access to the user_tokens table exposes usable reset/confirmation/deletion tokens and, depending on database contents, the surrounding user records.
• Integrity (High): The attacker can change account passwords and email state, effectively modifying identities and access rights.
• Availability (High): Account-deletion tokens allow destructive actions against victim accounts.
• Scope (Unchanged): The vulnerable component and impacted component are the same Vikunja instance/data boundary.
• Complexity (High): Exploitation requires the attacker to independently obtain database read access (backup leak, storage misconfiguration, or SQL-level exposure), which is why AC is rated High despite no privileges or user interaction being required.

Blast radius: Every self-hosted Vikunja instance prior to 2.4.0 that has pending tokens in the user_tokens table and any weakness in backup, storage, or database access control. Because Vikunja is often self-managed, weak operational hygiene around backups and storage is a realistic precondition. The impact is greatest for instances whose accounts include administrators or who aggregate organization-wide projects. The vulnerability is not in CISA KEV, no public PoC or exploit exists, and FIRST.org has not yet assigned an EPSS score (do not assume a low score — it is simply unmeasured).

Detection Guidance

Detection for this CVE must focus on two areas: (a) signs that a database/token store has been accessed by an unintended party, and (b) anomalous use of reset/confirmation tokens. The application will not log the theft itself.

Sigma Rule

title: Vikunja Plaintext Token Store Access or Anomalous Token Replay
id: 8f4c2b1e-3a7d-4c6e-9b2f-0d1e5a7c9b30
status: experimental
description: Detects access to the Vikunja database or anomalous use of password-reset/confirmation tokens consistent with CVE-2026-62376 token theft.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-62376
author: Threat Intelligence
date: 2026/01/01
logsource:
  category: database
  product: postgresql
detection:
  selection_table:
    query|contains:
      - 'user_tokens'
  selection_export:
    query|contains:
      - 'COPY'
      - 'pg_dump'
      - 'SELECT * FROM user_tokens'
  condition: selection_table and selection_export
falsepositives:
  - Legitimate administrative backup or maintenance jobs
level: high
tags:
  - attack.t1552
  - cve.2026.62376

YARA Rule

rule CVE_2026_62376_Vikunja_Plaintext_Tokens
{
    meta:
        description = "Detects dumped or leaked Vikunja database artifacts containing plaintext user_tokens data (CVE-2026-62376)"
        author = "Threat Intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-62376"
        date = "2026-01-01"
    strings:
        $t1 = "user_tokens" ascii wide nocase
        $t2 = "CREATE TABLE user_tokens" ascii wide nocase
        $t3 = "INSERT INTO user_tokens" ascii wide nocase
        $v1 = "Vikunja" ascii wide nocase
        $c1 = "password_reset" ascii wide nocase
        $c2 = "email_confirm" ascii wide nocase
        $c3 = "account_deletion" ascii wide nocase
    condition:
        filesize < 500MB and
        ($t1 and $v1) or
        ($t2 or $t3) and ($c1 or $c2 or $c3)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-62376 Vikunja password-reset token replay attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"password"; nocase; http.uri; content:"reset"; nocase; pcre:"/token=[A-Za-z0-9_.%\-]{16,}/U"; reference:cve,2026-62376; classtype:attempted-user; sid:202662376; rev:1;)

Elastic Detection

sequence by source.ip with maxspan=15m
  [ network where process.name : ("pg_dump","mysqldump") and
      network.protocol : "postgresql" ]
  [ http where http.request.method == "POST" and
      http.request.path : "*password*reset*" ]

Splunk SPL Query

index=web OR index=database
| eval token_present=if(match(_raw, "(?i)user_tokens"), 1, 0)
| eval reset_flow=if(match(_raw, "(?i)(password[_ -]?reset|confirm[_ -]?email|account[_ -]?deletion)"), 1, 0)
| where token_present=1 OR reset_flow=1
| stats count min(_time) as first_seen max(_time) as last_seen values(src_ip) as sources by user, host
| where count > 5
| sort - count

Wazuh OSSEC Rule

<group name="vikunja,cve-2026-62376,">
  <rule id="2026623" level="12">
    <decoded_as>json</decoded_as>
    <field name="log">user_tokens</field>
    <description>CVE-2026-62376: Possible access to Vikunja plaintext token store (user_tokens)</description>
    <mitre>
      <id>T1552</id>
    </mitre>
  </rule>
  <rule id="2026624" level="10">
    <decoded_as>json</decoded_as>
    <field name="url">password|reset</field>
    <field name="method">POST</field>
    <description>CVE-2026-62376: Suspicious password-reset request - possible token replay</description>
    <mitre>
      <id>T1552</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 2/4 (CLAIMED — a single source, the GHSA advisory, claims the fix; it has not been independently confirmed). Treat the fix as real but verify it in your environment before relying on it.

1. Immediate mitigations (apply now, before or during upgrade):

   • Treat the database and all backups as sensitive credential material. Audit object storage, volume snapshots, and dump endpoints for public or over-broad access; remove any exposure immediately.
   • Rotate and revoke any database credentials that could read the user_tokens table if exposure is suspected.
   • Invalidate all pending password-reset, email-confirmation, and account-deletion tokens, and force password resets for accounts believed affected.
   • Restrict database network exposure (bind to localhost/private interfaces, firewall the DB port, enforce least-privilege DB roles).
   • Monitor reset/confirmation/deletion flows for anomalous volume or source IPs using the detection rules above.

2. Patch / upgrade steps:

   • Upgrade Vikunja to 2.4.0 or later, which the advisory states fixes the issue (tokens are no longer stored in plaintext).
   • Review the release/security advisory before upgrading; back up the current database and configuration.
   • After upgrading, confirm the user_tokens table no longer holds usable cleartext token values, and purge stale token records.

3. Long-term hardening:

   • Enforce at-rest encryption for databases and backups, and store backups in access-controlled locations with audit logging.
   • Adopt least-privilege database roles so application components cannot read more than required.
   • Instrument token-table access and alert on unusual dump/export operations.
   • Track the GHSA advisory and NVD entry for independent confirmation of the 2.4.0 fix and any backports.
   • Monitor CISA KEV and EPSS for changes; neither currently covers this CVE (EPSS unassigned, no KEV listing, no public PoC).

References

• NVD — CVE-2026-62376: https://nvd.nist.gov/vuln/detail/CVE-2026-62376
• GitHub Security Advisory (GHSA) — Vikunja plaintext token storage advisory (source of patch claim)
• Vikunja project repository / release notes for version 2.4.0
• MITRE CWE-312 — Cleartext Storage of Sensitive Information: https://cwe.mitre.org/data/definitions/312.html
• MITRE ATT&CK T1552 — Unsecured Credentials: https://attack.mitre.org/techniques/T1552/

No threat actor campaigns or exploit-in-the-wild activity have been reported for this CVE. There is no public PoC, no Nuclei template, and no CISA KEV listing. FIRST.org has not yet assigned an EPSS score.