CVE-2026-28268: Vikunja Auth Bypass Vulnerability

CVE-2026-28268 Overview

CVE-2026-28268 is a critical business logic vulnerability in Vikunja, an open-source self-hosted task management platform. The flaw exists in the password reset mechanism of the vikunja/api component, allowing password reset tokens to be reused indefinitely. Due to a failure to invalidate tokens upon use combined with a critical logic bug in the token cleanup cron job, reset tokens remain valid forever. This enables an attacker who intercepts a single reset token—through logs, browser history, or phishing—to perform a complete, persistent account takeover at any point in the future, effectively bypassing standard authentication controls.

Critical Impact

This vulnerability enables persistent account takeover through indefinite password reset token reuse, allowing attackers to compromise accounts at any time after obtaining a single reset token.

Affected Products

• Vikunja versions prior to 2.1.0
• Vikunja API component (vikunja/api)
• Self-hosted Vikunja deployments using vulnerable password reset functionality

Discovery Timeline

• 2026-02-27 - CVE-2026-28268 published to NVD
• 2026-03-02 - Last updated in NVD database

Technical Details for CVE-2026-28268

Vulnerability Analysis

This vulnerability represents a classic business logic flaw (CWE-459: Incomplete Cleanup) in the authentication subsystem. The password reset mechanism fails to properly invalidate tokens after they have been used, and the background cleanup process that should remove stale tokens contains a critical logic bug that prevents proper token expiration. As a result, once a password reset token is generated, it remains valid indefinitely, regardless of whether it has already been used to reset a password.

The impact of this vulnerability is severe. An attacker who obtains a password reset token through any means—such as intercepting email communications, accessing browser history, reviewing application logs, or conducting phishing attacks—can use that token to reset the victim's password at any time in the future. This creates a persistent backdoor into user accounts that survives password changes and other security measures.

Root Cause

The root cause stems from two compounding issues in the Vikunja codebase. First, the password reset handler does not invalidate or delete the token after successful use, allowing the same token to be reused multiple times. Second, the token cleanup cron job responsible for removing expired tokens contains a logic error that prevents it from properly identifying and removing stale tokens. This combination results in tokens that persist indefinitely in the database, creating a permanent attack vector.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction from the victim beyond the initial generation of a password reset token. An attacker can exploit this vulnerability through the following scenario:

1. The attacker obtains a password reset token for a target account through interception of email traffic, access to server logs, browser history on a shared computer, or social engineering
2. Even if the legitimate user has already used the token to reset their password, the token remains valid
3. The attacker can use the intercepted token at any future time to reset the victim's password
4. The attacker gains full access to the victim's account and can lock out the legitimate user

The vulnerability exploitation mechanism involves resubmitting a previously-used password reset token to the password reset endpoint. Because the token is never invalidated, the server accepts it as valid and allows the password change to proceed. Technical details and the fix can be found in the GitHub Security Advisory.

Detection Methods for CVE-2026-28268

Indicators of Compromise

• Multiple password reset operations using the same token identifier in application logs
• Password reset requests occurring long after the original token was generated
• Suspicious password reset activity from IP addresses different from the original requestor
• User reports of unauthorized account access following previous password reset activity

Detection Strategies

• Monitor password reset endpoint logs for token reuse patterns, particularly tokens being used more than once
• Implement alerting for password reset tokens being used after significant time delays from generation
• Review authentication logs for account takeover indicators such as geographic anomalies following password resets
• Audit database for old, uncleared password reset tokens that should have been invalidated

Monitoring Recommendations

• Enable detailed logging on password reset endpoints including token identifiers and timestamps
• Implement anomaly detection for password reset frequency and timing patterns per user account
• Configure alerts for password changes followed by immediate session creation from new IP addresses
• Regularly audit the password reset token table for tokens exceeding expected lifetimes

How to Mitigate CVE-2026-28268

Immediate Actions Required

• Upgrade Vikunja to version 2.1.0 or later immediately
• Manually purge all existing password reset tokens from the database after upgrading
• Force password resets for all users as a precautionary measure if token compromise is suspected
• Review logs for any evidence of historical token reuse attacks

Patch Information

The vulnerability has been addressed in Vikunja version 2.1.0. The fix ensures that password reset tokens are properly invalidated after use and corrects the logic bug in the token cleanup cron job. The patch can be reviewed in the GitHub commit. Release details are available in the Vikunja v2.1.0 changelog.

Workarounds

• If immediate upgrade is not possible, manually implement a database cleanup script to purge all password reset tokens on a regular basis
• Implement additional rate limiting on the password reset endpoint to reduce the window of opportunity for token reuse
• Add monitoring to detect and alert on token reuse attempts while awaiting the patch deployment
• Consider temporarily disabling the password reset functionality if the risk is deemed too high for your environment

# Database cleanup example for PostgreSQL (temporary workaround)
# Run this periodically until upgrade to 2.1.0 is complete
psql -U vikunja_user -d vikunja_db -c "DELETE FROM password_reset_tokens WHERE created_at < NOW() - INTERVAL '1 hour';"