CVE-2026-91982 in Vikunja
Summary
by MITRE • 09/15/2026
Vikunja before 2.6.0 continues to expose the raw TOTP shared secret after enrollment through the GET /api/v1/user/settings/totp and /api/v1/user/settings/totp/qrcode endpoints without re-authentication. Attackers with a valid access token can read the secret, import it into their own authenticator, and generate valid codes indefinitely to defeat the second factor and enable account takeover.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability in Vikunja versions prior to 2.6.0 represents a critical failure in authentication state management and sensitive data handling within its two-factor authentication implementation. Specifically, the application exposes the raw Time-based One-Time Password shared secret through API endpoints GET /api/v1/user/settings/totp and GET /api/v1/user/settings/totp/qrcode without requiring re-authentication for these specific requests. This design flaw allows any user possessing a valid access token to retrieve the cryptographic material necessary to generate valid TOTP codes, effectively bypassing the intended security control of multi-factor authentication. The absence of additional verification steps such as password confirmation or session renewal creates a significant attack surface where compromised credentials can be leveraged for persistent unauthorized access.
From a technical perspective, this issue stems from an improper enforcement of authorization checks on endpoints that handle highly sensitive cryptographic secrets. While the user is authenticated via their initial token, the system fails to validate whether the requestor has recently re-verified their identity before disclosing the TOTP secret. This allows for session hijacking scenarios where an attacker who obtains a valid access token can immediately query these endpoints to extract the shared secret. Once obtained, this secret enables the attacker to configure their own authenticator application with the victim's credentials and generate valid one-time codes indefinitely. Consequently, the second factor of authentication is neutralized because the attacker possesses both the static password (via the stolen token) and the dynamic TOTP code generation capability derived from the exposed secret.
The operational impact of this vulnerability is severe, leading directly to account takeover with full persistence. An adversary who compromises a user's access token can not only log in as that user but also maintain long-term access even if the victim changes their password or rotates other credentials, provided they retain control over the TOTP generation process. This undermines the fundamental security guarantee of two-factor authentication, which is to provide an additional layer of defense against credential theft. The ability to generate valid codes indefinitely means that traditional remediation steps like resetting passwords are insufficient unless the TOTP secret itself is also rotated and re-enrolled with proper verification procedures in place.
This vulnerability aligns closely with CWE-359, which describes exposure of private information without adequate control, as well as CWE-640, Weak Password Recovery Mechanisms for Administrators, due to the bypassing of secondary authentication checks. In terms of MITRE ATT&CK framework tactics, this flaw facilitates Credential Access through techniques such as Valid Accounts and potentially Account Manipulation if the attacker modifies settings further after gaining access. It also relates to Defense Evasion by allowing the attacker to maintain persistence without detection from standard MFA alerts that might trigger on new device logins or unusual geographic locations.
To mitigate this risk, immediate action is required for organizations running Vikunja versions earlier than 2.6.0. The primary remediation strategy involves upgrading to version 2.6.0 or later where the issue has been addressed by enforcing re-authentication requirements on sensitive endpoints. For environments unable to upgrade immediately, administrators should implement reverse proxy rules or WAF policies that require additional authentication headers for requests targeting /api/v1/user/settings/totp and related qrcode endpoints. Additionally, users who may have been affected should rotate their access tokens and revoke existing sessions to invalidate any stolen credentials. It is also critical to re-enroll in two-factor authentication after applying fixes to ensure the new shared secret is protected by proper verification protocols during setup.