<?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-07T20:56:28.671702+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/cve-2025-62711</id>
    <title>CVE-2025-62711 — Wasmtime vulnerable to segfault when using component resources</title>
    <updated>2026-10-07T20:56:28.673421+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> bytecodealliance wasmtime</p>
<p>Wasmtime is a runtime for WebAssembly. In versions from 38.0.0 to before 38.0.3, the implementation of component-model related host-to-wasm trampolines in Wasmtime contained a bug where it's possible to carefully craft a component, which when called in a specific way, would crash the host with a segfault or assert failure. Wasmtime 38.0.3 has been released and is patched to fix this issue. There are no workarounds.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2025-62711"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-4h67-722j-5pmc</id>
    <title>GHSA-4h67-722j-5pmc — Wasmtime vulnerable to segfault when using component resources</title>
    <updated>2026-10-07T20:56:28.673476+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> crates.io: wasmtime</p>
<p>### Impact</p>
<p>The implementation of component-model related host-to-wasm trampolines in Wasmtime contained a bug where it's possible to carefully craft a component, which when called in a specific way, would crash the host with a segfault or assert failure. This bug was introduced in the release of Wasmtime 38.0.0 and affects it subsequent patch releases of 38.0.1 and 38.0.2. No other versions of Wasmtime are affected.</p>
<p>In Wasmtime 38 the implementation of host-to-wasm trampolines was refactored to remove the old usage of `setjmp` and `longjmp` to unwind the stack. In this transition, however, trampolines for component-model intrinsics were accidentally not updated meaning that they didn't update runtime data structures as the other host-to-wasm trampolines did. If an error ocurred during execution of wasm it would then try to read this runtime data which isn't present, and processing it could then result in a crash. For example one piece of runtime data is where to jump to in the case of a trap, and this is intended to be updated by trampolines during their execution. In this situation the trampoline didn't do anything meaning that the value was left set to 0 meaning that execution would jump to the 0 address and deterministically crash the program with a segfault.</p>
<p>Component intrinsic host-to-wasm trampolines are not typically used in most situations. These only exist for carefully crafted components no toolchain would conventionally produce. For example if the `resource.rep…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-4h67-722j-5pmc"/>
  </entry>
</feed>
