Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🦀 crates.io
Not in CISA KEV

CVE-2026-54786 — wasmtime-wasi

Fix: bytecodealliance/wasmtime#13650

CVE-2026-54786 is a Uncontrolled Resource Consumption vulnerability in wasmtime-wasi. A fix is available for wasmtime-wasi — see the affected versions and patch details below.

Wasmtime: Leak in WASIp1 `fd_renumber` implementation

Also known asGHSA-3p27-qvp9-27qfRUSTSEC-2026-0182
Published
Updated
Affected
4 pkgs
Patched
4 / 4
Exploits
None indexed
Exploitation data as of Oct 9, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-54786.

EPSS Exploitation Probability

via FIRST.org ↗
0.4%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs29th percentile — riskier than 29% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

4 pkgs affected
🦀wasmtime-wasi🦀wasmtime-wasi🦀wasmtime-wasi🦀wasmtime-wasi

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.

Description

Wasmtime is a runtime for WebAssembly. All versions prior to 24.0.10; versions 25.0.0 through those before 36.0.11; versions 37.0.0 through those before 44.0.3; and versions 45.0.0 and 45.0.1 contain a native implementation of WASIp1 which suffers from a leak in the fd_renumber function where the file descriptor being renumbered to is not properly closed. Wasmtime's implementation erroneously only updated the table of descriptors for WASIp1 and didn't update the underlying table of descriptors used by the host. This behavior means that while fd_renumber works correctly from a guest's perspective it ends up leaking resources in the host that aren't cleaned up until the corresponding Store is destroyed. In a loop, guests can use fd_renumber to cause hosts to exhaust both resources and file descriptors. This bug only affects the native implementation of WASIp1, meaning that only runtimes which load core wasm modules and expose fd_renumber are affected. Runtimes are additionally only affected if they expose the ability to acquire a file descriptor, such as opening a file. For runtimes that deny access to files they are unaffected. This issue has been fixed in versions 24.0.10, 36.0.11, 44.0.3, and 45.0.2.

Affected Packages

4 total 4 fixed
EcosystemPackageVulnerable rangeFix
🦀crates.iowasmtime-wasiall versions24.0.10cargo update -p wasmtime-wasi --precise 24.0.10
🦀crates.iowasmtime-wasi≥ 45.0.0&&< 45.0.245.0.2cargo update -p wasmtime-wasi --precise 45.0.2
🦀crates.iowasmtime-wasi≥ 25.0.0&&< 36.0.1136.0.11cargo update -p wasmtime-wasi --precise 36.0.11
🦀crates.iowasmtime-wasi≥ 37.0.0&&< 44.0.344.0.3cargo update -p wasmtime-wasi --precise 44.0.3

Affected Products

1 product · 4 configurations
Application
wasmtimebytecodealliance
≥ 45.0.0 && < 45.0.2
range

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for wasmtime-wasi, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update wasmtime-wasi to 24.0.10 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-54786 is resolved across your whole dependency graph.

  3. Workarounds

    Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatLow

This flaw is rated as Low impact. Wasmtime's WASIp1 implementation can leak file descriptors when renumbering, allowing a malicious guest program to exhaust host resources and cause a Denial of Service. This issue primarily affects Red Hat products that utilize Wasmtime with WASIp1 enabled and allow guest programs to…

Workaround published by Red Hat
To mitigate this issue, configure Wasmtime environments to deny guest programs the ability to acquire file descriptors, such as preventing file system access. This restriction limits the attack surface by preventing the `fd_renumber` function from leaking host resources. Consult product-specific documentation for instructions on configuring Wasmtime security policies to restrict file access. If the Wasmtime service is reloaded or restarted, ensure the configuration changes persist.
Source: Red Hat security advisory for CVE-2026-54786 (CC BY 4.0)

Frequently Asked Questions

Wasmtime is a runtime for WebAssembly. All versions prior to 24.0.10; versions 25.0.0 through those before 36.0.11; versions 37.0.0 through those before 44.0.3; and versions 45.0.0 and 45.0.1 contain a native implementation of WASIp1 which suffers from a leak in the fd_renumber function where the file descriptor being renumbered to is not properly closed. Wasmtime's implementation erroneously only updated the table of descriptors for WASIp1 and didn't update the underlying table of descriptors used by the host. This behavior means that while fd_renumber works correctly from a guest's perspect
O3 Security · Impact-Aware SCA

Is CVE-2026-54786 in your dependencies?

Find it across crates.io, including transitive dependencies.

Scan my dependencies How O3 SCA works
CVE-2026-54786: wasmtime-wasi — Fixed in 24.0.10