<?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>Sun, 04 Oct 2026 11:28:59 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-273779</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-273779</link>
      <description>EUVD-2026-273779</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-273779</guid>
    </item>
    <item>
      <title>fkie_cve-2026-27204</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-27204</link>
      <description>&lt;p&gt;Wasmtime is a runtime for WebAssembly. Prior to versions 24.0.6, 36.0.6, 4.0.04, 41.0.4, and 42.0.0, Wasmtime&amp;#39;s implementation of WASI host interfaces are susceptible to guest-controlled resource exhaustion on the host. Wasmtime did not appropriately place limits on resource allocations requested by the guests. This serves as a Denial of Service vector. Wasmtime 24.0.6, 36.0.6, 40.0.4, 41.0.4, and 42.0.0 have all been released with the fix for this issue. These versions do not prevent this issue in their default configuration to avoid breaking preexisting behaviors. All versions of Wasmtime have appropriate knobs to prevent this behavior, and Wasmtime 42.0.0-and-later will have these knobs tuned by default to prevent this issue from happening. There are no known workarounds for this issue without upgrading. Embedders are recommended to upgrade and configure their embeddings as necessary to prevent possibly-malicious guests from triggering this issue.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Wasmtime is a runtime for WebAssembly. Prior to versions 24.0.6, 36.0.6, 4.0.04, 41.0.4, and 42.0.0, Wasmtime&amp;#39;s implementation of WASI host interfaces are susceptible to guest-controlled resource exhaustion on the host. Wasmtime did not appropriately place limits on resource allocations requested by the guests. This serves as a Denial of Service vector. Wasmtime 24.0.6, 36.0.6, 40.0.4, 41.0.4, and 42.0.0 have all been released with the fix for this issue. These versions do not prevent this issue in their default configuration to avoid breaking preexisting behaviors. All versions of Wasmtime have appropriate knobs to prevent this behavior, and Wasmtime 42.0.0-and-later will have these knobs tuned by default to prevent this issue from happening. There are no known workarounds for this issue without upgrading. Embedders are recommended to upgrade and configure their embeddings as necessary to prevent possibly-malicious guests from triggering this issue.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-27204</guid>
    </item>
    <item>
      <title>GHSA-852m-cvvp-9p4w — Wasmtime WASI implementations are vulnerable to guest-controlled resource exhaustion</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-852m-cvvp-9p4w</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: wasmtime&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Wasmtime&amp;#39;s implementation of WASI host interfaces are susceptible to guest-controlled resource exhaustion on the host. Wasmtime did not appropriately place limits on resource allocations requested by the guests. This serves as a Denial of Service vector where a guest can induce a range of crashing behaviors on the host such as:&lt;/p&gt;
&lt;p&gt;* Allocating arbitrarily large amounts of host memory.
* Causing an allocation failure on the host, which in Rust defaults to aborting the process.
* Causing a panic on the host due to over-large allocations being performed.
* Cause degredation in performance of the host by holding excessive host memory alive.&lt;/p&gt;
&lt;p&gt;Wasmtime&amp;#39;s [security bug policy](https://docs.wasmtime.dev/security-what-is-considered-a-security-vulnerability.html) considers all of these behaviors a security vulnerability. Wasmtime&amp;#39;s implementation of WASI has a number of different ways that resource exhaustion could happen, and fixing any one of them is insufficient from solving this vulnerability. A number of individual issues are grouped within this advisory and as a whole represent the known ways that guests can exhaust resources on the host.&lt;/p&gt;
&lt;p&gt;An example of guest-controlled resource exhaustion within Wasmtime&amp;#39;s implementation of WASI is guests could repeatedly allocate handles to themselves without limit. Some APIs also caused the host to perform a guest-controlled-sized allocation of a buffer on the host for I/O operations. Other APIs could force the host to buffer arbitr…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: wasmtime&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Wasmtime&amp;#39;s implementation of WASI host interfaces are susceptible to guest-controlled resource exhaustion on the host. Wasmtime did not appropriately place limits on resource allocations requested by the guests. This serves as a Denial of Service vector where a guest can induce a range of crashing behaviors on the host such as:&lt;/p&gt;
&lt;p&gt;* Allocating arbitrarily large amounts of host memory.
* Causing an allocation failure on the host, which in Rust defaults to aborting the process.
* Causing a panic on the host due to over-large allocations being performed.
* Cause degredation in performance of the host by holding excessive host memory alive.&lt;/p&gt;
&lt;p&gt;Wasmtime&amp;#39;s [security bug policy](https://docs.wasmtime.dev/security-what-is-considered-a-security-vulnerability.html) considers all of these behaviors a security vulnerability. Wasmtime&amp;#39;s implementation of WASI has a number of different ways that resource exhaustion could happen, and fixing any one of them is insufficient from solving this vulnerability. A number of individual issues are grouped within this advisory and as a whole represent the known ways that guests can exhaust resources on the host.&lt;/p&gt;
&lt;p&gt;An example of guest-controlled resource exhaustion within Wasmtime&amp;#39;s implementation of WASI is guests could repeatedly allocate handles to themselves without limit. Some APIs also caused the host to perform a guest-controlled-sized allocation of a buffer on the host for I/O operations. Other APIs could force the host to buffer arbitr…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-852m-cvvp-9p4w</guid>
    </item>
    <item>
      <title>RUSTSEC-2026-0020 — Guest-controlled resource exhaustion in WASI implementations</title>
      <link>https://cve.radiocsirt.org/vuln/rustsec-2026-0020</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: wasmtime&lt;/p&gt;
