Wasmtime fixes two serious crashes in Cranelift (CVE-2026-115889, CVE-2026-115893)

In recent weeks, two serious failures were corrected in Wasmtime, the WebAssembly running environment that is integrated into programs outside the browser. The maintainers rated each vulnerability with 9.9 / 10 on the CVSS scale and published patches between 19 and 20 October. The errors allow, under certain conditions, a malicious WebAssembly module to escape from the sandbox that should limit it and run code outside your authorized area. According to official notes, there are no public reports of active exploitation until the cut-off date indicated in the notices.

What is confirmed: the two failures are implementational in Cranelift, the default compiler Wasmtime uses to convert Wasm into machine code. They are registered as CVE-2026-115889 (affects all architectures) and CVE-2026-115893 (affects only ARM64 / aarch64). The maintainers published corrected versions (e.g., Wasmtime 50.0.0 and point patches on supported lines) that eliminate vulnerable conditions. In addition, both entries are listed in the RustSec vulnerability base under the above-mentioned identifiers, and the catalogue of exploited vulnerabilities known to CISA did not include these CVE as at 26 October.

How the faults work technically (verifiable technical summary): CVE-2026-115889 comes from how Cranelift internally encoded numbers used to identify values within a function: originally those identifiers were adjusted in 24-bit fields and, in launch compilations, an identifier that exceeded that space was undetected, which could cause the compiler to refer to the wrong value and generate wrong code. This behavior allows to build extremely large Wasm functions or designed to consume many identifiers and force a type confusion that could break the sandbox guarantees. CVE-2026-115893 explores Wasm's br _ table instruction: in ARM64, Cranelift generated a "long range" branch towards the default jump input that could only reach a limited range (h1 MiB). When a table of jumps had too many inputs (more than ~ 256,000), the branch exceeded the range and quietly pointed to a wrong direction, allowing the controlled module to jump into arbitrary code in processes with the default configuration in ARM64. The correction changes the generation so that the out-of-range indices are passed through the table itself rather than using a long-range branch and adds a rejection threshold for excessively large tables (br _ table with more than 65,520 destinations are denied).

Who is most at risk - facts and estimates: The real risk is confirmed by the possibility that a third party will upload or deliver a Wasm module that the host will compete with a vulnerable version of Wasmtime. Therefore, the services that accept and compile external user code - for example, edge computing platforms or "serverless" that run WebAssembly - are the most exposed. This is consistent with public examples: suppliers like Fastly have documented the use of Wasmtime on platforms that run customer code, which illustrates the threat model even though official notices do not list affected services or claim known incidents. It is a reasonable estimate (but not a confirmation) that environments that do not compile third-party modules or only run signed / certified modules are at much lower risk.

Scope of versions and support - key facts for mitigation: Wasmtime maintains lines with different support: LTS (multiple of 12) receive support for two years; other lines only two months. The maintainers indicated that only lines 36, 48, 49 and 50 were supported at the time of the notice; many old branches, including LTS 24.x whose support ended on 20 August 2026, were not corrected. The versions according to each line are: update to 36.0.19, 48.0.7, 49.0.4 or Wasmtime 50.0.0 (the latter fixes both faults). Important: Wasmtime is usually embedded as a library: updating only the command line tool does not mitigate embossed dependencies; each product including Wasmtime must be reconstructed by linking the secure version.

Specific and prioritized actions that you should take now: 1) Inventory uses: identify all binaries, containers and packages that include Wasmtime in your environment and determine the version line (e.g. 36.x, 48.x, 49.x, 50.x or unsupported lines). 2) Update and remodel: for supported environments, update to the corrected versions indicated above; for products that embody Wasmtime as bookstore, reconstruct these programs with the secure version; for unsupported lines, migrate to a supported line and apply the patch. 3) Analyze the exposure: if your service compiles user modules, treat these entry points as a top priority for parking and deployment. 4) Detecting dependencies: run tools like cargo-audit to detect RUSTSEC inputs (associated IDs are listed in RustSec); this helps to find Wasmtime affected in dependency chains. 5) Compensatory controls if you cannot park immediately: it restricts the possibility for third parties to upload or compile modules (e.g., disable the JIT compilation of unverified modules, implement the rejection of loads, require the signature of modules or isolate the compilation within additional OS sandboxes as containers with seccomp / SELinux policies). 6) Record and monitor: Enable detailed execution logs and monitor atypical behaviors (unusual jumps, out-of-memory execution assigned) and monitor public alerts and inputs on bases such as GitHub Advisory Database, RustSec and CISA.

The following is not clear or confirmed: The notices do not specify what specific resources an attacker could obtain after escaping the sandbox or list affected suppliers; nor do they specify precisely when the team recognized the safety impact for the first vulnerability (technical correction - extending fields to 32 bits - was introduced previously for capacity reasons). There are also no verified public operating data in active campaigns at the close of the notices. In ARM64, the second failure has existed since Wasmtime supported that architecture (2020), but there is no public evidence of massive abuse of it.

For corrections and download published versions, see the project launches page: Wasmtime v50.0.0, and check security tickets to RustSec: RUSTSEC-2026-0380 and RUSTSEC-2026-0379. For context on the list of exploited vulnerabilities and their monitoring by critical infrastructure, see the CISA catalogue: CISA KEV catalog.

In short: treat these corrections as a high priority if your infrastructure compiles or runs Wasm modules of unreliable origin; patching and reconstructing libraries is the safe and direct measure. If you cannot do so immediately, reduce exposure by restricting the intake and compilation of modules and apply additional controls at container level and authentication of modules until the final solution is deployed.