GHSA-rfjg-6m84-crj2 CVE-2026-28268 GO-2026-4575
Vikunja Vulnerable to Account Takeover via Password Reset Token Reuse
- 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
- 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.
- 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.
}
- 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
- Invalidate Token on Use
Update ResetPassword to delete the specific reset token upon successful completion.
// Recommended Fix err = removeTokens(s, user, TokenPasswordReset) // Correct TokenKind - 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
| Package | Vulnerable | Fixed 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
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why 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 |
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