Two critical vulnerabilities have been disclosed in Wasmtime, an open-source WebAssembly runtime that developers can embed into applications and services. According to the project's maintainers, the flaws could allow a malicious WebAssembly module to break out of the sandbox designed to isolate untrusted code.

The issue is not a general browser-side WebAssembly problem. It affects software that uses vulnerable Wasmtime builds to compile attacker-controlled modules. One of the flaws impacts ARM64 systems only, which is relevant for organisations running workloads on ARM-based cloud infrastructure or newer server environments.

What happened

Wasmtime maintainers said two critical flaws could enable sandbox escape from malicious WebAssembly modules under specific conditions. To exploit the issue, an attacker would need software that uses a vulnerable Wasmtime build and allows compilation of a WebAssembly module they control.

Fixed versions have been released. The disclosure indicates that exploitability depends on how Wasmtime is integrated into a product or service, rather than affecting every organisation that uses WebAssembly in general.

Why it matters for European businesses

For many businesses, WebAssembly is not a consumer-facing technology but a component inside developer tools, edge platforms, automation products, SaaS infrastructure and internal execution environments. If a company runs untrusted or customer-supplied code through Wasmtime, a sandbox escape risk can become a serious isolation and infrastructure security issue.

This matters in several practical ways:

• Software supply chain exposure: Companies may be affected indirectly if a vendor embeds Wasmtime in a product or platform.
• Multi-tenant risk: Service providers using WebAssembly to isolate customer workloads may need urgent patching and review.
• Cloud and ARM adoption: The ARM64-specific flaw is relevant for teams using ARM-based servers or cloud instances to reduce infrastructure costs.
• Internal developer platforms: Businesses building plugin systems, workflow engines or secure code execution features around WebAssembly should verify whether Wasmtime is part of the stack.

For European companies in regulated sectors, a sandbox escape affecting hosted services or internal execution systems could also trigger wider security and incident-management obligations, depending on the nature of the environment and any resulting data or system exposure.

Who may be affected

• Software vendors embedding Wasmtime into commercial products
• SaaS providers running customer-supplied or third-party WebAssembly modules
• Cloud, edge and infrastructure teams using WebAssembly for workload isolation
• IT and platform engineering teams operating internal automation or plugin systems based on Wasmtime
• Businesses on ARM64 environments where the ARM-specific flaw may apply

Companies that do not use Wasmtime directly may still be exposed through third-party software. That makes vendor checks important, especially where WebAssembly is used behind the scenes and is not obvious from standard asset inventories.

What companies should consider

• Identify usage: Check whether your applications, developer platforms, SaaS tools or infrastructure components embed Wasmtime.
• Patch promptly: If Wasmtime is in use, review the maintainer advisory and move to the fixed versions released by the project.
• Review trust boundaries: Prioritise systems that compile or execute untrusted, customer-supplied or third-party WebAssembly modules.
• Assess ARM64 exposure: Determine whether affected workloads run on ARM-based cloud or server infrastructure.
• Ask vendors for confirmation: Request status updates from suppliers whose products rely on embedded WebAssembly runtimes.
• Validate monitoring and containment: Review logging, workload isolation and incident response controls for environments designed to sandbox untrusted code.

For SMEs, the immediate priority is not to treat this as a broad internet-wide WebAssembly panic, but as a dependency and platform security question. If your business or suppliers use Wasmtime to run untrusted modules, applying the fixed versions and checking isolation assumptions should be treated as a high-priority security task.