CVE-2026-35597: Vikunja TOTP Auth Bypass Vulnerability

CVE-2026-35597 Overview

CVE-2026-35597 is an authentication bypass vulnerability affecting Vikunja, an open-source self-hosted task management platform. The vulnerability exists in the Time-based One-Time Password (TOTP) failed-attempt lockout mechanism, which is rendered non-functional due to a database transaction handling bug. This flaw allows attackers to conduct unlimited brute-force attempts against TOTP codes, effectively bypassing the multi-factor authentication protection intended to secure user accounts.

Critical Impact

The TOTP lockout bypass enables attackers to perform unlimited brute-force attacks against user accounts protected by two-factor authentication, potentially compromising any account on affected Vikunja instances.

Affected Products

• Vikunja versions prior to 2.3.0
• All Vikunja installations with TOTP-based two-factor authentication enabled
• Self-hosted Vikunja deployments running vulnerable versions

Discovery Timeline

• 2026-04-10 - CVE CVE-2026-35597 published to NVD
• 2026-04-13 - Last updated in NVD database

Technical Details for CVE-2026-35597

Vulnerability Analysis

This vulnerability represents a classic Improper Restriction of Excessive Authentication Attempts (CWE-307) combined with a subtle database transaction management flaw. The vulnerability exists in the interaction between two code paths: the login handler in pkg/routes/api/v1/login.go and the TOTP authentication handler in pkg/user/totp.go.

When a user attempts to authenticate with TOTP, the system uses an in-memory counter (key-value store) to track failed attempts. Upon reaching 10 failed attempts, the HandleFailedTOTPAuth function correctly invokes user.SetStatus(s, StatusAccountLocked) to lock the account. However, the critical flaw lies in the transaction handling—the login handler unconditionally rolls back the database transaction after any TOTP failure.

This rollback behavior means that while the in-memory counter correctly tracks failed attempts and the lockout code executes on every attempt after the threshold is reached, the actual database write that would persist the locked account status is undone. The result is a security control that appears to function but provides no actual protection.

Root Cause

The root cause is improper database transaction handling in the authentication flow. The login handler in pkg/routes/api/v1/login.go unconditionally calls rollback after TOTP validation failures, regardless of whether the lockout status was written to the database. The HandleFailedTOTPAuth function in pkg/user/totp.go operates within the same database session, so when the parent transaction rolls back, all changes—including the account lockout status—are discarded. The disconnect between in-memory state (which persists) and database state (which gets rolled back) creates a false sense of security where the lockout logic executes but has no effect.

Attack Vector

An attacker can exploit this vulnerability by repeatedly submitting invalid TOTP codes against a target account. Since the network-accessible authentication endpoint accepts unlimited attempts without effective rate limiting or account lockout, the attacker can systematically attempt all 1,000,000 possible 6-digit TOTP codes. Given that TOTP codes typically have a 30-second validity window, a sufficiently fast attack could potentially guess the correct code within this timeframe.

The attack requires the attacker to know or have already compromised the target account's primary credentials (username and password), making this vulnerability particularly dangerous in credential stuffing scenarios or when primary credentials have been leaked.

Detection Methods for CVE-2026-35597

Indicators of Compromise

• Unusually high volume of failed TOTP authentication attempts from a single IP address
• Multiple failed login attempts targeting the same user account in rapid succession
• Authentication logs showing continued TOTP failures after the 10-attempt threshold should have triggered lockout
• Patterns of systematic code enumeration (sequential or structured TOTP code attempts)

Detection Strategies

• Implement external monitoring for authentication endpoint request rates that exceed normal user behavior
• Configure alerting on authentication failure patterns that indicate brute-force attempts
• Review Vikunja application logs for repeated HandleFailedTOTPAuth executions without corresponding account lockouts
• Deploy web application firewall (WAF) rules to detect and block rapid authentication attempts

Monitoring Recommendations

• Enable verbose logging for authentication events and monitor for anomalous patterns
• Implement network-level rate limiting on the login endpoint as an additional layer of defense
• Set up alerts for any single IP making more than 10 authentication attempts within a 5-minute window
• Consider deploying SIEM rules to correlate failed TOTP attempts with potential account compromise indicators

How to Mitigate CVE-2026-35597

Immediate Actions Required

• Upgrade all Vikunja installations to version 2.3.0 or later immediately
• Audit authentication logs for signs of previous exploitation attempts
• Implement network-level rate limiting on authentication endpoints as a defense-in-depth measure
• Consider temporarily disabling TOTP authentication and using alternative MFA methods if immediate upgrade is not possible

Patch Information

The vulnerability is fixed in Vikunja version 2.3.0. The fix addresses the database transaction handling to ensure that account lockout status is properly committed to the database. Organizations should update to this version through their standard deployment processes. The patch is available via the GitHub Release v2.3.0. Technical details of the fix can be reviewed in the GitHub Commit and GitHub Pull Request. For full security advisory details, refer to GHSA-fgfv-pv97-6cmj.

Workarounds

• Deploy a reverse proxy or WAF with rate limiting configured to block excessive authentication attempts
• Implement IP-based blocking for sources exceeding authentication attempt thresholds
• Use VPN or IP allowlisting to restrict access to the Vikunja login endpoint to trusted networks
• Consider temporarily disabling TOTP and using hardware security keys or other MFA methods until the patch can be applied

# Example nginx rate limiting configuration for Vikunja login endpoint
# Add to nginx server block configuration
limit_req_zone $binary_remote_addr zone=login_limit:10m rate=5r/m;

location /api/v1/login {
    limit_req zone=login_limit burst=3 nodelay;
    limit_req_status 429;
    proxy_pass http://vikunja_backend;
}