Cyber Resilience

CVE-2024-47763

Bytecodealliance Wasmtime 21.0.0 … 25.0.1

Published
09 October 2024
Modified
29 September 2025
Patch / advisory
CVSS Score v3.1 5.5
Click a component to see what it means
Raw vectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score 0.0024 15th percentile
Risk Priority 42 floored blend · peak EPSS

CVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.

Summary

CVE-2024-47763 is a medium-severity Always-Incorrect Control Flow Implementation (CWE-670) vulnerability in Bytecodealliance Wasmtime. Its CVSS base score is 5.5 (Medium).

Operationally, ranked at the 15th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.

The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-15 (Development Process, Standards, and Tools) — see the control section below for these in your framework.

EU & UK References

Vulnerability Data

Wasmtime is an open source runtime for WebAssembly. Wasmtime's implementation of WebAssembly tail calls combined with stack traces can result in a runtime crash in certain WebAssembly modules. The runtime crash may be undefined behavior if Wasmtime was compiled with…

more

Rust 1.80 or prior. The runtime crash is a deterministic process abort when Wasmtime is compiled with Rust 1.81 and later. WebAssembly tail calls are a proposal which relatively recently reached stage 4 in the standardization process. Wasmtime first enabled support for tail calls by default in Wasmtime 21.0.0, although that release contained a bug where it was only on-by-default for some configurations. In Wasmtime 22.0.0 tail calls were enabled by default for all configurations. The specific crash happens when an exported function in a WebAssembly module (or component) performs a `return_call` (or `return_call_indirect` or `return_call_ref`) to an imported host function which captures a stack trace (for example, the host function raises a trap). In this situation, the stack-walking code previously assumed there was always at least one WebAssembly frame on the stack but with tail calls that is no longer true. With the tail-call proposal it's possible to have an entry trampoline appear as if it directly called the exit trampoline. This situation triggers an internal assert in the stack-walking code which raises a Rust `panic!()`. When Wasmtime is compiled with Rust versions 1.80 and prior this means that an `extern "C"` function in Rust is raising a `panic!()`. This is technically undefined behavior and typically manifests as a process abort when the unwinder fails to unwind Cranelift-generated frames. When Wasmtime is compiled with Rust versions 1.81 and later this panic becomes a deterministic process abort. Overall the impact of this issue is that this is a denial-of-service vector where a malicious WebAssembly module or component can cause the host to crash. There is no other impact at this time other than availability of a service as the result of the crash is always a crash and no more. This issue was discovered by routine fuzzing performed by the Wasmtime project via Google's OSS-Fuzz infrastructure. We have no evidence that it has ever been exploited by an attacker in the wild. All versions of Wasmtime which have tail calls enabled by default have been patched: * 21.0.x - patched in 21.0.2 * 22.0.x - patched in 22.0.1 * 23.0.x - patched in 23.0.3 * 24.0.x - patched in 24.0.1 * 25.0.x - patched in 25.0.2. Wasmtime versions from 12.0.x (the first release with experimental tail call support) to 20.0.x (the last release with tail-calls off-by-default) have support for tail calls but the support is disabled by default. These versions are not affected in their default configurations, but users who explicitly enabled tail call support will need to either disable tail call support or upgrade to a patched version of Wasmtime. The main workaround for this issue is to disable tail support for tail calls in Wasmtime, for example with `Config::wasm_tail_call(false)`. Users are otherwise encouraged to upgrade to patched versions.

CWE(s)

Related Threats

CVEs Like This One

CVE-2026-34946Same product: Bytecodealliance Wasmtime
CVE-2024-47813Same product: Bytecodealliance Wasmtime
CVE-2023-30624Same product: Bytecodealliance Wasmtime
CVE-2025-62711Same product: Bytecodealliance Wasmtime
CVE-2026-34988Same product: Bytecodealliance Wasmtime
CVE-2026-47261Same product: Bytecodealliance Wasmtime
CVE-2025-53901Same product: Bytecodealliance Wasmtime
CVE-2026-27572Same product: Bytecodealliance Wasmtime
CVE-2026-24116Same product: Bytecodealliance Wasmtime
CVE-2026-34987Same product: Bytecodealliance Wasmtime

Affected Assets

bytecodealliance
wasmtime
21.0.0, 21.0.1, 22.0.0, 23.0.0, 23.0.1

Mitigating Controls

Control response

Prevent
Stop it (NIST 800-53)

—

Detect
Catch it (NIST detect / respond)

—

Harden
Shrink the surface (DISA STIG)

—

Validate
Prove the fix (OWASP ASVS)
  • V9.2.1

Mitigating Controls (NIST 800-53 r5) AI

Developer testing and evaluation at post-design stages directly exercises control-flow paths and reveals mismatches between implemented and intended behavior.

Requiring a documented development process and supporting tools reduces the chance that incorrect control-flow logic is introduced in the first place.

Flaw identification and remediation processes can locate and correct control-flow errors once they manifest as incorrect runtime behavior.

Mitigating Controls (NIST CSF 2.0) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.

PR.PS-06 mostly match
prevents

Secure SDLC practices directly prevent incorrect control-flow implementations via reviews, testing, and static analysis.

Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.

finds

Security testing in development and acceptance can detect paths that deviate from intended logic.

prevents

Secure development lifecycle processes can catch incorrect control-flow logic during design and code review.

prevents

Secure coding standards and reviews directly target flawed control-flow implementations.

prevents

Change-management gates may prevent deployment of flawed logic but do not address the coding defect itself.

References