<?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>Sat, 03 Oct 2026 08:00:07 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-337300</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-337300</link>
      <description>EUVD-2026-337300</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-337300</guid>
    </item>
    <item>
      <title>fkie_cve-2026-34971</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-34971</link>
      <description>&lt;p&gt;Wasmtime is a runtime for WebAssembly. From 32.0.0 to before 36.0.7, 42.0.2, and 43.0.1, Wasmtime&amp;#39;s Cranelift compilation backend contains a bug on aarch64 when performing a certain shape of heap accesses which means that the wrong address is accessed. When combined with explicit bounds checks a guest WebAssembly module this can create a situation where there are two diverging computations for the same address: one for the address to bounds-check and one for the address to load. This difference in address being operated on means that a guest module can pass a bounds check but then load a different address. Combined together this enables an arbitrary read/write primitive for guest WebAssembly when accesssing host memory. This is a sandbox escape as guests are able to read/write arbitrary host memory. This vulnerability has a few ingredients, all of which must be met, for this situation to occur and bypass the sandbox restrictions. This miscompiled shape of load only occurs on 64-bit WebAssembly linear memories, or when Config::wasm_memory64 is enabled. 32-bit WebAssembly is not affected. Spectre mitigations or signals-based-traps must be disabled. When spectre mitigations are enabled then the offending shape of load is not generated. When signals-based-traps are disabled then spectre mitigations are also automatically disabled. The specific bug in Cranelift is a miscompile of a load of the shape load(iadd(base, ishl(index, amt))) where amt is a constant. The amt value is mask…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Wasmtime is a runtime for WebAssembly. From 32.0.0 to before 36.0.7, 42.0.2, and 43.0.1, Wasmtime&amp;#39;s Cranelift compilation backend contains a bug on aarch64 when performing a certain shape of heap accesses which means that the wrong address is accessed. When combined with explicit bounds checks a guest WebAssembly module this can create a situation where there are two diverging computations for the same address: one for the address to bounds-check and one for the address to load. This difference in address being operated on means that a guest module can pass a bounds check but then load a different address. Combined together this enables an arbitrary read/write primitive for guest WebAssembly when accesssing host memory. This is a sandbox escape as guests are able to read/write arbitrary host memory. This vulnerability has a few ingredients, all of which must be met, for this situation to occur and bypass the sandbox restrictions. This miscompiled shape of load only occurs on 64-bit WebAssembly linear memories, or when Config::wasm_memory64 is enabled. 32-bit WebAssembly is not affected. Spectre mitigations or signals-based-traps must be disabled. When spectre mitigations are enabled then the offending shape of load is not generated. When signals-based-traps are disabled then spectre mitigations are also automatically disabled. The specific bug in Cranelift is a miscompile of a load of the shape load(iadd(base, ishl(index, amt))) where amt is a constant. The amt value is mask…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-34971</guid>
    </item>
    <item>
      <title>GHSA-jhxm-h53p-jm7w — Wasmtime: Miscompiled guest heap access enables sandbox escape on aarch64 Cranelift</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-jhxm-h53p-jm7w</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 Cranelift compilation backend contains a bug on aarch64 when performing a certain shape of heap accesses which means that the wrong address is accessed. When combined with explicit bounds checks a guest WebAssembly module this can create a situation where there are two diverging computations for the same address: one for the address to bounds-check and one for the address to load. This difference in address being operated on means that a guest module can pass a bounds check but then load a different address. Combined together this enables an arbitrary read/write primitive for guest WebAssembly when accesssing host memory. This is a sandbox escape as guests are able to read/write arbitrary host memory.&lt;/p&gt;
