Yagehu

Name of the Vulnerable Software and Affected Versions: WAMR versions up to and including 2.2.0 WAMR built with libc-uvwasi on Windows Description: The issue is related to a symlink following vulnerability in the WebAssembly Micro Runtime (WAMR). On WAMR running in Windows, creating a symlink pointing outside of the preopened directory and subsequently opening it with create flag will create a file on the host outside of the sandbox. If the symlink points to an existing host file, it's also possible to open it and read its content. Recommendations: For WAMR versions up to and including 2.2.0, update to version 2.3.0 to fix the issue. For WAMR built with libc-uvwasi on Windows, update to a version that does not use libc-uvwasi or apply a patch that fixes the symlink following vulnerability. As a temporary workaround, consider restricting the use of the `create` flag when opening files to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Wasmer versions prior to 4.3.2 **Description** The issue allows WASI programs to traverse a symlink and access the host filesystem if the caller sets both `oflags::creat` and `rights::fd write`. Programs can also crash the runtime by creating a symlink pointing outside with `path symlink` and `path open`ing the link. **Recommendations** For versions prior to 4.3.2, upgrade to release version 4.3.2 to address the issue. As a temporary workaround, consider restricting the use of `path symlink` and `path open` functions to minimize the risk of exploitation. Avoid using the `oflags::creat` and `rights::fd write` flags in the affected API endpoints until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Wasmer versions prior to 4.2.4 **Description** The issue affects Wasmer, a WebAssembly runtime, allowing Wasm programs to access the filesystem outside of the sandbox. This can lead to service providers running untrusted Wasm code on Wasmer unexpectedly exposing the host filesystem. **Recommendations** For versions prior to 4.2.4, update to version 4.2.4 to resolve the issue. As a temporary workaround, consider restricting access to untrusted Wasm code until the update is applied.