Wasmtime 49.0.2 and 48.0.4 Fix Eight Advisories, Led by a Critical Stack Overflow in Async Component Callbacks
The Bytecode Alliance patched eight Wasmtime advisories on October 2, including a critical 9.3 CVSS stack buffer overflow that lets a guest write about 16KB to the host's native stack.
Editor's Note ·
- Correction:
- The section heading reads "A second release in nine days". The cited release notes date Wasmtime 49.0.1 to 2026-09-24 and 49.0.2 to 2026-10-02, an interval of eight days.
Overview
The Wasmtime WebAssembly runtime shipped patch releases on October 2, 2026 that together fix eight security advisories. According to the Wasmtime 49.0.2 release notes, the release is dated 2026-10-02, and the 48.0.5 release notes list the same eight advisories under 48.0.4, which was released the same day. The most serious is rated Critical.
What We Know
The critical flaw: async component callbacks
The GHSA-32h6-97mm-8q3c advisory is titled “Wasmtime component async-lifted callback result count is unvalidated, causing a native stack buffer overflow”. It carries a Critical rating with a CVSS score of 9.3, and the advisory lists no CVE identifier. Per the same advisory, affected versions are 39.0.0 up to but excluding 48.0.4, and 49.0.0 up to but excluding 49.0.2; the patched versions are 48.0.4 and 49.0.2.
The advisory says a guest can “write up to ~16KB of arbitrary data of its choosing to the process’s native stack”. Because that data can overwrite return addresses, it says embedders should treat the bug “as if it’s a arbitrary code execution sandbox escape vulnerability”, while noting that address space layout randomization and a non-executable stack can thwart simple attempts.
The root cause, as described in the advisory, was in wasmparser v0.259.0 and earlier. The validation of async callback function signatures should have required three i32 parameters and a single i32 result, but a typographic error meant the check accepted either three i32 parameters or a single i32 parameter without checking the result types at all. Wasmtime then trusted that validation and neither bounds-checked the trampoline’s parameter array nor allocated a return area matching the real signature. The advisory credits smaeljaish771 as reporter and KeenSecurityLab as sponsor.
A workaround is to disable the component-model-async feature, according to the advisory, or to validate components with wasmparser v1.260.0 or later before passing them to Wasmtime.
Fuel metering bypass
The GHSA-j366-h8gg-77pm advisory, rated Moderate with a CVSS score of 4.0, covers a WASI preview 0 implementation of poll_oneoff that “circumvents fuel consumption”. It says a guest can run long computations that ignore fuel limits, and that systems using the wasmtime CLI are affected because WASI preview 0 is enabled by default. It is the only one of the four advisories examined here that also received a patch on the 36.x line, 36.0.17. The advisory gives -Spreview0=n as a CLI workaround.
Garbage-collector heap corruption
Two more advisories concern the GC heap. The GHSA-hw8m-q44c-ggrf advisory (Moderate, 5.7) describes a GC reference that may not be properly rooted across a try_call, and states that “Both GC and exceptions are on-by-default in Wasmtime v47 and above.” The GHSA-cfhf-m2cr-62wj advisory (Moderate, 5.9) covers mis-typed WebAssembly tag imports. It notes that Wasmtime’s GC heap “is implemented to be resilient to corruption but this is nevertheless a bug to fix”, and says there is no known workaround other than upgrading or disabling the WebAssembly exceptions proposal.
The rest of the batch
The 49.0.2 release notes name the remaining four fixes: excessive host memory allocation when guests have no stdio, fd_readdir copying uninitialized struct padding into guest memory, a guest able to panic the host through a filesystem timestamp before the epoch on wasip3, and a wasi:http panic when a zero timeout is supplied.
A second release in nine days
The October 2 patches follow Wasmtime 49.0.1, released 2026-09-24, which fixed four other advisories covering fuel-spend accounting for call_ref callees and dynamic record lifting, host memory exhaustion on outgoing HTTP body writes, and a panic on out-of-range datetimes in WASI filesystem set-times. Earlier this year, The Machine Herald reported on a larger Wasmtime security patch.
What We Don’t Know
- None of the four advisories examined for this report lists a CVE identifier; each says “No known CVE”.
- The advisories do not state whether any of the flaws has been exploited in the wild.
- The 48.0.5 release notes say artifacts for 48.0.4 did not get correctly published from CI and that no GitHub release was made for it, so users on the 48.x line should take 48.0.5 rather than 48.0.4.
Practical Takeaway
Embedders running Wasmtime 39 or later with component-model async enabled fall inside the critical advisory’s affected range; the advisory lists 48.0.4 and 49.0.2 as the patched versions.