CVE-2026-34727
NixOS vulnerability analysis and mitigation

Overview

CVE-2026-34727 is a TOTP two-factor authentication bypass vulnerability in Vikunja, an open-source self-hosted task management platform. The OIDC callback handler issues a full JWT token without verifying whether the matched user has TOTP 2FA enabled, allowing an attacker who can authenticate via OIDC with a matching email address to completely bypass the second factor. All versions up to and including 2.2.2 are affected; the vulnerability was disclosed on April 9–10, 2026, and fixed in version 2.3.0 (GitHub Advisory). The CVSS v3.1 base score is 9.1 (Critical) per NVD, and 7.4 (High) per the GitHub advisory (reflecting higher attack complexity) (GitHub Advisory).

Technical details

The root cause is improper authentication (CWE-287): the OIDC callback handler at pkg/modules/auth/openid/openid.go:185 calls auth.NewUserAuthTokenResponse(u, c, false) immediately after user lookup, with zero references to TOTP anywhere in the pkg/modules/auth/openid/ directory. By contrast, the local login handler at pkg/routes/api/v1/login.go:79-102 correctly calls user2.TOTPEnabledForUser() and user2.ValidateTOTPPasscode() before issuing a token. When the OIDC EmailFallback (or UsernameFallback) configuration is enabled and a local user with TOTP enrolled is matched by email, the OIDC path issues a full JWT without any second-factor challenge. A public proof-of-concept Python script demonstrates the full end-to-end exploit flow against a real Vikunja instance with Dex as the OIDC provider (GitHub Advisory). This vulnerability is also noted as a prerequisite chain with a separate OIDC email fallback account takeover (missing email_verified check), together enabling bypass of both password and TOTP protections (GitHub Advisory).

Impact

An unauthenticated remote attacker can obtain a valid JWT token and gain full authenticated access to any Vikunja account that has TOTP 2FA enrolled, provided the attacker can authenticate to the configured OIDC provider with a matching email address. This results in high confidentiality and integrity impact — the attacker can read, create, modify, and delete all tasks, projects, and data belonging to the compromised account. Availability is not directly impacted, but full account takeover undermines the security guarantee of TOTP enrollment and can serve as a stepping stone for further unauthorized actions within the Vikunja instance (GitHub Advisory).

Exploitability

A proof-of-concept Python exploit is publicly available via the GitHub security advisory, demonstrating the complete OIDC login flow that bypasses TOTP without any second-factor challenge (GitHub Advisory). As of the time of disclosure, there is no evidence of in-the-wild exploitation or threat actor attribution. The EPSS score is approximately 0.038% (0.000380), indicating low but non-zero probability of exploitation in the near term. This vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires the attacker to control or have access to an OIDC identity provider account with an email matching a local Vikunja user who has TOTP enabled, and the Vikunja instance must have OIDC with emailfallback: true configured.

Exploitation steps

  1. Reconnaissance: Identify a Vikunja instance (version ≤ 2.2.2) configured with OIDC authentication and emailfallback: true. Confirm that a target local user account has TOTP 2FA enrolled by attempting a local login (which returns HTTP 412 / error code 1017 when TOTP is required).
  2. Obtain OIDC credentials: Acquire or control an account on the configured OIDC provider (e.g., Dex, Keycloak) whose email address matches the target local Vikunja user.
  3. Initiate OIDC authorization flow: Send a GET request to the OIDC provider's authorization endpoint (e.g., GET /dex/auth?client_id=vikunja&redirect_uri=<TARGET>/auth/openid/dex&response_type=code&scope=openid+profile+email&state=x) to obtain the login form.
  4. Authenticate to the OIDC provider: POST credentials to the OIDC provider's login action URL, then follow the redirect to the approval/consent page and submit approval to obtain an authorization code.
  5. Submit the authorization code to Vikunja: POST the authorization code to Vikunja's OIDC callback endpoint: POST /api/v1/auth/openid/<provider>/callback with body {"code": "<auth_code>", "redirect_url": "<TARGET>/auth/openid/<provider>"}.
  6. Receive JWT without TOTP challenge: The Vikunja backend matches the OIDC email to the local user, skips TOTP verification, and returns a full JWT token in the response (HTTP 200).
  7. Access the account: Use the returned JWT as a Bearer token to make authenticated API calls (e.g., GET /api/v1/user) and gain full access to the victim's Vikunja account without ever providing a TOTP code (GitHub Advisory).

