Skip to main content
Vulnerability Database/CVE-2026-91982

CVE-2026-91982: Vikunja TOTP Secret Disclosure Vulnerability

CVE-2026-91982 is an information disclosure vulnerability in Vikunja that exposes TOTP shared secrets after enrollment, allowing attackers to bypass two-factor authentication and take over accounts. This article covers technical details, affected versions, impact, and mitigation strategies.

Published:

CVE-2026-91982 Overview

CVE-2026-91982 is a sensitive information disclosure vulnerability in Vikunja, an open-source task management application, affecting all versions before 2.6.0. The application exposes the raw Time-based One-Time Password (TOTP) shared secret after enrollment through the GET /api/v1/user/settings/totp and /api/v1/user/settings/totp/qrcode endpoints without requiring re-authentication. An attacker holding a valid access token can retrieve the TOTP seed, import it into an authenticator application, and generate valid one-time codes at will. This defeats the second authentication factor and enables persistent account takeover even after password rotation. The weakness is tracked as [CWE-522: Insufficiently Protected Credentials].

Critical Impact

Attackers with a valid session token can permanently bypass TOTP-based multi-factor authentication by extracting the shared secret and cloning the victim's authenticator.

Affected Products

  • Vikunja versions prior to 2.6.0
  • Vikunja API endpoint /api/v1/user/settings/totp
  • Vikunja API endpoint /api/v1/user/settings/totp/qrcode

Discovery Timeline

  • 2026-09-15 - CVE-2026-91982 published to the National Vulnerability Database
  • 2026-09-17 - Last updated in NVD database

Technical Details for CVE-2026-91982

Vulnerability Analysis

Vikunja implements TOTP as a second authentication factor for user accounts. During enrollment, the server generates a shared secret and returns it to the user so that it can be imported into an authenticator application. The flaw is that the same secret remains readable through the settings API after enrollment completes. The endpoints GET /api/v1/user/settings/totp and /api/v1/user/settings/totp/qrcode return the raw seed or a QR code encoding it, and neither endpoint requires the user to re-authenticate with a password or an existing TOTP code before responding.

The consequence is that any actor holding a valid access token, including a stolen session cookie, a leaked API token, or a token obtained through an unrelated cross-site scripting or client compromise, can retrieve the TOTP secret. Because TOTP is a symmetric shared-secret scheme, possession of the seed is equivalent to permanent enrollment of the attacker's authenticator. Rotating the password does not invalidate the secret.

Root Cause

The root cause is a missing authorization check on a sensitive resource, mapped to [CWE-522]. The TOTP secret should be treated as write-only after enrollment or gated behind a step-up authentication challenge. Instead, the endpoints reuse the standard bearer-token authorization applied to ordinary settings resources.

Attack Vector

Exploitation is network-based and requires low privileges, specifically a valid authenticated session on the target account. No user interaction is needed once a token is obtained. The attacker issues an authenticated GET request against the TOTP settings endpoint, parses the returned secret, and provisions the seed in an offline authenticator. The attacker can subsequently pass the second-factor challenge indefinitely without the victim noticing any authentication event.

Refer to the GitHub Security Advisory GHSA-88f6-4rjv-x774 and the VulnCheck Advisory for Vikunja for additional technical detail.

Detection Methods for CVE-2026-91982

Indicators of Compromise

  • Successful GET requests to /api/v1/user/settings/totp or /api/v1/user/settings/totp/qrcode from a client that did not just complete enrollment.
  • Successful authentications immediately following retrieval of a TOTP secret from an unfamiliar IP address, user agent, or ASN.
  • Access-token or session-cookie use from geolocations or devices inconsistent with the account owner's baseline.

Detection Strategies

  • Enable verbose access logging on the Vikunja API and alert on any read of the TOTP endpoints outside the enrollment workflow.
  • Correlate TOTP secret retrieval events with subsequent authentication activity to identify cloned authenticators.
  • Hunt historical proxy, WAF, and reverse-proxy logs for prior requests to the two affected endpoints to scope potential exposure.

Monitoring Recommendations

  • Forward Vikunja application logs to a centralized log platform and retain HTTP request paths, source IP, and user identifier fields.
  • Alert on repeated retrieval of TOTP settings by the same account, which is unusual for legitimate use.
  • Monitor for anomalous session token usage patterns, such as concurrent sessions from disparate geographies.

How to Mitigate CVE-2026-91982

Immediate Actions Required

  • Upgrade Vikunja to version 2.6.0 or later, which removes the exposure of the raw TOTP secret after enrollment.
  • Force all users with TOTP enabled to disable and re-enroll their second factor so any previously leaked secrets become invalid.
  • Invalidate all active API tokens and user sessions, then require users to sign in again.
  • Review access logs for prior calls to the two affected endpoints and treat any hits as potential account compromise.

Patch Information

The issue is fixed in Vikunja 2.6.0. Administrators should upgrade the server component and follow the release notes published with the GitHub Security Advisory GHSA-88f6-4rjv-x774. After upgrading, rotate all TOTP secrets by having users disable and re-enroll multi-factor authentication.

Workarounds

  • Block or restrict GET access to /api/v1/user/settings/totp and /api/v1/user/settings/totp/qrcode at an upstream reverse proxy or web application firewall until the upgrade is applied.
  • Shorten access-token and session lifetimes to reduce the window in which a stolen token can be used to retrieve the secret.
  • Require administrators and privileged users to re-enroll TOTP after the upgrade regardless of prior exposure evidence.
bash
# Example NGINX snippet to block the vulnerable endpoints until patched
location ~ ^/api/v1/user/settings/totp(/qrcode)?$ {
    if ($request_method = GET) {
        return 403;
    }
    proxy_pass http://vikunja_backend;
}

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.