Kyoo EUVD-2026-83205

Requires the Kyoo instance (version prior to 5.1.0) to have at least one OIDC login provider configured and enabled, since the flaw lives in the OIDC login/callback flow (auth/oidc.go). Exploitation is unauthenticated but depends on victim interaction: the attacker must induce a logged-out victim to open an attacker-crafted OIDC login link and complete authentication at their identity provider (UI:R). The pre-fix behavior - storing an unvalidated attacker-controlled redirectUrl with the opaque login state and appending the one-use token to that destination without binding it to the initiating browser session - is what enables token capture; the fix restricts redirects to PUBLIC_URL origin, kyoo:// scheme, loopback addresses, and EXTRA_OIDC_REDIRECT_URLS entries, rejecting others with 400. Limiting factors: needs social engineering to trigger the victim login, applies only to OIDC-enabled deployments, and only to versions below 5.1.0.

The CVSS 3.1 base score is 6.5 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N) - network-reachable, no authentication or privileges required, but gated on victim user interaction (UI:R). Although CWE-601/'Open Redirect' undersells it, the real impact is OIDC login-token theft leading to victim session/account takeover, which is why the vendor rated confidentiality High. There is no EPSS score, no CISA KEV listing, and no public proof-of-concept exploit code in the input; the GitHub security advisory (GHSA-xhg6-v78p-xf44) and the fix PR/commit describe the mechanism in enough detail to reconstruct an attack, but that is not the same as a released exploit - no public exploit identified at time of analysis. Weighing signals: this is a credible confidentiality/account-takeover flaw, but real-world risk is tempered by (a) required social-engineering interaction - the victim must be lured into completing an OIDC login - and (b) low deployment footprint of a niche self-hosted media server. Net: a genuine, patch-worthy vulnerability for anyone running Kyoo with OIDC, but not a mass-exploitation emergency. Note one conflict to verify: the vendor sets I:N despite the outcome being full session takeover, which normally implies at least some integrity impact - see assessed vector.

An attacker crafts a Kyoo OIDC login link carrying an attacker-controlled redirectUrl and lures a legitimate Kyoo user (e.g., via a phishing message) into clicking it and completing OIDC authentication with their identity provider. Because the one-use login token is not bound to the browser session that started the flow, it is appended to the redirect and delivered to the attacker's destination, where the attacker captures it and exchanges it via /auth/oidc/callback/{provider} to obtain the victim's authenticated Kyoo session. No public exploit code is identified, but the advisory and fix commit document the flow in reproducible detail.