<?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://db.gcve.eu</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>Mon, 26 Oct 2026 04:36:21 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-113798 — Electron: Pointer lock permission requests can be attributed to the wrong frame</title>
      <link>https://db.gcve.eu/vuln/cve-2026-113798</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; electron&lt;/p&gt;
&lt;p&gt;Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to versions 42.11.9, 43.7.6, 44.5.0, and 45.0.0-alpha.13, pointerLock permission requests from some cross-origin iframes caused session.setPermissionRequestHandler() to receive the top-level frame&amp;#39;s requestingUrl and isMainFrame values instead of those of the requesting frame. An application that embeds untrusted iframe content and grants pointer lock based on the requesting origin could therefore grant the permission under the top-level page&amp;#39;s identity. Applications that deny pointerLock for untrusted embedded content are not affected. This issue is fixed in versions 42.11.9, 43.7.6, 44.5.0, and 45.0.0-alpha.13.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; electron&lt;/p&gt;
&lt;p&gt;Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to versions 42.11.9, 43.7.6, 44.5.0, and 45.0.0-alpha.13, pointerLock permission requests from some cross-origin iframes caused session.setPermissionRequestHandler() to receive the top-level frame&amp;#39;s requestingUrl and isMainFrame values instead of those of the requesting frame. An application that embeds untrusted iframe content and grants pointer lock based on the requesting origin could therefore grant the permission under the top-level page&amp;#39;s identity. Applications that deny pointerLock for untrusted embedded content are not affected. This issue is fixed in versions 42.11.9, 43.7.6, 44.5.0, and 45.0.0-alpha.13.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-113798</guid>
    </item>
  </channel>
</rss>
