CVE-2026-54786 in Wasmtime
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.
Quick answer
Bytecode Alliance Wasmtime should be reviewed and updated if it matches the affected versions. The recommended fix is to apply the vendor-supported patched version or the mitigation steps below, then retest the public website with Fixnx.
Who is affected
Affected versions
- Wasmtime before 24.0.10
- Wasmtime 25.0.0 through versions before 36.0.11
- Wasmtime 37.0.0 through versions before 44.0.3
- Wasmtime 45.0.0 and 45.0.1
Fixed versions
- Wasmtime 24.0.10 or later on the 24 branch
- Wasmtime 36.0.11 or later on the 36 branch
- Wasmtime 44.0.3 or later on the 44 branch
- Wasmtime 45.0.2 or later
How to fix it
CVE-2026-54786 affects Wasmtime. The issue means sensitive data may be exposed to people who should not see it. Treat it as a priority if this software is reachable by users, admins, browsers, or the network. Update to Wasmtime 24.0.10 or later on the 24 branch, or follow the linked vendor advisory if your branch needs a backport.
- Inventory every Wasmtime install, package, server, browser, or managed device in use.
- Compare installed versions with the affected range: Wasmtime before 24.0.10; Wasmtime 25.0.0 through versions before 36.0.11; Wasmtime 37.0.0 through versions before 44.0.3; Wasmtime 45.0.0 and 45.0.1.
- Update to Wasmtime 24.0.10 or later on the 24 branch.
- If you cannot update today, restrict access to trusted users and trusted networks only.
- Review logs for crashes, failed requests, privilege changes, unusual data access, or exploit alerts.
- Rotate secrets, tokens, and passwords if exposure or abuse is suspected.
- Document the update and keep the advisory link with the change record.
Scan now. Google sign-in is only needed to unlock fix guidance.
Verify the fix
- Confirm the installed version matches the fixed guidance: Wasmtime 24.0.10 or later on the 24 branch; Wasmtime 36.0.11 or later on the 36 branch; Wasmtime 44.0.3 or later on the 44 branch; Wasmtime 45.0.2 or later.
- Confirm risky admin, API, browser, or network exposure is reduced.
- Retest the affected workflow after the update or mitigation.
- Review logs again after patching for repeated suspicious activity.
- Run a new Fixnx scan where the affected software is part of the public site.
Related categories
Trusted references
FAQ
What is affected by CVE-2026-54786?
Bytecode Alliance Wasmtime versions listed as affected should be reviewed: Wasmtime before 24.0.10, Wasmtime 25.0.0 through versions before 36.0.11, Wasmtime 37.0.0 through versions before 44.0.3, Wasmtime 45.0.0 and 45.0.1.
What should I fix first?
Start with internet-facing sites, admin panels, login flows, plugins, themes, modules, packages, and systems that process user-controlled input or sensitive data.
How do I confirm the fix worked?
Apply the patched version or mitigation, clear caches where relevant, retest the affected workflow, and run a new Fixnx scan to verify public website exposure signals.
How are Fixnx security risk categories chosen?
Fixnx keeps one canonical risk page and assigns only broad, relevant categories such as ecosystem, technology area, or vulnerability class.