<?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>Tue, 06 Oct 2026 14:42:29 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-61670 — Wasmtime has memory leak in C API with `externref` and `anyref` types</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2025-61670</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; bytecodealliance wasmtime&lt;/p&gt;
&lt;p&gt;Wasmtime is a runtime for WebAssembly. Wasmtime 37.0.0 and 37.0.1 have memory leaks in the C/C++ API when using bindings for the `anyref` or `externref` WebAssembly values. This is caused by a regression introduced during the development of 37.0.0 and all prior versions of Wasmtime are unaffected. If `anyref` or `externref` is not used in the C/C++ API then embeddings are also unaffected by the leaky behavior. The `wasmtime` Rust crate is unaffected by this leak.&lt;/p&gt;
&lt;p&gt;Development of Wasmtime 37.0.0 included a refactoring in Rust of changing the old `ManuallyRooted&amp;lt;T&amp;gt;` type to a new `OwnedRooted&amp;lt;T&amp;gt;` type. This change was integrated into Wasmtime&amp;#39;s C API but left the C API in a state which had memory leaks. Additionally the new ownership semantics around this type were not reflected into the C++ API, making it leak-prone. A short version of the change is that previously `ManuallyRooted&amp;lt;T&amp;gt;`, as the name implies, required manual calls to an &amp;#34;unroot&amp;#34; operation. If this was forgotten then the memory was still cleaned up when the `wasmtime_store_t` itself was destroyed eventually. Documentation of when to &amp;#34;unroot&amp;#34; was sparse and there were already situations prior to 37.0.0 where memory would be leaked until the store was destroyed anyway. All memory, though, was always bound by the store, and destroying the store would guarantee that there were no memory leaks.&lt;/p&gt;
&lt;p&gt;In migrating to `OwnedRooted&amp;lt;T&amp;gt;` the usage of the type in Rust changed. A manual &amp;#34;unroot&amp;#34; operation is no longer required an…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; bytecodealliance wasmtime&lt;/p&gt;
&lt;p&gt;Wasmtime is a runtime for WebAssembly. Wasmtime 37.0.0 and 37.0.1 have memory leaks in the C/C++ API when using bindings for the `anyref` or `externref` WebAssembly values. This is caused by a regression introduced during the development of 37.0.0 and all prior versions of Wasmtime are unaffected. If `anyref` or `externref` is not used in the C/C++ API then embeddings are also unaffected by the leaky behavior. The `wasmtime` Rust crate is unaffected by this leak.&lt;/p&gt;
&lt;p&gt;Development of Wasmtime 37.0.0 included a refactoring in Rust of changing the old `ManuallyRooted&amp;lt;T&amp;gt;` type to a new `OwnedRooted&amp;lt;T&amp;gt;` type. This change was integrated into Wasmtime&amp;#39;s C API but left the C API in a state which had memory leaks. Additionally the new ownership semantics around this type were not reflected into the C++ API, making it leak-prone. A short version of the change is that previously `ManuallyRooted&amp;lt;T&amp;gt;`, as the name implies, required manual calls to an &amp;#34;unroot&amp;#34; operation. If this was forgotten then the memory was still cleaned up when the `wasmtime_store_t` itself was destroyed eventually. Documentation of when to &amp;#34;unroot&amp;#34; was sparse and there were already situations prior to 37.0.0 where memory would be leaked until the store was destroyed anyway. All memory, though, was always bound by the store, and destroying the store would guarantee that there were no memory leaks.&lt;/p&gt;
&lt;p&gt;In migrating to `OwnedRooted&amp;lt;T&amp;gt;` the usage of the type in Rust changed. A manual &amp;#34;unroot&amp;#34; operation is no longer required an…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2025-61670</guid>
    </item>
    <item>
      <title>GHSA-vvp9-h8p2-xwfc — Wasmtime: Memory leak in C API with `externref` and `anyref` types</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-vvp9-h8p2-xwfc</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: wasmtime-c-api-impl, PyPI: wasmtime-bin&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Wasmtime 37.0.0 and 37.0.1 have memory leaks in the C/C++ API when using bindings for the `anyref` or `externref` WebAssembly values. This is caused by a regression introduced during the development of 37.0.0 and all prior versions of Wasmtime are unaffected. If `anyref` or `externref` is not used in the C/C++ API then embeddings are also unaffected by the leaky behavior. The `wasmtime` Rust crate is unaffected by this leak.&lt;/p&gt;
&lt;p&gt;Development of Wasmtime 37.0.0 included a refactoring in Rust of changing the old `ManuallyRooted&amp;lt;T&amp;gt;` type to a new `OwnedRooted&amp;lt;T&amp;gt;` type. This change was integrated into Wasmtime&amp;#39;s C API but left the C API in a state which had memory leaks. Additionally the new ownership semantics around this type were not reflected into the C++ API, making it leak-prone. A short version of the change is that previously `ManuallyRooted&amp;lt;T&amp;gt;`, as the name implies, required manual calls to an &amp;#34;unroot&amp;#34; operation. If this was forgotten then the memory was still cleaned up when the `wasmtime_store_t` itself was destroyed eventually. Documentation of when to &amp;#34;unroot&amp;#34; was sparse and there were already situations prior to 37.0.0 where memory would be leaked until the store was destroyed anyway. All memory, though, was always bound by the store, and destroying the store would guarantee that there were no memory leaks.&lt;/p&gt;
&lt;p&gt;In migrating to `OwnedRooted&amp;lt;T&amp;gt;` the usage of the type in Rust changed. A manual &amp;#34;unroot&amp;#34; operation is no longer required and it happens naturally as a…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: wasmtime-c-api-impl, PyPI: wasmtime-bin&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Wasmtime 37.0.0 and 37.0.1 have memory leaks in the C/C++ API when using bindings for the `anyref` or `externref` WebAssembly values. This is caused by a regression introduced during the development of 37.0.0 and all prior versions of Wasmtime are unaffected. If `anyref` or `externref` is not used in the C/C++ API then embeddings are also unaffected by the leaky behavior. The `wasmtime` Rust crate is unaffected by this leak.&lt;/p&gt;
&lt;p&gt;Development of Wasmtime 37.0.0 included a refactoring in Rust of changing the old `ManuallyRooted&amp;lt;T&amp;gt;` type to a new `OwnedRooted&amp;lt;T&amp;gt;` type. This change was integrated into Wasmtime&amp;#39;s C API but left the C API in a state which had memory leaks. Additionally the new ownership semantics around this type were not reflected into the C++ API, making it leak-prone. A short version of the change is that previously `ManuallyRooted&amp;lt;T&amp;gt;`, as the name implies, required manual calls to an &amp;#34;unroot&amp;#34; operation. If this was forgotten then the memory was still cleaned up when the `wasmtime_store_t` itself was destroyed eventually. Documentation of when to &amp;#34;unroot&amp;#34; was sparse and there were already situations prior to 37.0.0 where memory would be leaked until the store was destroyed anyway. All memory, though, was always bound by the store, and destroying the store would guarantee that there were no memory leaks.&lt;/p&gt;
&lt;p&gt;In migrating to `OwnedRooted&amp;lt;T&amp;gt;` the usage of the type in Rust changed. A manual &amp;#34;unroot&amp;#34; operation is no longer required and it happens naturally as a…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-vvp9-h8p2-xwfc</guid>
    </item>
  </channel>
</rss>
