<?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>Wed, 07 Oct 2026 03:14:06 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-187611</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-187611</link>
      <description>EUVD-2026-187611</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-187611</guid>
    </item>
    <item>
      <title>fkie_cve-2023-41880</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2023-41880</link>
      <description>&lt;p&gt;Wasmtime is a standalone runtime for WebAssembly. Wasmtime versions from 10.0.0 to versions 10.02, 11.0.2, and 12.0.1 contain a miscompilation of the WebAssembly `i64x2.shr_s` instruction on x86_64 platforms when the shift amount is a constant value that is larger than 32. Only x86_64 is affected so all other targets are not affected by this. The miscompilation results in the instruction producing an incorrect result, namely the low 32-bits of the second lane of the vector are derived from the low 32-bits of the second lane of the input vector instead of the high 32-bits. The primary impact of this issue is that any WebAssembly program using the `i64x2.shr_s` with a constant shift amount larger than 32 may produce an incorrect result.&lt;/p&gt;
&lt;p&gt;This issue is not an escape from the WebAssembly sandbox. Execution of WebAssembly guest programs will still behave correctly with respect to memory sandboxing and isolation from the host. Wasmtime considers non-spec-compliant behavior as a security issue nonetheless.&lt;/p&gt;
&lt;p&gt;This issue was discovered through fuzzing of Wasmtime&amp;#39;s code generator Cranelift.&lt;/p&gt;
&lt;p&gt;Wasmtime versions 10.0.2, 11.0.2, and 12.0.2 are all patched to no longer have this miscompilation. This issue only affects x86_64 hosts and the only workaround is to either scan for this pattern in wasm modules which is nontrivial or to disable the SIMD proposal for WebAssembly. Users prior to 10.0.0 are unaffected by this vulnerability.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Wasmtime is a standalone runtime for WebAssembly. Wasmtime versions from 10.0.0 to versions 10.02, 11.0.2, and 12.0.1 contain a miscompilation of the WebAssembly `i64x2.shr_s` instruction on x86_64 platforms when the shift amount is a constant value that is larger than 32. Only x86_64 is affected so all other targets are not affected by this. The miscompilation results in the instruction producing an incorrect result, namely the low 32-bits of the second lane of the vector are derived from the low 32-bits of the second lane of the input vector instead of the high 32-bits. The primary impact of this issue is that any WebAssembly program using the `i64x2.shr_s` with a constant shift amount larger than 32 may produce an incorrect result.&lt;/p&gt;
&lt;p&gt;This issue is not an escape from the WebAssembly sandbox. Execution of WebAssembly guest programs will still behave correctly with respect to memory sandboxing and isolation from the host. Wasmtime considers non-spec-compliant behavior as a security issue nonetheless.&lt;/p&gt;
&lt;p&gt;This issue was discovered through fuzzing of Wasmtime&amp;#39;s code generator Cranelift.&lt;/p&gt;
&lt;p&gt;Wasmtime versions 10.0.2, 11.0.2, and 12.0.2 are all patched to no longer have this miscompilation. This issue only affects x86_64 hosts and the only workaround is to either scan for this pattern in wasm modules which is nontrivial or to disable the SIMD proposal for WebAssembly. Users prior to 10.0.0 are unaffected by this vulnerability.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2023-41880</guid>
    </item>
    <item>
      <title>GHSA-gw5p-q8mj-p7gh — Miscompilation of wasm `i64x2.shr_s` instruction with constant input on x86_64</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-gw5p-q8mj-p7gh</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 versions from 10.0.0 to 12.0.1 contain a miscompilation of the WebAssembly `i64x2.shr_s` instruction on x86_64 platforms when the shift amount is a constant value that is larger than 32. Only x86_64 is affected so all other targets are not affected by this. The miscompilation results in the instruction producing an incorrect result, namely the low 32-bits of the second lane of the vector are derived from the low 32-bits of the second lane of the input vector instead of the high 32-bits. The primary impact of this issue is that any WebAssembly program using the `i64x2.shr_s` with a constant shift amount larger than 32 may produce an incorrect result.&lt;/p&gt;
