CVE-2026-91982

Executive Summary

CVE-2026-91982 is an insufficiently protected credentials vulnerability (CWE-522) in Vikunja before 2.6.0. The application 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 requiring re-authentication. Any attacker holding a valid access token can read the secret, import it into their own authenticator application, and generate valid one-time codes indefinitely — neutralizing the second authentication factor and enabling full account takeover.

Technical Analysis

The vulnerability resides in how Vikunja handles TOTP enrollment state and secret retrieval. Under the intended security model, a TOTP shared secret is a sensitive cryptographic value that should be disclosed exactly once — at enrollment — and should never be retrievable again afterward. Vikunja before 2.6.0 violates this model in two ways:

1. Persistent secret exposure. The endpoints GET /api/v1/user/settings/totp and GET /api/v1/user/settings/totp/qrcode continue to return the raw TOTP shared secret after enrollment has completed. The QR-code endpoint, by design, must encode the secret (typically as an otpauth:// URI) — meaning the raw secret is recoverable from it as well.
2. No re-authentication requirement. Neither endpoint requires the user to re-authenticate (step-up authentication) before returning the secret. This means the disclosure condition is satisfied by possession of an ordinary, already-issued access token, with no additional proof of identity.

The result is a classic CWE-522 (Insufficiently Protected Credentials) condition: a long-lived shared secret that authenticates the second factor is exposed over a network-accessible API surface to any principal holding a valid session token. Because the secret is not ephemeral — it is the seed for all future TOTP codes — its disclosure is permanent in effect. Until the secret is rotated or the user is re-enrolled, the attacker who has obtained it can independently and reliably reproduce any future TOTP code.

The attack surface is the authenticated REST API. The affected product is a self-hosted, open-source project/task management platform commonly deployed behind reverse proxies and exposed on internal or public networks.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred from the vulnerability class (CWE-522) and the NVD description.

1. Reconnaissance / target identification. The attacker identifies a Vikunja instance (e.g., via HTTP response fingerprinting using the Shodan dorks above) and targets a user account with MFA enabled. The attacker must already possess a valid access token for that account — obtained, for example, via session theft, token leakage, malicious OAuth-style grant reuse, XSS-based token exfiltration, or a compromised API client. Note CVSS privilege requirement is LOW (PR:L), consistent with an already-authenticated attacker.

2. Triggering the specific flaw class. Using the stolen access token as the bearer credential, the attacker issues a request to GET /api/v1/user/settings/totp (and, alternatively, GET /api/v1/user/settings/totp/qrcode). Because Vikunja does not require re-authentication and does not stop exposing the secret post-enrollment, the response contains the raw TOTP shared secret. No special payload, injection, or malformed input is required — the disclosure is a direct consequence of the endpoint's authorization logic.

3. Payload / execution. The attacker extracts the raw secret from the response body (or the otpauth:// URI returned by the QR-code endpoint) and imports it into their own authenticator application. The attacker can now compute valid TOTP codes for the victim's account at will.

4. Post-exploitation impact. With the secret in hand, the attacker can generate valid one-time codes indefinitely, reproducing the legitimate user's second factor. Combined with control of the primary credential (username/password, stealable session, or token), the attacker can authenticate as the victim and defeat MFA. This enables account takeover of the affected user, which — given Vikunja's role as a project/task platform — may yield access to other users' data, project contents, API tokens, and any downstream integrations. Because MFA is completely bypassed, defensive detections that rely on MFA challenge failures will not fire.

Note: exploitation is contingent on prior possession of a valid access token; the vulnerability itself provides the MFA-bypass, not the initial credential theft.

Impact Assessment

• CVSS v3.1: 4.3 (Medium) — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
  • AV:N — exploitable over the network via the HTTP API.
  • AC:L — no special conditions beyond standard API access; the endpoint returns the secret directly.
  • PR:L — requires a low-privileged authenticated principal (i.e., a valid access token).
  • UI:N — no user interaction required.
  • S:U — impact is scoped to the affected component.
  • C:L — limited confidentiality impact, reflecting exposure of the TOTP secret for a single account.
  • I:N / A:N — the secret read itself does not directly modify or disrupt availability, though its downstream use enables account takeover.
• Business impact. Although CVSS assigns Medium severity, the real-world consequence is significant: MFA is a primary control against credential stuffing and token abuse. A user whose TOTP secret is exposed can have their second factor silently cloned, allowing persistent attacker access. This undermines the security posture of the entire Vikunja deployment for affected users.
• Blast radius. Each exploited token is scoped to the account it belongs to; however, in deployments where a single human has administrative privileges over other projects/users, or where service accounts are shared, the downstream reach can extend to project data, API tokens, and connected integrations. Compromised secrets remain valid until the user rotates their TOTP secret (re-enrollment), so the window of exposure is indefinite.
• EPSS: 0.00276 (20.1st percentile). Low probability of exploitation in the wild at the time of assessment, consistent with the absence of public PoC and the requirement for a pre-existing valid token. Not listed in CISA KEV.

Detection Guidance

Sigma Rule

Detects access to the TOTP secret endpoints that return a raw secret or QR code after enrollment. Because server-side logging varies, this rule is best applied to reverse-proxy/access logs (e.g., Nginx, Apache) if forwarded into the SIEM.

title: Vikunja TOTP Secret Re-Disclosure Endpoint Access (CVE-2026-91982)
id: 5f7e2b6a-9c1d-4a2b-8e3f-1c6d0a9b7e42
status: experimental
description: >
  Detects repeated or anomalous access to Vikunja TOTP settings/QR-code endpoints
  that may indicate retrieval of the raw TOTP shared secret after enrollment
  (CVE-2026-91982).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-91982
author: valtersit.com
date: 2026/01/01
tags:
  - attack.credential_access
  - attack.t1556.006
logsource:
  category: webserver
detection:
  selection_method:
    cs-method: 'GET'
  selection_path:
    cs-uri-stem|contains:
      - '/api/v1/user/settings/totp'
      - '/api/v1/user/settings/totp/qrcode'
  selection_status:
    sc-status: 200
  condition: selection_method and selection_path and selection_status
falsepositives:
  - Legitimate user re-enrolling MFA (single expected access during enrollment)
  - Automated inventory or backup jobs that read settings
level: medium

YARA Rule

Targets the raw file:memory traces are not available; this rule detects source-code/build artifacts or configuration containing the vulnerable endpoint definitions. Use for scanning source trees or binaries during incident response.

rule CVE_2026_91982_Vikunja_TOTP_Secret_Exposure
{
    meta:
        author = "valtersit.com"
        description = "Detects references to Vikunja TOTP secret retrieval endpoints associated with CVE-2026-91982"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-91982"
        date = "2026-01-01"
        cve = "CVE-2026-91982"

    strings:
        $ep1 = "/api/v1/user/settings/totp" ascii wide
        $ep2 = "/api/v1/user/settings/totp/qrcode" ascii wide
        $s1  = "totp" ascii nocase
        $s2  = "otpauth://" ascii
        $s3  = "shared secret" ascii nocase

    condition:
        (any of ($ep1, $ep2)) and (any of ($s1, $s2, $s3))
}

Suricata IDS Rule

Detects network requests to the exposed TOTP endpoints. Replace $HOME_NET/$EXTERNAL_NET and the host variable with your Vikunja host.

alert http $HOME_NET any -> $EXTERNAL_NET any ( \
  msg:"CVE-2026-91982 Vikunja TOTP Secret Disclosure Endpoint Access"; \
  flow:established,to_server; \
  http.method; content:"GET"; \
  http.uri; content:"/api/v1/user/settings/totp"; \
  http.uri; content:"/api/v1/user/settings/totp/qrcode"; \
  classtype:policy-violation; \
  reference:cve,2026-91982; \
  reference:url,nvd.nist.gov/vuln/detail/CVE-2026-91982; \
  sid:100091982; rev:1; )

Note: Suricata matches content on a single buffer sequentially; the two http.uri content matches above deliberately allow detection of either substring. For a stricter rule, use http.uri; content:"/api/v1/user/settings/totp"; alone (it also matches the /qrcode sibling path).

Elastic Detection

EQL query against web access logs ingested as logs-* with ECS http.request.method and url.path fields. Flags HTTP 200 responses to the sensitive endpoints.

sequence by source.ip with maxspan=5m
  [any where event.category == "web"
     and http.request.method == "GET"
     and url.path : ("/api/v1/user/settings/totp", "/api/v1/user/settings/totp/qrcode")
     and http.response.status_code == 200]

Standalone (non-sequence) variant:

any where event.category == "web"
  and http.request.method == "GET"
  and url.path : ("/api/v1/user/settings/totp", "/api/v1/user/settings/totp/qrcode")
  and http.response.status_code == 200

Splunk SPL Query

Assumes access logs are indexed with fields method, uri_path, and status, or that the raw event contains the URI. Adjust sourcetype as needed.

index=web sourcetype=access_combined (uri_path="/api/v1/user/settings/totp" OR uri_path="/api/v1/user/settings/totp/qrcode" OR uri="*/api/v1/user/settings/totp*")
| where status=200 OR status="200"
| stats count min(_time) as first_seen max(_time) as last_seen values(src_ip) as source_ips by user, uri_path, status
| where count > 1
| eval first_seen=strftime(first_seen,"%Y-%m-%d %H:%M:%S"), last_seen=strftime(last_seen,"%Y-%m-%d %H:%M:%S")
| sort - count

Note: repeated access (count > 1) to the TOTP secret endpoint is suspicious because legitimate enrollment touches it once. Analysts should baseline expected re-enrollment behavior.

Wazuh OSSEC Rule

Detects access-log entries for the Vikunja TOTP endpoints. Requires Wazuh to be parsing the web server log format containing the request path.

<group name="web,vikunja,cve-2026-91982,">
  <rule id="100982" level="10">
    <if_sid>31100,31101,31108</if_sid>
    <field name="url">/api/v1/user/settings/totp</field>
    <description>CVE-2026-91982: Access to Vikunja TOTP secret endpoint detected</description>
    <mitre>
      <id>T1556.006</id>
    </mitre>
    <group>credential_access,</group>
  </rule>
</group>

Note: if_sid references common Wazuh web-access-log parent rules (adjust to the exact web-decoder rule IDs in your deployment). The <field name="url"> match triggers on either the base path or its /qrcode sibling due to substring matching.

Mitigation & Patch Guidance

Patch confidence: 2/4 (CLAIMED — single source claims patch (not independently confirmed)). OSV is the sole source asserting a fix in Vikunja 2.6.0; no vendor advisory, commit reference, or CNA confirmation was independently verified. Treat the version threshold as provisional and validate against the project's release notes before relying on it.

1. Immediate mitigations (if upgrade cannot be performed now):

   • Restrict network access to the affected endpoints at the reverse proxy/WAF — block or rate-limit GET requests to /api/v1/user/settings/totp and /api/v1/user/settings/totp/qrcode except during a known enrollment window (e.g., require step-up conditions, IP allowlists, or admin approval).
   • Enforce short token lifetimes and token binding where possible; revoke access tokens that cannot be accounted for. The flaw requires a valid token — reducing token exposure reduces the attack surface.
   • Monitor for anomalous reads of the TOTP endpoints (see Detection Guidance) and alert on repeated access, which is inconsistent with one-time enrollment.
   • For high-risk accounts, rotate TOTP secrets (disable and re-enroll MFA) to invalidate any secret that may have already been exfiltrated.
   • Where feasible, prefer phishing-resistant factors (WebAuthn/FIDO2) over TOTP for accounts that support it, reducing reliance on the exposed secret type.

2. Patch / upgrade steps:

   • Upgrade Vikunja to 2.6.0 or later (per OSV — single-source claim; verify the exact fixed version in the official release notes).
   • Because no official vendor fix text was retrieved (Vendor Fix: N/A, Workarounds: N/A in the source data), confirm the fix in the project's changelog/release tags before closing remediation tickets.
   • After upgrading, re-verify that the GET /api/v1/user/settings/totp and /qrcode endpoints no longer return the raw secret post-enrollment and that re-authentication is enforced. Consider re-enrolling MFA for users as a precaution.

3. Long-term hardening:

   • Adopt a "reveal-once" design for any secret material: sensitive values should be displayed only during enrollment and thereafter stored only in hashed/derived form (for verification) — never retrievable as raw plaintext.
   • Require step-up authentication for any endpoint that returns authentication secrets or modifies MFA state.
   • Apply least privilege to access tokens, enforce short expiration and rotation, and monitor token issuance/usage for anomalies.
   • Deploy detection content from the section above and periodically test it against controlled, authorized simulations.

References

• NVD — CVE-2026-91982: https://nvd.nist.gov/vuln/detail/CVE-2026-91982
• OSV — CVE-2026-91982 / Vikunja (single source claiming fix in 2.6.0 — unverified): https://osv.dev/list?q=CVE-2026-91982
• Vikunja project — release notes / changelog (verify the 2.6.0 fix and endpoint behavior): https://vikunja.io/changelog/
• CWE-522 — Insufficiently Protected Credentials: https://cwe.mitre.org/data/definitions/522.html
• MITRE ATT&CK — T1556.006 (Modify Authentication Process: Multi-Factor Authentication): https://attack.mitre.org/techniques/T1556/006/

Threat actor / exploit-in-the-wild note: No public PoC, no Nuclei template, no known exploit code, and no CISA KEV listing were identified for CVE-2026-91982 at the time of this report. Exploitation probability is currently low (EPSS 0.00276, ~20.1st percentile). No named threat actor campaigns are associated with this CVE in the provided data.