&lt;p&gt;This vulnerability has a few ingredients, all of which must be met, for this situation to occur and bypass the sandbox restrictions:&lt;/p&gt;
&lt;p&gt;* This miscompiled shape of load only occurs on 64-bit WebAssembly linear memories, or when `Config::wasm_memory64` is enabled. 32-bit WebAssembly is not affected.
* Spectre mitigations or signals-based-traps must be disabled. When spectre mitigations are enabled then the offending shape of load is not generated. When signals-based-traps are disabled then spectre mitigations are also automatically disabled.&lt;/p&gt;
&lt;p&gt;The specific bug in Cranelift is a miscompile of a load of the shape `load(iadd(base, ishl(index, amt)))` where `amt` is a constant. The `amt` value is masked incorrectly to test if it&amp;#39;s a certain value, and this incor…&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 Cranelift compilation backend contains a bug on aarch64 when performing a certain shape of heap accesses which means that the wrong address is accessed. When combined with explicit bounds checks a guest WebAssembly module this can create a situation where there are two diverging computations for the same address: one for the address to bounds-check and one for the address to load. This difference in address being operated on means that a guest module can pass a bounds check but then load a different address. Combined together this enables an arbitrary read/write primitive for guest WebAssembly when accesssing host memory. This is a sandbox escape as guests are able to read/write arbitrary host memory.&lt;/p&gt;
&lt;p&gt;This vulnerability has a few ingredients, all of which must be met, for this situation to occur and bypass the sandbox restrictions:&lt;/p&gt;
&lt;p&gt;* This miscompiled shape of load only occurs on 64-bit WebAssembly linear memories, or when `Config::wasm_memory64` is enabled. 32-bit WebAssembly is not affected.
* Spectre mitigations or signals-based-traps must be disabled. When spectre mitigations are enabled then the offending shape of load is not generated. When signals-based-traps are disabled then spectre mitigations are also automatically disabled.&lt;/p&gt;
&lt;p&gt;The specific bug in Cranelift is a miscompile of a load of the shape `load(iadd(base, ishl(index, amt)))` where `amt` is a constant. The `amt` value is masked incorrectly to test if it&amp;#39;s a certain value, and this incor…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-jhxm-h53p-jm7w</guid>
    </item>
    <item>
      <title>RUSTSEC-2026-0096 — Miscompiled guest heap access enables sandbox escape on aarch64 Cranelift</title>
      <link>https://cve.radiocsirt.org/vuln/rustsec-2026-0096</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-jhxm-h53p-jm7w
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-jhxm-h53p-jm7w
For more information see the GitHub-hosted security advisory.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rustsec-2026-0096</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-34971</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-34971</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. From 32.0.0 to before 36.0.7, 42.0.2, and 43.0.1, Wasmtime&amp;#39;s Cranelift compilation backend contains a bug on aarch64 when performing a certain shape of heap accesses which means that the wrong address is accessed. When combined with explicit bounds checks a guest WebAssembly module this can create a situation where there are two diverging computations for the same address: one for the address to bounds-check and one for the address to load. This difference in address being operated on means that a guest module can pass a bounds check but then load a different address. Combined together this enables an arbitrary read/write primitive for guest WebAssembly when accesssing host memory. This is a sandbox escape as guests are able to read/write arbitrary host memory. This vulnerability has a few ingredients, all of which must be met, for this situation to occur and bypass the sandbox restrictions. This miscompiled shape of load only occurs on 64-bit WebAssembly linear memories, or when Config::wasm_memory64 is enabled. 32-bit WebAssembly is not affected. Spectre mitigations or signals-based-traps must be disabled. When spectre mitigations are enabled then the offending shape of load is not generated. When signals-based-traps are disabled then spectre mitigations are also automatically disabled. The specific bug in Cranelift is a miscompile of a load of the shape load(iadd(base, ishl(index, amt))) where amt is a constant. The amt value is mask…&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. From 32.0.0 to before 36.0.7, 42.0.2, and 43.0.1, Wasmtime&amp;#39;s Cranelift compilation backend contains a bug on aarch64 when performing a certain shape of heap accesses which means that the wrong address is accessed. When combined with explicit bounds checks a guest WebAssembly module this can create a situation where there are two diverging computations for the same address: one for the address to bounds-check and one for the address to load. This difference in address being operated on means that a guest module can pass a bounds check but then load a different address. Combined together this enables an arbitrary read/write primitive for guest WebAssembly when accesssing host memory. This is a sandbox escape as guests are able to read/write arbitrary host memory. This vulnerability has a few ingredients, all of which must be met, for this situation to occur and bypass the sandbox restrictions. This miscompiled shape of load only occurs on 64-bit WebAssembly linear memories, or when Config::wasm_memory64 is enabled. 32-bit WebAssembly is not affected. Spectre mitigations or signals-based-traps must be disabled. When spectre mitigations are enabled then the offending shape of load is not generated. When signals-based-traps are disabled then spectre mitigations are also automatically disabled. The specific bug in Cranelift is a miscompile of a load of the shape load(iadd(base, ishl(index, amt))) where amt is a constant. The amt value is mask…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-34971</guid>
    </item>
  </channel>
</rss>