&lt;p&gt;This issue is not an escape from the WebAssembly sandbox. Execution of WebAssembly guest programs will still behave correctly with respect to memory sandboxing and isolation from the host. Wasmtime considers non-spec-compliant behavior as a security issue nonetheless.&lt;/p&gt;
&lt;p&gt;This issue was discovered through fuzzing of Wasmtime&amp;#39;s code generator Cranelift.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;Wasmtime versions 10.0.2, 11.0.2, and 12.0.2 are all patched to no longer have this miscompilation.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;This issue only affects x86_64 hosts and the only workaround is to either scan for this pattern in wasm modules which is nontrivial or to [disable the SIMD proposal for WebAssembly](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_simd). Users prior to 10.0.0 are unaffected by this vulnerability.&lt;/p&gt;
&lt;p&gt;### Reference…&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 versions from 10.0.0 to 12.0.1 contain a miscompilation of the WebAssembly `i64x2.shr_s` instruction on x86_64 platforms when the shift amount is a constant value that is larger than 32. Only x86_64 is affected so all other targets are not affected by this. The miscompilation results in the instruction producing an incorrect result, namely the low 32-bits of the second lane of the vector are derived from the low 32-bits of the second lane of the input vector instead of the high 32-bits. The primary impact of this issue is that any WebAssembly program using the `i64x2.shr_s` with a constant shift amount larger than 32 may produce an incorrect result.&lt;/p&gt;
&lt;p&gt;This issue is not an escape from the WebAssembly sandbox. Execution of WebAssembly guest programs will still behave correctly with respect to memory sandboxing and isolation from the host. Wasmtime considers non-spec-compliant behavior as a security issue nonetheless.&lt;/p&gt;
&lt;p&gt;This issue was discovered through fuzzing of Wasmtime&amp;#39;s code generator Cranelift.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;Wasmtime versions 10.0.2, 11.0.2, and 12.0.2 are all patched to no longer have this miscompilation.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;This issue only affects x86_64 hosts and the only workaround is to either scan for this pattern in wasm modules which is nontrivial or to [disable the SIMD proposal for WebAssembly](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_simd). Users prior to 10.0.0 are unaffected by this vulnerability.&lt;/p&gt;
&lt;p&gt;### Reference…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-gw5p-q8mj-p7gh</guid>
    </item>
    <item>
      <title>gsd-2023-41880</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2023-41880</link>
      <description>gsd-2023-41880</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2023-41880</guid>
    </item>
    <item>
      <title>RUSTSEC-2023-0091 — Miscompilation of wasm `i64x2.shr_s` instruction with constant input on x86\_64</title>
      <link>https://cve.radiocsirt.org/vuln/rustsec-2023-0091</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-gw5p-q8mj-p7gh.
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-gw5p-q8mj-p7gh.
For more information see the GitHub-hosted security advisory.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rustsec-2023-0091</guid>
    </item>
    <item>
      <title>Withdrawn: UBUNTU-CVE-2023-41880</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-41880</link>
      <description>&lt;p&gt;&lt;strong&gt;Withdrawn by the publisher.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:24.04:LTS: rust-wasmtime&lt;/p&gt;
&lt;p&gt;Wasmtime is a standalone runtime for WebAssembly. Wasmtime versions from 10.0.0 to versions 10.02, 11.0.2, and 12.0.1 contain a miscompilation of the WebAssembly `i64x2.shr_s` instruction on x86_64 platforms when the shift amount is a constant value that is larger than 32. Only x86_64 is affected so all other targets are not affected by this. The miscompilation results in the instruction producing an incorrect result, namely the low 32-bits of the second lane of the vector are derived from the low 32-bits of the second lane of the input vector instead of the high 32-bits. The primary impact of this issue is that any WebAssembly program using the `i64x2.shr_s` with a constant shift amount larger than 32 may produce an incorrect result. This issue is not an escape from the WebAssembly sandbox. Execution of WebAssembly guest programs will still behave correctly with respect to memory sandboxing and isolation from the host. Wasmtime considers non-spec-compliant behavior as a security issue nonetheless. This issue was discovered through fuzzing of Wasmtime&amp;#39;s code generator Cranelift. Wasmtime versions 10.0.2, 11.0.2, and 12.0.2 are all patched to no longer have this miscompilation. This issue only affects x86_64 hosts and the only workaround is to either scan for this pattern in wasm modules which is nontrivial or to disable the SIMD proposal for WebAssembly. Users prior to 10.0.0 are unaffected by this vulnerability.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Withdrawn by the publisher.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:24.04:LTS: rust-wasmtime&lt;/p&gt;
&lt;p&gt;Wasmtime is a standalone runtime for WebAssembly. Wasmtime versions from 10.0.0 to versions 10.02, 11.0.2, and 12.0.1 contain a miscompilation of the WebAssembly `i64x2.shr_s` instruction on x86_64 platforms when the shift amount is a constant value that is larger than 32. Only x86_64 is affected so all other targets are not affected by this. The miscompilation results in the instruction producing an incorrect result, namely the low 32-bits of the second lane of the vector are derived from the low 32-bits of the second lane of the input vector instead of the high 32-bits. The primary impact of this issue is that any WebAssembly program using the `i64x2.shr_s` with a constant shift amount larger than 32 may produce an incorrect result. This issue is not an escape from the WebAssembly sandbox. Execution of WebAssembly guest programs will still behave correctly with respect to memory sandboxing and isolation from the host. Wasmtime considers non-spec-compliant behavior as a security issue nonetheless. This issue was discovered through fuzzing of Wasmtime&amp;#39;s code generator Cranelift. Wasmtime versions 10.0.2, 11.0.2, and 12.0.2 are all patched to no longer have this miscompilation. This issue only affects x86_64 hosts and the only workaround is to either scan for this pattern in wasm modules which is nontrivial or to disable the SIMD proposal for WebAssembly. Users prior to 10.0.0 are unaffected by this vulnerability.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-41880</guid>
    </item>
  </channel>
</rss>
