---
id: "CVE-2026-58494"
kind: "vulnerability"
aliases: ["CVE-2026-58494", "GHSA-4ch3-9j33-3pmj"]
title: "Wasmtime: WASI hard links bypass wasmtime-wasi's FilePerms for destination"
severity: "medium"
cvss: 6.5
epss: 0.0017099999822676182
exploited: false
status: "open"
category: "package"
products: [{"name": "wasmtime-wasi", "fixed": ["24.0.11"], "affected": "< 24.0.11", "ecosystem": "cargo"}, {"name": "wasmtime-wasi", "fixed": ["36.0.12"], "affected": ">= 25.0.0, < 36.0.12", "ecosystem": "cargo"}, {"name": "wasmtime-wasi", "fixed": ["45.0.3"], "affected": ">= 37.0.0, < 45.0.3", "ecosystem": "cargo"}, {"name": "wasmtime-wasi", "fixed": ["46.0.1"], "affected": ">= 46.0.0, < 46.0.1", "ecosystem": "cargo"}]
ecosystems: ["cargo"]
tags: ["cwe-281", "cwe-863", "embedders", "package", "rust", "wasi", "wasmtime"]
not_affected_if: ["no-dirperms-mutate", "no-fileperms-read-only-preopen", "single-preopen-config", "wasmtime-cli-only"]
published_at: "2026-07-08T21:16:54+00:00"
first_seen_at: "2026-10-23T19:11:32+00:00"
updated_at: "2026-10-23T23:44:52+00:00"
sources: [{"source": "ghsa", "url": "https://github.com/advisories/GHSA-4ch3-9j33-3pmj", "first_seen_at": "2026-10-23T19:11:32+00:00"}, {"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58494", "first_seen_at": "2026-10-23T23:44:52+00:00"}]
---

# Wasmtime: WASI hard links bypass wasmtime-wasi's FilePerms for destination

Wasmtime's wasmtime-wasi lets a WASI guest create a hard link to a read-only file in a preopen that allows writes, then write through that link to overwrite the host file. An attacker who controls a WASI guest can modify host files that were exposed as FilePerms::READ.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- cargo:wasmtime-wasi affected < 24.0.11 fixed 24.0.11
- cargo:wasmtime-wasi affected >= 25.0.0, < 36.0.12 fixed 36.0.12
- cargo:wasmtime-wasi affected >= 37.0.0, < 45.0.3 fixed 45.0.3
- cargo:wasmtime-wasi affected >= 46.0.0, < 46.0.1 fixed 46.0.1

## How to check

Search embedding code for WasiCtxBuilder::preopened_dir calls that combine DirPerms::MUTATE with FilePerms::READ on one preopen and FilePerms::READ | FilePerms::WRITE on another.
Check the wasmtime-wasi version in Cargo.lock against the affected ranges.
wasmtime-cli is not affected because it always sets FilePerms::all().

## Fix

Upgrade wasmtime-wasi to 24.0.11, 36.0.12, 45.0.3, or 46.0.1 depending on your release line.
If you cannot upgrade, do not give a guest a read-only file preopen alongside a writable preopen that shares the same mutable directory setup.

## Timeline

- 2026-10-23T19:11:32+00:00 ghsa https://github.com/advisories/GHSA-4ch3-9j33-3pmj
- 2026-10-23T23:44:52+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-58494

## From the sources

## Summary

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::preopened_dir` documents `file_perms` 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 | FilePerms::WRITE
* the attacker opens the file `alias` for writing, in which they can overwrite `target`

The same attack is possible by way of renaming:
* 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 that same preopen
* the `alias` file is renamed into a preopen with FilePerms::READ | FilePerms::WRITE
* the attacker opens the file `alias` for writing, in which they can overwrite `target`

Symbolic links are not a vector for this attack because the wasi-filesystem interfaces already enforces that the destination for a symlink is under the same preopen. We do not believe there are any other vectors to this attack because there are no other wasi filesystem interfaces that take multiple borrows of a descriptor resource for e.g. the source and destination in different descriptors.

### Remediation

The definition of `Dir::link_at` and `Dir::rename_at` in wasmtime-wasi's `src/filesystem.rs` now have an additional permissions check that ensures the source and destination values for the directory permissions `perms` and the file permissions `file_perms` are identical.

```rust
        if self.perms != new_dir.perms || self.file_perms != new_dir.file_perms {
            return Err(ErrorCode::NotPermitted);
        }
```

### Impact

Only wasmtime-wasi embeddings that use a combination of DirPerms::MUTATE with FilePerms::READ, as well as using a second preopen with higher permissions (FilePerms::WRITE as well), are affected by this bug, e.g. those that use in the WasiCtxBuilder:

```rust
builder.preopened_dir("readwrite", "readwrite", DirPerms::READ | DirPerms::MUTATE, FilePerms::READ | FilePerms::WRITE);
builder.preopened_dir("readonly", "readonly", DirPerms::READ | DirPerms::MUTATE, FilePerms::READ);
```

In particular, the Wasmtime project's wasmtime-cli's use of wasmtime-wasi is not affected, because it always sets FilePerms::all() for all preopens.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_