Skip to content

GHSA-rfjg-6m84-crj2 CVE-2026-28268 GO-2026-4575

Vikunja Vulnerable to Account Takeover via Password Reset Token Reuse

Critical Go
Severity
9.8 / 10
Critical · CVSS 3.1
Exploit chance (EPSS)
0.75%
Chance of exploitation in the next 30 days. Higher than 54.93% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-459 Incomplete Cleanup
CWE-640 Weak Password Recovery Mechanism for Forgotten Password
Fix
None yet
No fixed version published

Description

Summary A critical business logic vulnerability exists in the password reset mechanism of vikunja/api that allows password reset tokens to be reused indefinitely. Due to a failure to invalidate tokens upon use and a critical logic bug in the token cleanup cron job, reset tokens remain valid forever.

This allows an attacker who intercepts a single reset token (via logs, browser history, or phishing) to perform a complete, persistent account takeover at any point in the future, bypassing standard authentication controls.

Technical Analysis The vulnerability stems from two distinct logic errors in the pkg/user/ package that confirm the tokens are never removed.

  1. Logic Error in Password Reset (No Invalidation) In pkg/user/user_password_reset.go, the ResetPassword function successfully updates the user's password but fails to delete the reset token used to authorize the request. Instead, it attempts to delete a TokenEmailConfirm token, leaving the TokenPasswordReset active.

Vulnerable Code: pkg/user/user_password_reset.go (Lines 36-94)

func ResetPassword(s *xorm.Session, reset *PasswordReset) (userID int64, err error) {
    // ... [Validation and User Lookup] ...

    // Hash the password
    user.Password, err = HashPassword(reset.NewPassword)
    if err != nil {
        return
    }

    // FLAW: Deletes 'TokenEmailConfirm' instead of the current 'TokenPasswordReset'
    err = removeTokens(s, user, TokenEmailConfirm)
    if err != nil {
        return
    }

    // ... [Update User Status and Return] ...
    // The reset token is never removed and remains valid in the DB.
}
  1. Logic Error in Token Cleanup (Inverted Expiry) The background cron job intended to expire old tokens contains an inverted comparison operator. It deletes tokens newer than 24 hours instead of older ones.

Vulnerable Code: pkg/user/token.go (Lines 125-151)

func RegisterTokenCleanupCron() {
    // ...
    err := cron.Schedule("0 * * * *", func() {
        // ...
        // FLAW: "created > ?" selects tokens created AFTER 24 hours ago.
        // This deletes NEW valid tokens and keeps OLD expired tokens forever.
        deleted, err := s.
            Where("created > ? AND (kind = ? OR kind = ?)", 
            time.Now().Add(time.Hour*24*-1), 
            TokenPasswordReset, TokenAccountDeletion).
            Delete(&Token{})
        // ...
    })
}

Impact Persistent Account Takeover: An attacker with a single valid token can reset the victim's password an unlimited number of times.

Bypass of Remediation: Even if the victim notices suspicious activity and changes their password, the attacker can use the same old token to reset it again immediately.

Infinite Attack Window: Because the cleanup cron is broken, the token effectively has a generic TTL of "forever," allowing exploitation months or years after the token was issued.

Remediation

  1. Invalidate Token on Use Update ResetPassword to delete the specific reset token upon successful completion. // Recommended Fix err = removeTokens(s, user, TokenPasswordReset) // Correct TokenKind
  2. Fix Cleanup Logic Update the SQL query in RegisterTokenCleanupCron to target tokens created before the cutoff time. // Recommended Fix Where("created < ? ...", time.Now().Add(time.Hour*24*-1), ...) // Use Less Than (<)

A fix is available at https://github.com/go-vikunja/vikunja/releases/tag/v2.1.0

Affected versions

Go

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

How to fix

No fixed version has been published yet. Until one is, remove or replace the package, or turn off or isolate the affected feature. This page updates when a fix ships.

Severity breakdown

CVSS 3.1 9.8

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

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

Weakness

CWE-459: Incomplete Cleanup

The product does not properly "clean up" and remove temporary or supporting resources after they have been used.

How to prevent it
  • Architecture and Design, Implementation: Temporary files and other supporting resources should be deleted/released immediately after they are no longer needed.

CWE-640: Weak Password Recovery Mechanism for Forgotten Password

The product contains a mechanism for users to recover or change their passwords without knowing the original password, but the mechanism is weak.

How to prevent it
  • Architecture and Design: Make sure that all input supplied by the user to the password recovery mechanism is thoroughly filtered and validated.
  • Architecture and Design: Do not use standard weak security questions and use several security questions.
  • Architecture and Design: Make sure that there is throttling on the number of incorrect answers to a security question. Disable the password recovery functionality after a certain (small) number of incorrect guesses.
  • Architecture and Design: Require that the user properly answers the security question prior to resetting their password and sending the new password to the e-mail address of record.
  • Architecture and Design: Never allow the user to control what e-mail address the new password will be sent to in the password recovery mechanism.
  • Architecture and Design: Assign a new temporary password rather than revealing the original password.

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