1# What is considered a security vulnerability? 2 3**If you are still unsure whether an issue you are filing is a security 4vulnerability or not after reading this page, always err on the side of caution 5and report it as a security vulnerability!** 6 7Bugs must affect [a tier 1 platform or feature](./stability-tiers.md) to be 8considered a security vulnerability. 9 10The security of the host and integrity of the sandbox when executing Wasm is 11paramount. Anything that undermines the Wasm execution sandbox is a security 12vulnerability. 13 14On the other hand, execution that diverges from Wasm semantics (such as 15computing incorrect values) are not considered security vulnerabilities so long 16as they remain confined within the sandbox. This has a couple repercussions that 17are worth highlighting: 18 19* Even though it is safe from the *host's* point of view, an incorrectly 20 computed value could lead to classic memory unsafety bugs from the *Wasm 21 guest's* point of view, such as corruption of its `malloc`'s free list or 22 reading past the end of a source-level array. 23 24* Wasmtime embedders should never blindly trust values from the guest — no 25 matter how trusted the guest program is, even if it was written by the 26 embedders themselves — and should always validate these values before 27 performing unsafe operations on behalf of the guest. 28 29Denials of service when *executing* Wasm (either originating inside compiled 30Wasm code or Wasmtime's runtime subroutines) are considered security 31vulnerabilities. For example, if you configure Wasmtime to run Wasm guests with 32the async 33[fuel](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.consume_fuel) 34mechanism, and then executing the Wasm goes into an infinite loop that never 35yields, that is considered a security vulnerability. 36 37Denials of service when *compiling* Wasm, however, are not considered security 38vulnerabilities. For example, an infinite loop during register allocation is not 39a security vulnerability. 40 41Any kind of memory unsafety (e.g. use-after-free bugs, out-of-bounds memory 42accesses, etc...) in the host is always a security vulnerability. 43 44### Cheat Sheet: Is this bug considered a security vulnerability? 45 46| Type of bug | At Wasm Compile Time | At Wasm Execution Time | 47|-------------------------------------------------------------------------------------|-----|-----| 48| Sandbox escape | - | Yes | 49| <ul>Uncaught out-of-bounds memory access | - | Yes | 50| <ul>Uncaught out-of-bounds table access | - | Yes | 51| <ul>Failure to uphold Wasm's control-flow integrity | - | Yes | 52| <ul>File system access outside of the WASI file system's mapped directories | - | Yes | 53| <ul>Use of a WASI resource without having been given the associated WASI capability | - | Yes | 54| <ul>Etc... | - | Yes | 55| Divergence from Wasm semantics (without escaping the sandbox) | - | No | 56| <ul>Computing incorrect value | - | No | 57| <ul>Raising errant trap | - | No | 58| <ul>Etc... | - | No | 59| Memory unsafety | Yes | Yes | 60| <ul>Use-after-free | Yes | Yes | 61| <ul>Out-of-bounds memory access | Yes | Yes | 62| <ul>Use of uninitialized memory | Yes | Yes | 63| <ul>Etc... | Yes | Yes | 64| Denial of service | No | Yes | 65| <ul>Panic | No | Yes | 66| <ul>Process abort | No | Yes | 67| <ul>Uninterruptible infinite loops | No | Yes | 68| <ul>User-controlled memory exhaustion | No | Yes | 69| <ul>Uncontrolled recursion over user-supplied input | No | Yes | 70| <ul>Etc... | No | Yes | 71 72Note that we still want to fix every bug mentioned above even if it is not a 73security vulnerability! We appreciate when issues are filed for 74non-vulnerability bugs, particularly when they come with test cases and steps to 75reproduce! 76 77Backports for non-security related fixes is [documented 78here](./contributing-release-process.html#releasing-a-patch-version). 79