<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 06 Oct 2026 13:52:48 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-373568</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-373568</link>
      <description>EUVD-2026-373568</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-373568</guid>
    </item>
    <item>
      <title>fkie_cve-2026-77386</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-77386</link>
      <description>&lt;p&gt;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&amp;#39;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&amp;#39;s Kyoo session. This issue is fixed in version 5.1.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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&amp;#39;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&amp;#39;s Kyoo session. This issue is fixed in version 5.1.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-77386</guid>
    </item>
  </channel>
</rss>
