Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
11 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-hmmr-87qq-258j For more information see the GitHub-hosted security advisory.
Recommended action: Upgrade to 50.0.1, 49.0.5 or 48.0.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Wasmtime's WASI filesystem implementation lets a guest with a read-only source file capability overwrite that file by hard-linking it into another preopen that allows file writes. An attacker who can run a WASI guest can bypass WasiCtxBuilder per-preopen FilePerms and modify host files that were exposed as FilePerms::READ. This attack is possible through the wasip1, wasip2, and wasip3 interfaces to the WASI filesystem. This attack is also possible through an indirection of renaming a hardlink into another preopen. Details WasiCtxBuilder::preopeneddir documents fileperms as the maximum permissions usable for files in that preopen. However, hard-link creation and renaming only checked directory mutation for permission, and not whether the file permissions matched. This makes an attack possible where: a read-only file target exists in a preopen with only FilePerms::READ a hardlink named alias, with destination to the target, is created in a preopen with FilePerms::READ |…
Recommended action: Upgrade to 46.0.1, 45.0.3, 36.0.12 or 24.0.11 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-m9f7-9w4p-gv38 For more information see the GitHub-hosted security advisory.
Recommended action: Upgrade to 49.0.3, 48.0.6 or 36.0.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-j366-h8gg-77pm For more information see the GitHub-hosted security advisory.
Recommended action: Upgrade to 49.0.2, 48.0.4 or 36.0.17 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-gqmc-89g8-p25r For more information see the GitHub-hosted security advisory.
Recommended action: Upgrade to 49.0.2, 48.0.4 or 36.0.17 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-96f6-r43r-8c24 For more information see the GitHub-hosted security advisory.
Recommended action: Upgrade to 49.0.2, 48.0.4 or 36.0.17 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-mr2v-56j5-cmfc For more information see the GitHub-hosted security advisory.
Recommended action: Upgrade to 49.0.2 or 48.0.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-j2g9-4prp-pf6h For more information see the GitHub-hosted security advisory.
Recommended action: Upgrade to 49.0.1, 48.0.3 or 36.0.16 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Wasmtime's native implementation of WASIp1 suffers from a leak in the fdrenumber function where the file descriptor being renumbered to is not properly closed. Wasmtime's implementation erroneously only updated the table of descriptors for WASIp1 and didn't update the underlying table of descriptors used by the host. This behavior means that while fdrenumber works correctly from a guest's perspective it ends up leaking resources in the host that aren't cleaned up until the corresponding Store is destroyed. This means that guests can, in a loop, use fdrenumber to cause hosts to exhaust resources or exhaust file descriptors. This bug only affects the native implementation of WASIp1. This means that only runtimes which load core wasm modules and expose fdrenumber are affected. Runtimes are additionally only affected if they expose the ability to acquire a file descriptor, such as opening a file. For runtimes that deny access to files they are unaffected. Patches Wasmtime 24.0.10,…
Recommended action: Upgrade to 45.0.2, 44.0.3, 36.0.11 or 24.0.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In wasmtime-wasi, when a filesystem preopen is given DirPerms::all() and FilePerms::READ without FilePerms::WRITE, this wasmtime-wasi enforced access control mechanism can be bypassed by using the wasip2 descriptor.open-at or wasip1 pathopen interfaces by opening a file with OpenFlags::TRUNCATE oflag only, for example: The root cause is that the clause that considered OpenFlags::TRUNCATE did not set openmode |= OpenMode::WRITE;, used later in that function for the access control check against FilePerms for whether opening that file is permitted. With the bug corrected, these calls to open-at and pathopen fail with error-code.not-permitted and ERRNOPERM respectively. The bug in crates/wasi/src/filesystem.rs, Dir::openat, lines 967–969: and the single line fix is: Only wasmtime-wasi embeddings that use a combination of DirPerms::MUTATE with FilePerms::READ are affected by this bug, e.g. those that use in the WasiCtxBuilder: In particular, the Wasmtime project's wasmtime-cli's…
Recommended action: Upgrade to 44.0.2, 36.0.10 or 24.0.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A bug in Wasmtime's implementation of the WASIp1 set of import functions can lead to a WebAssembly guest inducing a panic in the host (embedder). The specific bug is triggered by calling pathopen after calling fdrenumber with either: - two equal argument values - second argument being equal to a previously-closed file descriptor number value The corrupt state introduced in fdrenumber will lead to the subsequent opening of a file descriptor to panic. This panic cannot introduce memory unsafety or allow WebAssembly to break outside of its sandbox, however. There is no possible heap corruption or memory unsafety from this panic. This bug is in the implementation of Wasmtime's wasmtime-wasi crate which provides an implementation of WASIp1. The bug requires a specially crafted call to fdrenumber in addition to the ability to open a subsequent file descriptor. Opening a second file descriptor is only possible when a preopened directory was provided to the guest, and this is common…
Recommended action: Upgrade to 34.0.2, 33.0.2 or 24.0.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.