Indicators of compromise

  • Network: Unexpected POST requests to /api/v1/auth/openid/<provider>/callback from IP addresses not associated with normal user activity; successful OIDC logins (HTTP 200) for accounts known to have TOTP enabled.
  • Logs: Vikunja access logs showing OIDC callback requests returning HTTP 200 for users who consistently return HTTP 412 on local login attempts; absence of TOTP validation log entries for OIDC sessions of 2FA-enrolled users.
  • Authentication Events: JWT tokens issued via the OIDC path for accounts with TOTP enrollment, particularly during off-hours or from unusual geographic locations; no corresponding TOTP challenge/response in the authentication flow.
  • Application Behavior: User activity (task creation, project modification, data access) attributed to accounts that have TOTP enabled but whose sessions were established exclusively via OIDC callback without a preceding 412/1017 TOTP prompt (GitHub Advisory).

Mitigation and workarounds

Upgrade Vikunja to version 2.3.0 or later, which adds TOTP enforcement to the OIDC callback handler via the enforceTOTPIfRequired helper before any JWT is issued (Vikunja v2.3.0 Release, Fix PR #2582). As an interim workaround if immediate upgrade is not possible: disable OIDC authentication entirely, or disable the emailfallback (and usernamefallback) option in the OIDC configuration to prevent local user matching. Additionally, review authentication logs for any suspicious OIDC login activity for accounts with TOTP enrollment, and consider temporarily disabling TOTP for affected accounts and re-enrolling after upgrading to ensure no unauthorized sessions persist (GitHub Advisory).

Community reactions

The vulnerability was discovered and reported by aisafe.io and disclosed by Vikunja maintainer kolaente via a GitHub security advisory on April 9, 2026 (GitHub Advisory). The fix was reviewed with automated analysis from Augment Code, which identified additional secondary issues in the initial patch (e.g., account lockout not persisting on TOTP failure via OIDC, and TOTP passcode briefly stored in localStorage instead of sessionStorage), all of which were addressed before merge (Fix PR #2582). The v2.3.0 release notes highlighted 11 security fixes and strongly recommended prompt updating (Vikunja v2.3.0 Release).

Additional resources


SourceThis report was generated using AI

Related NixOS vulnerabilities:

CVE ID

Severity

Score

Technologies

Component name

CISA KEV exploit

Has fix

Published date

CVE-2026-68981HIGH8.8
  • NixOS logoNixOS
  • cpe:2.3:a:apache:nifi
NoYesAug 03, 2026
CVE-2026-69153MEDIUM6.3
  • JavaScript logoJavaScript
  • postcss
NoYesAug 03, 2026
CVE-2026-68979MEDIUM5.9
  • NixOS logoNixOS
  • nifi
NoYesAug 03, 2026
CVE-2026-64640MEDIUM5.3
  • Python logoPython
  • polaris
NoYesAug 06, 2026
CVE-2026-68980LOW2.3
  • NixOS logoNixOS
  • apache-nifi
NoYesAug 03, 2026

Free Vulnerability Assessment

Benchmark your Cloud Security Posture

Evaluate your cloud security practices across 9 security domains to benchmark your risk level and identify gaps in your defenses.

Request assessment

Get a personalized demo

Ready to see Wiz in action?

"Best User Experience I have ever seen, provides full visibility to cloud workloads."
David EstlickCISO
"Wiz provides a single pane of glass to see what is going on in our cloud environments."
Adam FletcherChief Security Officer
"We know that if Wiz identifies something as critical, it actually is."
Greg PoniatowskiHead of Threat and Vulnerability Management