CVE-2026-28268: 
NixOS vulnerability analysis and mitigation

CVE-2026-28268 is a critical business logic vulnerability in the password reset mechanism of Vikunja, an open-source self-hosted task management platform, that allows password reset tokens to be reused indefinitely. All versions prior to 2.1.0 (including the legacy code.vikunja.io/api package up to v0.24.6) are affected. The vulnerability was published on February 27, 2026, with a patch released in version 2.1.0. It carries a CVSS v3.1 base score of 9.8 (Critical) (GitHub Advisory, Vikunja Security Advisory).

The vulnerability stems from two compounding logic errors in the pkg/user/ package (CWE-459: Incomplete Cleanup; CWE-640: Weak Password Recovery Mechanism). First, in pkg/user/user_password_reset.go, the ResetPassword function calls removeTokens(s, user, TokenEmailConfirm) instead of removeTokens(s, user, TokenPasswordReset), meaning the password reset token is never deleted from the database after use. Second, the background cron job in pkg/user/token.go intended to expire old tokens uses an inverted SQL comparison (created > ? instead of created < ?), causing it to delete newly created valid tokens while retaining old expired ones indefinitely. Together, these bugs mean any intercepted reset token — obtained via server logs, browser history, or phishing — remains permanently valid and can be replayed without limit (Vikunja Security Advisory, Patch Commit).

Successful exploitation enables complete and persistent account takeover: an attacker who obtains a single password reset token can reset the victim's password an unlimited number of times, even months or years after the token was originally issued. Because the token remains valid even after the victim changes their password through normal means, the attacker can immediately re-assert control, effectively making remediation by the victim impossible without server-side intervention. All confidentiality, integrity, and availability of the affected user account are fully compromised, and any data stored within the Vikunja instance accessible to that account is at risk (GitHub Advisory).

No public proof-of-concept exploit code or evidence of in-the-wild exploitation has been reported as of the time of disclosure (Feedly). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.034–0.041%, placing it in the 13th percentile for exploitation likelihood within 30 days (GitHub Advisory). Despite the low EPSS, the CVSS 9.8 score and the zero-prerequisite nature of the attack (no authentication, no user interaction required beyond token interception) make it a high-priority patching target.

1. Token Acquisition: Obtain a valid password reset token for a target Vikunja account. This can be achieved through phishing (tricking the user into clicking a reset link and capturing the token from the URL), monitoring exposed server logs, inspecting browser history on a shared or compromised machine, or intercepting unencrypted traffic if TLS is not enforced.
2. Trigger Password Reset: Navigate to the Vikunja API password reset endpoint (e.g., POST /api/v1/user/password/reset) and submit a request body containing the intercepted token and a new attacker-chosen password: {"token": "<intercepted_token>", "new_password": "attacker_password"}.
3. Confirm Takeover: Log in to the victim's Vikunja account using the newly set password. Due to the token not being invalidated, this step can be repeated at any future time.
4. Persistence: Because the cleanup cron job is broken and the token is never removed, the attacker can re-execute step 2 at any point — even if the victim subsequently changes their password — to regain access indefinitely (Vikunja Security Advisory).

• Logs: Multiple successful POST /api/v1/user/password/reset requests for the same user account within a short period or across widely separated time intervals; password reset completions not initiated by the account owner.
• Database: Presence of TokenPasswordReset entries in the user_tokens table with created timestamps older than 24 hours that have not been cleaned up; duplicate or repeated use of the same token value across multiple reset events.
• Behavioral: Unexpected account password changes reported by legitimate users who did not initiate a reset; account logins from unfamiliar IP addresses or geolocations shortly after a password reset event.
• Network: Repeated API calls to the password reset endpoint from the same external IP address targeting multiple accounts (token stuffing or targeted reuse attempts) (Vikunja Security Advisory).

Upgrade all Vikunja installations to version 2.1.0 or later, which contains the fix: the ResetPassword function now correctly calls removeTokens(s, user, TokenPasswordReset) to invalidate the token upon use, and the cron job cleanup logic has been corrected (Patch Commit). No official configuration-based workaround exists for unpatched versions. As an interim measure before patching, administrators should review the user_tokens database table and manually delete all TokenPasswordReset entries, and audit password reset logs for suspicious reuse patterns (GitHub Advisory).

Security Online covered the vulnerability under the headline "Critical Flaws in Vikunja Expose Users to Persistent Account Takeovers," highlighting the severity of the infinite attack window (Security Online). The Hacker Wire also published coverage and social media posts on Bluesky drawing attention to the token reuse issue (The Hacker Wire). Community discussion appeared on Mastodon and Bluesky, with security researchers noting the compounding nature of the two logic bugs as particularly concerning. Red Hat also tracked the CVE in their security advisory database (Red Hat).