&lt;p&gt;This is an entry in the RustSec database for the Wasmtime security advisory
located at
https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-852m-cvvp-9p4w
For more information see the GitHub-hosted security advisory.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: wasmtime&lt;/p&gt;
&lt;p&gt;This is an entry in the RustSec database for the Wasmtime security advisory
located at
https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-852m-cvvp-9p4w
For more information see the GitHub-hosted security advisory.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rustsec-2026-0020</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-27204</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-27204</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:24.04:LTS: rust-wasmtime, Ubuntu:25.10: rust-wasmtime, Ubuntu:26.04:LTS: rust-wasmtime&lt;/p&gt;
&lt;p&gt;Wasmtime is a runtime for WebAssembly. Prior to versions 24.0.6, 36.0.6, 4.0.04, 41.0.4, and 42.0.0, Wasmtime&amp;#39;s implementation of WASI host interfaces are susceptible to guest-controlled resource exhaustion on the host. Wasmtime did not appropriately place limits on resource allocations requested by the guests. This serves as a Denial of Service vector. Wasmtime 24.0.6, 36.0.6, 40.0.4, 41.0.4, and 42.0.0 have all been released with the fix for this issue. These versions do not prevent this issue in their default configuration to avoid breaking preexisting behaviors. All versions of Wasmtime have appropriate knobs to prevent this behavior, and Wasmtime 42.0.0-and-later will have these knobs tuned by default to prevent this issue from happening. There are no known workarounds for this issue without upgrading. Embedders are recommended to upgrade and configure their embeddings as necessary to prevent possibly-malicious guests from triggering this issue.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:24.04:LTS: rust-wasmtime, Ubuntu:25.10: rust-wasmtime, Ubuntu:26.04:LTS: rust-wasmtime&lt;/p&gt;
&lt;p&gt;Wasmtime is a runtime for WebAssembly. Prior to versions 24.0.6, 36.0.6, 4.0.04, 41.0.4, and 42.0.0, Wasmtime&amp;#39;s implementation of WASI host interfaces are susceptible to guest-controlled resource exhaustion on the host. Wasmtime did not appropriately place limits on resource allocations requested by the guests. This serves as a Denial of Service vector. Wasmtime 24.0.6, 36.0.6, 40.0.4, 41.0.4, and 42.0.0 have all been released with the fix for this issue. These versions do not prevent this issue in their default configuration to avoid breaking preexisting behaviors. All versions of Wasmtime have appropriate knobs to prevent this behavior, and Wasmtime 42.0.0-and-later will have these knobs tuned by default to prevent this issue from happening. There are no known workarounds for this issue without upgrading. Embedders are recommended to upgrade and configure their embeddings as necessary to prevent possibly-malicious guests from triggering this issue.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-27204</guid>
    </item>
  </channel>
</rss>
