<?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>Thu, 08 Oct 2026 13:54:11 +0000</lastBuildDate>
    <item>
      <title>bdu:2022-05144</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2022-05144</link>
      <description>bdu:2022-05144</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2022-05144</guid>
    </item>
    <item>
      <title>EUVD-2026-234047</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-234047</link>
      <description>EUVD-2026-234047</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-234047</guid>
    </item>
    <item>
      <title>fkie_cve-2022-29247</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2022-29247</link>
      <description>&lt;p&gt;Electron is a framework for writing cross-platform desktop applications using JavaScript (JS), HTML, and CSS. A vulnerability in versions prior to 18.0.0-beta.6, 17.2.0, 16.2.6, and 15.5.5 allows a renderer with JS execution to obtain access to a new renderer process with `nodeIntegrationInSubFrames` enabled which in turn allows effective access to `ipcRenderer`. The `nodeIntegrationInSubFrames` option does not implicitly grant Node.js access. Rather, it depends on the existing sandbox setting. If an application is sandboxed, then `nodeIntegrationInSubFrames` just gives access to the sandboxed renderer APIs, which include `ipcRenderer`. If the application then additionally exposes IPC messages without IPC `senderFrame` validation that perform privileged actions or return confidential data this access to `ipcRenderer` can in turn compromise your application / user even with the sandbox enabled. Electron versions 18.0.0-beta.6, 17.2.0, 16.2.6, and 15.5.5 contain a fix for this issue. As a workaround, ensure that all IPC message handlers appropriately validate `senderFrame`.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Electron is a framework for writing cross-platform desktop applications using JavaScript (JS), HTML, and CSS. A vulnerability in versions prior to 18.0.0-beta.6, 17.2.0, 16.2.6, and 15.5.5 allows a renderer with JS execution to obtain access to a new renderer process with `nodeIntegrationInSubFrames` enabled which in turn allows effective access to `ipcRenderer`. The `nodeIntegrationInSubFrames` option does not implicitly grant Node.js access. Rather, it depends on the existing sandbox setting. If an application is sandboxed, then `nodeIntegrationInSubFrames` just gives access to the sandboxed renderer APIs, which include `ipcRenderer`. If the application then additionally exposes IPC messages without IPC `senderFrame` validation that perform privileged actions or return confidential data this access to `ipcRenderer` can in turn compromise your application / user even with the sandbox enabled. Electron versions 18.0.0-beta.6, 17.2.0, 16.2.6, and 15.5.5 contain a fix for this issue. As a workaround, ensure that all IPC message handlers appropriately validate `senderFrame`.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2022-29247</guid>
    </item>
    <item>
      <title>GHSA-mq8j-3h7h-p8g7 — Compromised child renderer processes could obtain IPC access without nodeIntegrationInSubFrames being enabled</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-mq8j-3h7h-p8g7</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: electron&lt;/p&gt;
&lt;p&gt;### Impact
This vulnerability allows a renderer with JS execution to obtain access to a new renderer process with `nodeIntegrationInSubFrames` enabled which in turn allows effective access to `ipcRenderer`.&lt;/p&gt;
&lt;p&gt;Please note the misleadingly named `nodeIntegrationInSubFrames` option does not implicitly grant Node.js access rather it depends on the existing `sandbox` setting.  If your application is sandboxed then `nodeIntegrationInSubFrames` just gives access to the sandboxed renderer APIs (which includes `ipcRenderer`).&lt;/p&gt;
&lt;p&gt;If your application then additionally exposes IPC messages without IPC `senderFrame` validation that perform privileged actions or return confidential data this access to `ipcRenderer` can in turn compromise your application / user even with the sandbox enabled.&lt;/p&gt;
&lt;p&gt;### Patches
This has been patched and the following Electron versions contain the fix:&lt;/p&gt;
&lt;p&gt;* `18.0.0-beta.6`
* `17.2.0`
* `16.2.6`
* `15.5.5`&lt;/p&gt;
&lt;p&gt;### Workarounds
Ensure that all IPC message handlers appropriately validate `senderFrame` as per our [security tutorial here](https://github.com/electron/electron/blob/main/docs/tutorial/security.md#17-validate-the-sender-of-all-ipc-messages).&lt;/p&gt;
&lt;p&gt;### For more information&lt;/p&gt;
&lt;p&gt;If you have any questions or comments about this advisory, email us at [security@electronjs.org](mailto:security@electronjs.org).&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: electron&lt;/p&gt;
&lt;p&gt;### Impact
This vulnerability allows a renderer with JS execution to obtain access to a new renderer process with `nodeIntegrationInSubFrames` enabled which in turn allows effective access to `ipcRenderer`.&lt;/p&gt;
&lt;p&gt;Please note the misleadingly named `nodeIntegrationInSubFrames` option does not implicitly grant Node.js access rather it depends on the existing `sandbox` setting.  If your application is sandboxed then `nodeIntegrationInSubFrames` just gives access to the sandboxed renderer APIs (which includes `ipcRenderer`).&lt;/p&gt;
&lt;p&gt;If your application then additionally exposes IPC messages without IPC `senderFrame` validation that perform privileged actions or return confidential data this access to `ipcRenderer` can in turn compromise your application / user even with the sandbox enabled.&lt;/p&gt;
&lt;p&gt;### Patches
This has been patched and the following Electron versions contain the fix:&lt;/p&gt;
&lt;p&gt;* `18.0.0-beta.6`
* `17.2.0`
* `16.2.6`
* `15.5.5`&lt;/p&gt;
&lt;p&gt;### Workarounds
Ensure that all IPC message handlers appropriately validate `senderFrame` as per our [security tutorial here](https://github.com/electron/electron/blob/main/docs/tutorial/security.md#17-validate-the-sender-of-all-ipc-messages).&lt;/p&gt;
&lt;p&gt;### For more information&lt;/p&gt;
&lt;p&gt;If you have any questions or comments about this advisory, email us at [security@electronjs.org](mailto:security@electronjs.org).&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-mq8j-3h7h-p8g7</guid>
    </item>
    <item>
      <title>gsd-2022-29247</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2022-29247</link>
      <description>gsd-2022-29247</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2022-29247</guid>
    </item>
  </channel>
</rss>
