<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-04T15:43:28.685386+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-30506</id>
    <title>EUVD-2026-30506</title>
    <updated>2026-10-04T15:43:28.688991+00:00</updated>
    <content>EUVD-2026-30506</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-30506"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2021-39219</id>
    <title>fkie_cve-2021-39219</title>
    <updated>2026-10-04T15:43:28.689022+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Wasmtime is an open source runtime for WebAssembly &amp; WASI. Wasmtime before version 0.30.0 is affected by a type confusion vulnerability. As a Rust library the `wasmtime` crate clearly marks which functions are safe and which are `unsafe`, guaranteeing that if consumers never use `unsafe` then it should not be possible to have memory unsafety issues in their embeddings of Wasmtime. An issue was discovered in the safe API of `Linker::func_*` APIs. These APIs were previously not sound when one `Engine` was used to create the `Linker` and then a different `Engine` was used to create a `Store` and then the `Linker` was used to instantiate a module into that `Store`. Cross-`Engine` usage of functions is not supported in Wasmtime and this can result in type confusion of function pointers, resulting in being able to safely call a function with the wrong type. Triggering this bug requires using at least two `Engine` values in an embedding and then additionally using two different values with a `Linker` (one at the creation time of the `Linker` and another when instantiating a module with the `Linker`). It's expected that usage of more-than-one `Engine` in an embedding is relatively rare since an `Engine` is intended to be a globally shared resource, so the expectation is that the impact of this issue is relatively small. The fix implemented is to change this behavior to `panic!()` in Rust instead of silently allowing it. Using different `Engine` instances with a `Linker` is a program…</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2021-39219"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-q879-9g95-56mx</id>
    <title>GHSA-q879-9g95-56mx — Wrong type for `Linker`-define functions when used across two `Engine`s</title>
    <updated>2026-10-04T15:43:28.689066+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> crates.io: wasmtime, PyPI: wasmtime</p>
<p>### Impact</p>
<p>As a Rust library the `wasmtime` crate clearly marks which functions are safe and which are `unsafe`, guaranteeing that if consumers never use `unsafe` then it should not be possible to have memory unsafety issues in their embeddings of Wasmtime. An issue was discovered in the safe API of `Linker::func_*` APIs. These APIs were previously not sound when one `Engine` was used to create the `Linker` and then a different `Engine` was used to create a `Store` and then the `Linker` was used to instantiate a module into that `Store`. Cross-`Engine` usage of functions is not supported in Wasmtime and this can result in type confusion of function pointers, resulting in being able to safely call a function with the wrong type.</p>
<p>Triggering this bug requires using at least two `Engine` values in an embedding and then additionally using two different values with a `Linker` (one at the creation time of the `Linker` and another when instantiating a module with the `Linker`).</p>
<p>It's expected that usage of more-than-one `Engine` in an embedding is relatively rare since an `Engine` is intended to be a globally shared resource, so the expectation is that the impact of this issue is relatively small.</p>
<p>The fix implemented is to change this behavior to `panic!()` in Rust instead of silently allowing it. Using different `Engine` instances with a `Linker` is a programmer bug that `wasmtime` catches at runtime.</p>
<p>### Patches</p>
<p>This bug has been patched and users should upgrade to Wasmtime v…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-q879-9g95-56mx"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/gsd-2021-39219</id>
    <title>gsd-2021-39219</title>
    <updated>2026-10-04T15:43:28.689110+00:00</updated>
    <content>gsd-2021-39219</content>
    <link href="https://cve.radiocsirt.org/vuln/gsd-2021-39219"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/pysec-2021-322</id>
    <title>PYSEC-2021-322</title>
    <updated>2026-10-04T15:43:28.689123+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: wasmtime</p>
<p>Wasmtime is an open source runtime for WebAssembly &amp; WASI. Wasmtime before version 0.30.0 is affected by a type confusion vulnerability. As a Rust library the `wasmtime` crate clearly marks which functions are safe and which are `unsafe`, guaranteeing that if consumers never use `unsafe` then it should not be possible to have memory unsafety issues in their embeddings of Wasmtime. An issue was discovered in the safe API of `Linker::func_*` APIs. These APIs were previously not sound when one `Engine` was used to create the `Linker` and then a different `Engine` was used to create a `Store` and then the `Linker` was used to instantiate a module into that `Store`. Cross-`Engine` usage of functions is not supported in Wasmtime and this can result in type confusion of function pointers, resulting in being able to safely call a function with the wrong type. Triggering this bug requires using at least two `Engine` values in an embedding and then additionally using two different values with a `Linker` (one at the creation time of the `Linker` and another when instantiating a module with the `Linker`). It's expected that usage of more-than-one `Engine` in an embedding is relatively rare since an `Engine` is intended to be a globally shared resource, so the expectation is that the impact of this issue is relatively small. The fix implemented is to change this behavior to `panic!()` in Rust instead of silently allowing it. Using different `Engine` instances with a `Linker` is a program…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/pysec-2021-322"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/rustsec-2021-0110</id>
    <title>RUSTSEC-2021-0110 — Multiple Vulnerabilities in Wasmtime</title>
    <updated>2026-10-04T15:43:28.689154+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> crates.io: wasmtime</p>
<p>* [Use after free passing `externref`s to Wasm in
  Wasmtime](https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-v4cp-h94r-m7xf)</p>
<p>* [Out-of-bounds read/write and invalid free with `externref`s and GC safepoints
  in
  Wasmtime](https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-4873-36h9-wv49)</p>
<p>* [Wrong type for `Linker`-define functions when used across two
  `Engine`s](https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-q879-9g95-56mx)</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/rustsec-2021-0110"/>
  </entry>
</feed>
