<?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://vulnerability.circl.lu</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:55:18 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-104855</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-104855</link>
      <description>&lt;p&gt;Wasmtime is a runtime for WebAssembly. From 46.0.0 until 46.0.2 and 47.0.3, fuel and epoch preemption checks inside bulk operations including memory.copy, table.grow, and array.copy can expose invalid intermediate state when an embedder mutates a Store in Store::epoch_deadline_callback or continues using a Store after cancellation or a trap. A cancelled non-nullable table growth can leave null elements, linear-memory growth during memory.copy can invalidate retained raw pointers, and callback-triggered garbage collection during array.copy can invalidate GC pointers, resulting in a crash, invalid memory access, or GC heap corruption. Embeddings whose callbacks only access the host data in Store&amp;lt;T&amp;gt;, and embeddings that discard a Store after timeout or epoch deadline, are not affected. This issue is fixed in versions 46.0.2 and 47.0.3.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Wasmtime is a runtime for WebAssembly. From 46.0.0 until 46.0.2 and 47.0.3, fuel and epoch preemption checks inside bulk operations including memory.copy, table.grow, and array.copy can expose invalid intermediate state when an embedder mutates a Store in Store::epoch_deadline_callback or continues using a Store after cancellation or a trap. A cancelled non-nullable table growth can leave null elements, linear-memory growth during memory.copy can invalidate retained raw pointers, and callback-triggered garbage collection during array.copy can invalidate GC pointers, resulting in a crash, invalid memory access, or GC heap corruption. Embeddings whose callbacks only access the host data in Store&amp;lt;T&amp;gt;, and embeddings that discard a Store after timeout or epoch deadline, are not affected. This issue is fixed in versions 46.0.2 and 47.0.3.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-104855</guid>
    </item>
    <item>
      <title>GHSA-2hw9-mc66-jc2q — Wasmtime: Preemption and traps during bulk operations enable breaking internal VM state</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-2hw9-mc66-jc2q</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 bulk-data-transfer WebAssembly instructions, such as `memory.copy`, contains a vulnerability when a preemption via epochs or fuel is combined with altering the store&amp;#39;s state or cancelling a computation. To prevent these operations from taking too long Wasmtime injects fuel/epoch checks during these operations, but this enables embedders, and possible WebAssembly, to witness intermediate state in the middle of the operation. Examples of this include:&lt;/p&gt;
&lt;p&gt;* When a non-nullable WebAssembly table is grown the new elements initially start as null and are filled in as part of a loop with preemption checks. If this computation is then cancelled this left the table in a grown-but-uninitialized state where subsequent usage via WebAssembly could possibly segfault. Loads from this table are assumed to not be null due to its type, but the runtime implementation was exposed through this cancellation at a preemption point.
* Embedders could mutate the store during an epoch callback, such as growing a WebAssembly linear memory. During a bulk `memory.copy` operation, however, the pointers being copied to/from weren&amp;#39;t recomputed between preemption points. This meant that if the linear memory moved its base address it could be possible to have a preemption, the embedder manually grows memory, and then on resumption the copy operation uses invalid pointers.
* Embedders could execute a GC during epoch callbacks. GC operations such as `array.copy`, like `mem…&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 bulk-data-transfer WebAssembly instructions, such as `memory.copy`, contains a vulnerability when a preemption via epochs or fuel is combined with altering the store&amp;#39;s state or cancelling a computation. To prevent these operations from taking too long Wasmtime injects fuel/epoch checks during these operations, but this enables embedders, and possible WebAssembly, to witness intermediate state in the middle of the operation. Examples of this include:&lt;/p&gt;
&lt;p&gt;* When a non-nullable WebAssembly table is grown the new elements initially start as null and are filled in as part of a loop with preemption checks. If this computation is then cancelled this left the table in a grown-but-uninitialized state where subsequent usage via WebAssembly could possibly segfault. Loads from this table are assumed to not be null due to its type, but the runtime implementation was exposed through this cancellation at a preemption point.
* Embedders could mutate the store during an epoch callback, such as growing a WebAssembly linear memory. During a bulk `memory.copy` operation, however, the pointers being copied to/from weren&amp;#39;t recomputed between preemption points. This meant that if the linear memory moved its base address it could be possible to have a preemption, the embedder manually grows memory, and then on resumption the copy operation uses invalid pointers.
* Embedders could execute a GC during epoch callbacks. GC operations such as `array.copy`, like `mem…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-2hw9-mc66-jc2q</guid>
    </item>
    <item>
      <title>RUSTSEC-2026-0223 — Preemption and traps during bulk operations enable breaking internal VM state</title>
      <link>https://vulnerability.circl.lu/vuln/rustsec-2026-0223</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-2hw9-mc66-jc2q
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-2hw9-mc66-jc2q
For more information see the GitHub-hosted security advisory.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/rustsec-2026-0223</guid>
    </item>
  </channel>
</rss>
