Skip to main content
Vulnerability Database/CVE-2026-77386

CVE-2026-77386: Kyoo Media Server Auth Bypass Vulnerability

CVE-2026-77386 is an authentication bypass flaw in Kyoo media server that allows attackers to hijack user sessions through OIDC login manipulation. This post explains its impact, affected versions, and mitigation steps.

Published:

CVE-2026-77386 Overview

CVE-2026-77386 is an open redirect vulnerability [CWE-601] in Kyoo, a self-hosted media server for movies, series, and anime. Versions prior to 5.1.0 fail to validate the redirectUrl parameter used during OpenID Connect (OIDC) authentication. An unauthenticated attacker can initiate an OIDC login flow with an attacker-controlled destination. Because the one-use token is not bound to the browser session that initiated login, an attacker who tricks a victim into completing OIDC authentication can capture the token and exchange it for the victim's Kyoo session. The issue is fixed in Kyoo version 5.1.0.

Critical Impact

Successful exploitation results in full account takeover of the victim's Kyoo session through OIDC token theft.

Affected Products

  • Kyoo self-hosted media server versions prior to 5.1.0
  • Deployments using OIDC authentication providers
  • Instances exposing /auth/oidc/logged/{provider} and /auth/oidc/callback/{provider} endpoints

Discovery Timeline

  • 2026-09-18 - CVE-2026-77386 published to NVD
  • 2026-09-24 - Last updated in NVD database

Technical Details for CVE-2026-77386

Vulnerability Analysis

The vulnerability resides in the OIDC login handler in auth/oidc.go. When a client initiates login, the handler stores the caller-supplied redirectUrl alongside an opaque login state. After authentication completes, the endpoint /auth/oidc/logged/{provider} appends the provider name, one-use token, and any error value to that stored URL and issues a browser redirect without validating the destination against an allowlist.

The design compounds the flaw by failing to bind the one-use token to the browser session that initiated the login. Any party in possession of the token can complete the exchange at /auth/oidc/callback/{provider} and receive a Kyoo session for the authenticating victim. This converts an open redirect into a full authentication takeover primitive.

Root Cause

Two defects combine to produce the impact. First, redirectUrl is trusted as-is with no scheme, host, or allowlist validation before being used as a redirect target. Second, the login state and issued token lack any per-browser binding (no session cookie, PKCE-style verifier, or origin check) tying the callback exchange to the browser that initiated authentication.

Attack Vector

An attacker crafts a Kyoo OIDC login URL with redirectUrl pointing to an attacker-controlled host. The victim, already or newly authenticated to the identity provider, is induced to click the link (phishing, chat, embedded iframe). After the identity provider redirects back to Kyoo, /auth/oidc/logged/{provider} forwards the browser to the attacker with the token appended. The attacker then submits the captured token to /auth/oidc/callback/{provider} and receives the victim's session.

text
# Patch excerpt: .env.example introduces an OIDC redirect allowlist
# The url you can use to reach your kyoo instance. This is used during oidc to redirect users to your instance.
PUBLIC_URL=http://localhost:8901

# Extra post-login OIDC redirect targets, comma separated. The official web and
# mobile apps, plus loopback addresses (http://127.0.0.1, http://localhost) on
# any port, are always allowed; only add entries here for other third-party
# clients. Each entry is either a web origin (https://app.example.com) matched by
# scheme+host(+port), or a bare custom scheme (myapp) matched by scheme only.
# EXTRA_OIDC_REDIRECT_URLS=https://app.example.com,myapp

Source: GitHub Commit 02ab3af

Detect Identity Attacks the Moment Authentication Fails

Singularity™ Identity surfaces credential misuse, lateral movement, and privilege escalation in real time, so you can contain the breach before it spreads.

Stop Identity Attacks

Detection Methods for CVE-2026-77386

Indicators of Compromise

  • Requests to /api/auth/oidc/login/{provider} where the redirectUrl parameter references hosts outside the deployment's PUBLIC_URL or approved client list.
  • HTTP 302 responses from /auth/oidc/logged/{provider} containing token= query parameters redirected to external domains.
  • Successful /auth/oidc/callback/{provider} exchanges originating from IP addresses or user agents that do not match the browser that initiated the corresponding login.

Detection Strategies

  • Alert on outbound redirects issued by the Kyoo OIDC handler whose Location header host does not match the configured PUBLIC_URL or EXTRA_OIDC_REDIRECT_URLS allowlist.
  • Correlate the source IP and user-agent of the OIDC login initiation with the callback exchange for the same login state; mismatches indicate token replay.
  • Monitor reverse-proxy or WAF logs for anomalous redirectUrl values containing external schemes, encoded payloads, or unexpected hostnames.

Monitoring Recommendations

  • Centralize Kyoo authentication logs in a SIEM and retain the full request URL, referrer, and callback source for each OIDC flow.
  • Baseline normal OIDC redirect destinations per deployment and generate alerts for first-seen or externally hosted targets.
  • Review session creation events for accounts that received an unexpected new session immediately after an external redirect.

How to Mitigate CVE-2026-77386

Immediate Actions Required

  • Upgrade all Kyoo instances to version 5.1.0 or later, which enforces a redirect allowlist for OIDC post-login destinations.
  • Configure EXTRA_OIDC_REDIRECT_URLS only for legitimate third-party clients; official web, mobile, and loopback addresses are already permitted.
  • Invalidate active Kyoo sessions after upgrade and require users to re-authenticate through OIDC.

Patch Information

The fix is delivered in Kyoo v5.1.0 via commit 02ab3af8127a081295fd7bed103847173c0d7632. The patch introduces a scheme+host(+port) allowlist for web origins and scheme-only matching for bare custom schemes. See the GitHub Security Advisory GHSA-xhg6-v78p-xf44, Pull Request #1576, and Release v5.1.0 for full details.

Workarounds

  • Place Kyoo behind a reverse proxy or WAF that strips or rewrites the redirectUrl parameter to a trusted internal URL before forwarding requests to /api/auth/oidc/login/{provider}.
  • Restrict access to the Kyoo instance via VPN or IP allowlist until the upgrade is applied, reducing the attack surface for phishing-delivered exploit links.
  • Temporarily disable OIDC providers and require local authentication where operationally feasible.
bash
# Configuration example: restrict post-login OIDC redirects after upgrading to 5.1.0
PUBLIC_URL=https://kyoo.example.com
EXTRA_OIDC_REDIRECT_URLS=https://app.example.com,myapp

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.