Vikunja EUVD-2026-95993

Requires three specific conditions, all CONFIRMED by the advisory: (1) an administrator has enabled the per-provider emailfallback:true option, which defaults to false - a default install is NOT exploitable; (2) the configured OIDC issuer allows the attacker to assert the victim's unverified email, e.g. a self-service IdP (Keycloak/Authentik/Auth0/Dex with editable email), a mixed federation, or a multi-tenant Entra /common app - iss and aud are pinned, so the attacker controls only the email claim, not the issuer; (3) the victim has a pre-existing LOCAL (issuer=local) account that does NOT have TOTP enabled - the 2.3.0 enforceTOTPIfRequired gate protects TOTP users, and pure-SSO (non-local) accounts are not matched. Limiting factors: non-default configuration, dependence on the issuer's email-assertion policy, and the TOTP/local-account scoping substantially narrow real-world exposure despite the unauthenticated, no-interaction nature of the flaw.

This is a genuine high-priority flaw for the narrow population running the vulnerable configuration, but not a mass-exploitation emergency. Signals: the vendor CVSS 4.0 vector scores 7.5 with VC:H/VI:H/VA:H (full local-account takeover) and PR:N/UI:N (unauthenticated, no victim interaction), matching the well-understood nOAuth class (cf. Grafana CVE-2023-3128). No EPSS score, no CISA KEV listing, and no weaponized public exploit were provided, so exploitation is not confirmed in the wild. The vendor set AV:L with AT:P; this is questionable and conflicting - the attack is actually driven through Vikunja's network-facing OIDC callback, so the access vector looks network-reachable rather than local, while the real gating factor (attacker must coerce the issuer into emitting a token carrying the victim's unverified email) is better modeled as an attack requirement/complexity than as AV:L. VERIFY AV WITH VENDOR: the description and advisory imply a network login flow, yet the input vector says AV:L. The dominant risk limiter is configuration, not CVSS: the vulnerable path exists only when an admin has turned on the non-default per-provider emailfallback option, the IdP must let an attacker assert an arbitrary email, and the victim account must be a local (issuer=local) non-TOTP account. Net: treat as urgent (patch to 2.4.0) if you run OIDC emailfallback against a self-service or multi-tenant issuer; otherwise default installs are unaffected.

An organization runs Vikunja with emailfallback enabled against a self-service or multi-tenant IdP (e.g. Keycloak/Authentik/Auth0/Dex with editable email, or a multi-tenant Entra /common app). An attacker controls an identity at that issuer, sets the email claim to a victim's address, and completes the OIDC callback to Vikunja. Because Vikunja links the SSO login to the victim's pre-existing local account using only the email claim - never checking email_verified/xms_edov and never requiring the password - the attacker receives a full session as the victim with no victim interaction. No public exploit code was identified, though the advisory documents the exact vulnerable code path.