<?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>Fri, 09 Oct 2026 00:04:09 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-28006</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-28006</link>
      <description>EUVD-2026-28006</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-28006</guid>
    </item>
    <item>
      <title>fkie_cve-2021-32619</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2021-32619</link>
      <description>&lt;p&gt;Deno is a runtime for JavaScript and TypeScript that uses V8 and is built in Rust. In Deno versions 1.5.0 to 1.10.1, modules that are dynamically imported through `import()` or `new Worker` might have been able to bypass network and file system permission checks when statically importing other modules. The vulnerability has been patched in Deno release 1.10.2.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Deno is a runtime for JavaScript and TypeScript that uses V8 and is built in Rust. In Deno versions 1.5.0 to 1.10.1, modules that are dynamically imported through `import()` or `new Worker` might have been able to bypass network and file system permission checks when statically importing other modules. The vulnerability has been patched in Deno release 1.10.2.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2021-32619</guid>
    </item>
    <item>
      <title>GHSA-xpwj-7v8q-mcgj — Deno's static imports inside dynamically imported modules do not adhere to permission checks</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-xpwj-7v8q-mcgj</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: deno&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Modules that are dynamically imported through `import()` or `new Worker` might have been able to bypass network and file system permission checks when statically importing other modules. In Deno 1.5.x and 1.6.x only programs dynamically importing (especially transitively) untrusted code are affected. In Deno 1.7.x all programs importing (especially transitively) untrusted code are affected.&lt;/p&gt;
&lt;p&gt;In effect an attacker in control of a (possibly remote) module in a programs module graph has been able to, **irrespective of permissions**:
1. initiate GET requests to arbitrary URLs on the internet (including LAN) and possibly read (parts of) the contents of these resources.
2. check for existence of arbitrary paths on the file system, and possibly read (parts of) the contents of these files.&lt;/p&gt;
&lt;p&gt;In Deno 1.5.x (October 27th, 2020) and Deno 1.6.x (December 8th, 2020) the attacker module had to have been granted permissions to load dynamically through the network / fs read permission. Since Deno 1.7.x (January 19th, 2021) this vulnerability was able to be exploited in a fully sandboxed isolate (without any permissions). This vulnerability was not present in releases prior to 1.5.0.&lt;/p&gt;
&lt;p&gt;Arbitrary non-GET requests, control over request headers, or file system writes are not possible through this vulnerability. Users of the `deno_core`, `deno_runtime`, or other `deno_*` crates are not affected. This is a Deno CLI only vulnerability.&lt;/p&gt;
&lt;p&gt;We are relatively confident this was not abused in…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: deno&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Modules that are dynamically imported through `import()` or `new Worker` might have been able to bypass network and file system permission checks when statically importing other modules. In Deno 1.5.x and 1.6.x only programs dynamically importing (especially transitively) untrusted code are affected. In Deno 1.7.x all programs importing (especially transitively) untrusted code are affected.&lt;/p&gt;
&lt;p&gt;In effect an attacker in control of a (possibly remote) module in a programs module graph has been able to, **irrespective of permissions**:
1. initiate GET requests to arbitrary URLs on the internet (including LAN) and possibly read (parts of) the contents of these resources.
2. check for existence of arbitrary paths on the file system, and possibly read (parts of) the contents of these files.&lt;/p&gt;
&lt;p&gt;In Deno 1.5.x (October 27th, 2020) and Deno 1.6.x (December 8th, 2020) the attacker module had to have been granted permissions to load dynamically through the network / fs read permission. Since Deno 1.7.x (January 19th, 2021) this vulnerability was able to be exploited in a fully sandboxed isolate (without any permissions). This vulnerability was not present in releases prior to 1.5.0.&lt;/p&gt;
&lt;p&gt;Arbitrary non-GET requests, control over request headers, or file system writes are not possible through this vulnerability. Users of the `deno_core`, `deno_runtime`, or other `deno_*` crates are not affected. This is a Deno CLI only vulnerability.&lt;/p&gt;
&lt;p&gt;We are relatively confident this was not abused in…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-xpwj-7v8q-mcgj</guid>
    </item>
    <item>
      <title>gsd-2021-32619</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2021-32619</link>
      <description>gsd-2021-32619</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2021-32619</guid>
    </item>
  </channel>
</rss>
