CVE-2026-62367 in Vikunja
Summary
by MITRE • 10/09/2026
Vikunja is an open-source self-hosted task management platform. In versions 1.0.0 through 2.3.0, when an administrator enables the per-provider `emailfallback` option on an OpenID Connect provider, Vikunja links an SSO login to a pre-existing local (username+password) account using only the `email` claim from the IdP. The fallback never checks an `email_verified` (or Microsoft `xms_edov`) signal and never requires the matched account's password. An attacker who can obtain a token from the configured issuer carrying a victim's email logs in as that victim with a full session, with no consent or interaction from the victim. Version 2.4.0 fixes the issue.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/09/2026
The vulnerability identified in Vikunja versions 1.0.0 through 2.3.0 represents a critical authentication bypass rooted in flawed identity provider integration logic. Specifically, when an administrator configures an OpenID Connect provider with the per-provider emailfallback option enabled, the application attempts to link Single Sign-On logins to pre-existing local accounts based solely on the email address claim provided by the Identity Provider. This design decision introduces a severe security flaw because the system fails to validate whether the email address is genuinely owned or verified by the user presenting the authentication token. The absence of checks for standard verification signals, such as the OIDC email_verified attribute or Microsoft-specific xms_edov claims, means that any valid access token containing an arbitrary email address can be used to impersonate a local account associated with that email.
From a technical perspective, this flaw constitutes a classic case of identity confusion and authentication bypass. The application logic assumes that possession of the email claim is sufficient proof of identity for linking or logging into existing accounts without requiring additional verification steps. Crucially, when matching an SSO login to a local account via this fallback mechanism, Vikunja does not require the user to provide the password associated with that local account. This effectively nullifies the security boundary between federated authentication and local credential-based authentication. An attacker who obtains or forges an access token from the configured issuer carrying the victim's email address can bypass all traditional password checks and gain full administrative control over the victim's session without any interaction, consent, or knowledge of the victim's credentials.
The operational impact of this vulnerability is severe, as it allows for complete account takeover through identity spoofing. Since many organizations use predictable email formats or allow users to register with common domains that might be susceptible to token leakage or misconfiguration in external Identity Providers, an attacker can exploit this by obtaining a valid token from the IdP and using it to log into Vikunja as any user whose local account shares that email address. This bypasses multi-factor authentication if it is tied to the password-based login flow rather than strictly enforced at the federation level during the initial SSO handshake, although in this specific fallback scenario, no MFA challenge occurs because the system treats the token presentation as sufficient proof of identity for an existing local user. The attacker gains full access to all tasks, projects, and data associated with the victim's account, leading to potential confidentiality breaches, integrity violations through unauthorized modifications, and availability issues if malicious actions are taken within the platform.
This vulnerability aligns closely with CWE-287 Improper Authentication, as the system fails to properly verify the identity of a user during authentication. It also relates to CWE-613 Insufficient Session Expiration, insofar as the session established via this bypass is treated as fully valid and persistent until expiration or logout. In terms of MITRE ATT&CK framework mapping, this behavior facilitates Account Manipulation (T1098) by allowing an attacker to assume control of a legitimate account without detection through credential theft, and potentially Credential Access (T1110) if the initial token acquisition involves phishing or interception techniques. The root cause lies in the insecure assumption that email uniqueness across systems guarantees identity ownership, ignoring the reality that email claims can be manipulated or obtained by unauthorized parties.
To mitigate this vulnerability, organizations running Vikunja versions 1.0.0 through 2.3.0 must upgrade immediately to version 2.4.0 or later, where the issue has been resolved. For environments unable to patch instantly, administrators should disable the per-provider emailfallback option entirely if it is not strictly required for business operations. If the feature remains necessary, strict validation of the email_verified claim from the Identity Provider must be implemented at the application level before allowing any account linking or login fallback. Additionally, enforcing that local accounts linked via SSO require periodic password re-verification or binding to a verified phone number can add an additional layer of security. Regular audits of OpenID Connect configurations and monitoring for unusual login patterns associated with email-based fallbacks are also recommended to detect potential exploitation attempts in real-time.