CVE-2026-35597
Published: 10 April 2026
Summary
CVE-2026-35597 is a medium-severity Improper Restriction of Excessive Authentication Attempts (CWE-307) vulnerability in Vikunja Vikunja. Its CVSS base score is 5.9 (Medium).
Operationally, exploitation aligns with the MITRE ATT&CK technique Brute Force (T1110); ranked at the 11.4th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified are NIST 800-53 AC-7 (Unsuccessful Logon Attempts) and SI-2 (Flaw Remediation).
Threat & Defense at a Glance
Threat & Defense Details
Mitigating Controls (NIST 800-53 r5)AI
AC-7 requires limiting consecutive invalid logon attempts and automatically locking accounts, directly mitigating the unlimited brute-force attacks on TOTP codes due to the non-functional lockout mechanism.
SI-2 mandates identifying, reporting, and correcting flaws in system components, ensuring remediation of the database transaction bug that prevents TOTP lockout enforcement.
AU-12 requires generation of audit records for authentication events including failed logons, enabling detection of excessive TOTP brute-force attempts.
MITRE ATT&CK Enterprise TechniquesAI
Why these techniques?
The vulnerability disables the TOTP failed-attempt lockout via transaction rollback, directly enabling unlimited brute-force guessing of TOTP codes for unauthorized account access.
NVD Description
Vikunja is an open-source self-hosted task management platform. Prior to 2.3.0, the TOTP failed-attempt lockout mechanism is non-functional due to a database transaction handling bug. When a TOTP validation fails, the login handler in pkg/routes/api/v1/login.go calls HandleFailedTOTPAuth and then unconditionally…
more
rolls back. HandleFailedTOTPAuth in pkg/user/totp.go uses an in-memory counter (key-value store) to track failed attempts. When the counter reaches 10, it calls user.SetStatus(s, StatusAccountLocked) on the same database session s. Because the login handler always rolls back after a TOTP failure, the StatusAccountLocked write is undone. The in-memory counter correctly increments past 10, so the lockout code executes on every subsequent attempt, but the database write is rolled back every time. This allows unlimited brute-force attempts against TOTP codes. This vulnerability is fixed in 2.3.0.
Deeper analysisAI
CVE-2026-35597 affects Vikunja, an open-source self-hosted task management platform, in versions prior to 2.3.0. The vulnerability stems from a database transaction handling bug that renders the TOTP failed-attempt lockout mechanism non-functional. Specifically, when TOTP validation fails, the login handler in pkg/routes/api/v1/login.go calls HandleFailedTOTPAuth in pkg/user/totp.go, which increments an in-memory counter and attempts to set the user status to locked after 10 failures using the same database session. However, the login handler unconditionally rolls back the transaction afterward, undoing the lockout write while the counter continues to increment, allowing unlimited brute-force attempts against TOTP codes. The issue is rated 5.9 on CVSS 3.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N) and maps to CWE-307 (Improper Restriction of Excessive Authentication Attempts).
Unauthenticated remote attackers can exploit this vulnerability over the network with high attack complexity and no user interaction required. By repeatedly submitting invalid TOTP codes, attackers bypass the intended lockout, enabling brute-force attacks to guess valid TOTP codes and gain unauthorized access to user accounts, resulting in high confidentiality impact through potential exposure of sensitive task management data.
Vikunja addresses this vulnerability in version 2.3.0, as detailed in the GitHub security advisory GHSA-fgfv-pv97-6cmj, the associated pull request #2576, and the release notes. The fix is implemented via commit 6ca0151d02fa0e8c7e2181ab916a28e08caaaec8, which resolves the transaction rollback issue to properly enforce TOTP lockouts. Security practitioners should upgrade to 2.3.0 or later to mitigate the risk.
Details
- CWE(s)