CVE-2026-77386 in Kyoo
Summary
by MITRE • 09/18/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in Kyoo prior to version 5.1.0 represents a critical authentication bypass mechanism rooted in improper validation of redirect URIs during OpenID Connect flows. As a self-hosted media server, Kyoo relies on external identity providers for user authentication, utilizing the OIDC protocol to manage session establishment. The core technical flaw lies within the implementation of the authentication handler located at auth/oidc.go and the subsequent callback processing logic. When an unauthenticated attacker initiates the login flow, they are able to supply a malicious redirectUrl parameter that points to a server under their control. This URL is stored alongside opaque login state data without sufficient validation against a whitelist or strict origin checks. Consequently, upon successful authentication by the identity provider, the application redirects the victim's browser to this attacker-controlled destination rather than a trusted internal endpoint.
The operational impact of this flaw is severe because it allows for complete session hijacking through token interception and replay attacks. The vulnerability exploits two distinct weaknesses: first, the lack of strict validation on the redirect URI during the initial authorization request phase, which permits arbitrary destinations; second, the failure to bind the one-time authentication token to the specific browser session or origin that initiated the login process. Because the token is not cryptographically bound to the initiating context, an attacker can induce a victim to complete the OIDC authentication flow by tricking them into clicking a malicious link containing the crafted redirectUrl. Once the victim authenticates with their identity provider, the application redirects the browser to the attacker's server, appending the provider name, access token, and error values as query parameters or fragments. The attacker can then capture these credentials from their logs or request data.
Following the interception of the authentication token, the attacker proceeds to exchange it for a valid Kyoo session by calling the /auth/oidc/callback/{provider} endpoint with the stolen token. Since the application does not verify that this callback originates from the same context as the initial login request, it accepts the external token and establishes an authenticated session for the victim's account on behalf of the attacker. This effectively grants the adversary full administrative or user-level access to the Kyoo instance without knowing any valid credentials. The attack vector is classified under CWE-601, which describes URL Redirection to Untrusted Site, as well as CWE-384, Session Fixation, due to the reuse of session identifiers in an uncontrolled manner. From a tactical perspective, this aligns with MITRE ATT&CK technique T1528, Steal Application Access Token, where adversaries harvest tokens from identity providers to gain unauthorized access to applications and services.
Mitigation for this vulnerability requires immediate upgrading to Kyoo version 5.1.0 or later, which addresses the root cause by implementing strict validation of redirect URIs against a predefined allowlist and ensuring that authentication tokens are bound to the specific browser session context. For organizations unable to upgrade immediately, deploying a Web Application Firewall with rules capable of detecting and blocking OIDC flows containing suspicious or non-whitelisted redirect parameters can provide temporary protection. Additionally, enforcing Content Security Policy headers and implementing SameSite cookie attributes on all session cookies can help mitigate some aspects of cross-site request forgery and token theft associated with this flaw. Regular security audits focusing on authentication flow implementations are recommended to prevent similar misconfigurations in other identity-aware applications.