Wasmtime

Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability Separately, for a merged upstream patch : up to $5,000 Google Patch Rewards pays for a patch you get accepted upstream and that stays merged, without reverts, for one month, not for the report. Wasmtime sits at Tier 2, where the panel grades a merged patch from $100 for a one-liner up to $5,000 for a complicated, high-impact improvement, entirely at its discretion, and no memory-safety multiplier applies at this tier. Privilege separation and sandboxing work and unsafe-block reduction in Rust crates are both named qualifying categories. Patches must be at least one month and no more than twelve months old, maintainers hold a veto, and sanctions and territory exclusions apply. CVE history 23 Last 12 months 44 Lifetime Code execution 38 % Memory safety 28 % Parsing/validation 19 % Info disclosure 10 % Latest advisories Loading the feed Overview Wasmtime is the Bytecode Alliance's WebAssembly runtime and the one most often embedded when a platform has to execute code it does not trust: edge and serverless platforms, plugin systems inside larger applications, and a growing amount of multi-tenant infrastructure that treats a Wasm module as the isolation unit. The security boundary is the product here. A guest that gets out of it lands in a host process running other tenants' work. The bug profile follows: 38% code execution and sandbox escape, 28% memory safety in the runtime's unsafe boundaries. The Bytecode Alliance runs no bounty and Wasmtime's security policy carries no reward language, so sorona.xyz pays you directly on qualified, reproduced findings. In scope Escape from a guest WebAssembly module into host memory or host capability, which is the boundary the entire runtime exists to enforce The Cranelift code generator, where a miscompilation emits host machine code that violates an invariant the Wasm semantics guarantee The module decoder and validator, where a malformed or adversarially constructed binary reaches the compiler in a state it did not expect The WASI host implementations, which are the syscall-shaped surface between a guest and the operating system and the place a capability leaks in practice Memory-safety defects in the runtime's own Rust code and in the unsafe blocks at the host boundary, which account for 28% of this project's recorded history Privilege separation, sandboxing and unsafe-block reduction work across the above, all named categories in the Patch Rewards qualifying-submission list Out of scope Wasmer, WasmEdge and other WebAssembly runtimes, which are separate projects with their own repositories and their own pathways Embedder mistakes: a host that deliberately handed the guest a capability, or wired a host function that does no validation of its own Anything outside the repository the OSS-Fuzz integration names as main_repo , since the Tier 2 scope line attaches to that repository and nothing else One-line fixes for non-exploitable crashes, which the Patch Rewards rules exclude by name along with resource-exhaustion denial of service A patch the maintainers decline, since the reward panel states it will not second-guess a maintainer's decision Most-valued findings A guest-to-host sandbox escape reaching arbitrary code execution in the embedder's process. It is the highest-consequence outcome here, the largest class at 38%, and the one that turns a multi-tenant platform into a cross-tenant compromise A Cranelift miscompilation that produces host code violating a Wasm invariant, because it defeats the isolation without ever touching a runtime check Memory-safety defects at the host boundary and in unsafe blocks, at 28% a large share of the history despite the runtime being written in Rust A structural hardening of the validator or the compiler's invariant checking that closes a family of malformed-module cases rather than one, which is what the reward panel grades at the top of its ladder Capability leaks in the WASI implementations, where a guest reaches a file, socket or environment value the embedder never granted it Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Report through the Bytecode Alliance process named in the repository's SECURITY.md, which is a real channel and pays nothing for the report itself Send a detailed, reproducible report with the module, ideally a minimised .wat or .wasm , and the embedder configuration it was run under; if we can't reproduce it, it isn't eligible Show the escape from inside the guest, against a default embedding, rather than from a host that already handed the guest the capability If you also want the Google patch money, land the fix upstream yourself and keep it merged without reverts for a month. That is a separate pathway with its own rules The Patch Rewards side is rate-limited to three submissions per person per month, requires patches at least one month and no more than twelve months old, and excludes researchers in sanctioned territories Disclosure Coordinated with the Bytecode Alliance security process, which runs an embargo with its downstream embedders before publishing a GitHub Security Advisory and RustSec entry with researcher credit. Hold the detail until that advisory is out, since the embedders shipping this runtime need the window more than most. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability