Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessCraft OIDC login URL with attacker redirectUrl
-
DeliveryPhish victim into clicking link
-
ExploitVictim completes OIDC authentication at IdP
-
ExecutionLogin token appended, browser redirected to attacker site
-
PersistCapture one-use token at attacker destination
-
ImpactExchange token via /auth/oidc/callback for victim session
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V3 - Web Frontend Security Redirect URL validation
MITRE ATT&CK
1 technique across 1 tactic: Initial Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | 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. |
| Impact | 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. |
| Exploit ScenarioDerived | 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. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 18, 2026
Unvalidated OIDC redirect handling in the Kyoo self-hosted media server before 5.1.0 lets an unauthenticated attacker capture a victim's one-use login token and exchange it for that victim's Kyoo session. The attacker starts the OIDC login flow with an attacker-controlled redirectUrl; because the pre-fix code stored that URL alongside the opaque login state and appended the token, provider, and error values to it without validating the destination or binding the token to the browser session that began the flow, a social-engineered victim who completes authentication at their identity provider has the token delivered to the attacker's host, where it can be replayed through /auth/oidc/callback/{provider}. 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 and requiring no privileges or authentication, but gated on victim user interaction and on the instance having at least one OIDC provider configured and enabled; no public exploit identified at time of analysis.
RemediationAI
Upgrade to Kyoo 5.1.0, which is the vendor-released patch (release notes: https://github.com/zoriya/Kyoo/releases/tag/v5.1.0; advisory: https://github.com/zoriya/Kyoo/security/advisories/GHSA-xhg6-v78p-xf44; fix PR https://github.com/zoriya/Kyoo/pull/1576, commit 02ab3af8127a081295fd7bed103847173c0d7632). After upgrading, redirect targets are restricted by an allowlist and unlisted destinations are rejected with HTTP 400, so any legitimate third-party OIDC client must be registered via EXTRA_OIDC_REDIRECT_URLS as either a full web origin (for example https://app.example.com, matched by scheme, host, and port - include a non-default port) or a bare custom scheme (for example myapp, matched by scheme only); the official web app (PUBLIC_URL origin), the kyoo:// mobile scheme, and loopback addresses such as http://127.0.0.1 and http://localhost on any port are always permitted, and operators should expect login failures in unregistered clients until they add the entries - a deliberate, safe trade-off. If upgrading immediately is not possible, take compensating measures with the understanding that they are partial: temporarily disable the configured OIDC providers so the vulnerable login and callback endpoints are not reachable, accepting the loss of SSO and the need to fall back to another authentication method; avoid advertising or supporting third-party OIDC clients whose redirect destinations are not needed; and treat any login tokens observed in a client-supplied redirect URL as compromised and invalidate the resulting sessions. Patching is strongly preferred over these workarounds because the flaw also reflects a missing session binding on the one-use token, which no redirect validation performed outside the application can fully reproduce.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Kyoo is a Go-based, self-hosted media server for movies, series, and anime, and this flaw is CWE-601 (URL Redirection to Untrusted Site / open redirect) exercised through its OpenID Connect login flow in auth/oidc.go. When a user initiates OIDC login, Kyoo issues an opaque login state and stores it, but prior to 5.1.0 it also stored a caller-supplied redirectUrl with that state and later, at /auth/oidc/logged/{provider}, appended the provider name, one-use login token, and error values to the stored URL before issuing the browser redirect - with no destination validation and no binding of the token to the browser session that started the flow. That combination turns an ordinary open redirect into credential theft: the attacker supplies their own destination, induces the victim to complete authentication, receives the one-use token at that destination, and presents it to /auth/oidc/callback/{provider} to obtain the victim's Kyoo session. The fix in 5.1.0 adds an isAllowedRedirectUrl check backed by a redirect allowlist: the PUBLIC_URL origin (matched by scheme plus host, including port), the official mobile app's kyoo:// scheme, loopback addresses (http://127.0.0.1, http://localhost, http://[::1]) on any port for native/CLI apps per RFC 8252, and any operator-defined EXTRA_OIDC_REDIRECT_URLS entries - each entry being either a web origin matched by scheme+host(+port) or a bare custom scheme matched by scheme only; anything not covered is rejected with HTTP 400. The CPE cpe:2.3:a:zoriya:kyoo:*:*:*:*:*:*:*:* indicates the affected range is the entire pre-5.1.0 Kyoo codebase rather than a single component. The accompanying config changes validate OIDC provider settings and report the specific missing environment variables, which strengthens the callback handling path but does not itself address the redirect flaw.
Know when Kyoo gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N
Unauthenticated network attack (PR:N/AV:N) but requires victim to complete OIDC login (UI:R); stolen session gives full account read (C:H) and some ability to act as the victim (I:L, vs vendor's I:N).
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
Kyoo is a self-hosted media server focused on movies, series, and anime. Prior to 5.1.0, an unauthenticated attacker could initiate the OIDC login flow with an attacker-controlled redirectUrl. The login handling in auth/oidc.go stored that URL with the opaque login state, and /auth/oidc/logged/{provider} appended the provider, token, and error values before redirecting the victim's browser without validating the destination. Because the one-use token was not bound to the browser session that initiated login, an attacker who induced a victim to complete OIDC authentication could capture the token at the attacker-controlled destination and exchange it through /auth/oidc/callback/{provider} for the victim's Kyoo session. This issue is fixed in version 5.1.0.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
EUVD-2026-83205
NVD
CVE.org
EPSS
Vulnrichment
GitHub
Exploit-DB