OIDC login bypass skips TOTP, enabling Vikunja 2FA bypass

TL;DR — Vikunja’s OIDC callback can issue a full JWT for a TOTP-enrolled local user without a second-factor challenge, breaking the security guarantee of 2FA when OIDC EmailFallback is used.

What happened

Vikunja is an open-source, self-hosted task management platform that supports OIDC-based SSO for user login. CVE-2026-34727 describes an improper authentication flaw where the OIDC callback handler issues a full JWT token without checking whether the matched local user has TOTP two-factor authentication enabled.

Per the linked GitHub advisory, the OIDC callback path (e.g., pkg/modules/auth/openid/openid.go) issues a JWT after user lookup, and the OIDC auth module contains no TOTP checks, while the local login route implements TOTP verification. When OIDC EmailFallback maps an external identity to an existing local user who has TOTP enabled, the second factor is skipped and a JWT is still minted.

This is a high-impact identity failure mode because it turns a “defense-in-depth” control (TOTP) into a false sense of security in SSO deployments. OIDC integration bugs that mint tokens without enforcing the same MFA policy as local login are a recurring class of auth boundary breakage, and they tend to be widely reachable in internet-exposed self-hosted apps.

Who is impacted

• Deployments running Vikunja versions marked as affected in the CVE/advisory (CVE record: < 2.3.0; GitHub advisory: <= 2.2.2).
• Instances that enable OIDC and rely on EmailFallback (or equivalent email-based account linking) to map OIDC identities onto existing local users.
• Organizations treating TOTP enrollment as an access control boundary for privileged users (admins, project owners), since this flaw can mint a valid session token without a second-factor step.

What to do now

• Follow vendor remediation guidance and apply the latest patched release available at the time of writing.

  "Patched versions 2.3.0"

• Inventory Vikunja instances using OIDC and identify configurations that enable email-based fallback/linking to existing users (e.g., emailfallback: true).
• Treat this as an auth-policy parity issue: verify that every login path that can mint a session token (local login, OIDC callback, API tokens) enforces the intended MFA requirements.
• If exposure is suspected, review authentication logs for OIDC sign-ins for TOTP-enrolled accounts and rotate credentials/tokens accessible to those sessions (and consider invalidating existing JWTs where operationally feasible).