CVE-2026-58494: Wasmtime WASI Hard Links Bypass Wasmtime-wasi's Vulnerability

MODERATE
Advisory Identifier: GHSA-4ch3-9j33-3pmj
CVSS 6.5
CWE-863 CWE-281
Published
Advisory Summary

CVE-2026-58494 is a MODERATE (CVSS 6.5) wasi hard links bypass wasmtime-wasi's vulnerability (CWE-863: Incorrect Authorization) affecting Wasmtime libraries in the crates.io ecosystem. The issue involves wasi hard links bypass wasmtime-wasi's fileperms for destination. Remediation is available by upgrading affected packages to version 24.0.11, 36.0.12, 45.0.3, 46.0.1.

CVE-2026-58494 at a Glance

CVE Identifier CVE-2026-58494
GHSA Identifier GHSA-4ch3-9j33-3pmj
Severity MODERATE
CVSS v3.1 Base Score 6.5
CWE Classification CWE-863: Incorrect Authorization
Affected Product Wasmtime
Package Ecosystem crates.io
Published Date
Last Updated

Security Impact

CVSS: 6.5

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N).

Attack Vector Local (AV:L)
Attack Complexity Low (AC:L)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Changed (S:C)
Confidentiality None (C:N)
Integrity High (I:H)
Availability None (A:N)

How to Fix CVE-2026-58494

To remediate this vulnerability, upgrade all affected Wasmtime dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

wasmtime-wasi fixed: 24.0.11
Upgrade wasmtime-wasi to 24.0.11
wasmtime-wasi fixed: 36.0.12
Upgrade wasmtime-wasi to 36.0.12
wasmtime-wasi fixed: 45.0.3
Upgrade wasmtime-wasi to 45.0.3
wasmtime-wasi fixed: 46.0.1
Upgrade wasmtime-wasi to 46.0.1
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for wasmtime-wasi

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-58494, inspect your project dependencies for Wasmtime:

inspect dependencies for wasmtime-wasi

Analyze the terminal output to locate any version of Wasmtime in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 24.0.11), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-863: Incorrect Authorization, where the product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. In Wasmtime, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## 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.

CVE-2026-58494 Affected Wasmtime Versions

4 component(s)
Fixed Versions:
24.0.1136.0.1245.0.346.0.1
Product / Package Ecosystem Affected Versions Fixed Version
wasmtime-wasi
crates.io
< 24.0.11
24.0.11
wasmtime-wasi
crates.io
≥ 25.0.0
< 36.0.12
36.0.12
wasmtime-wasi
crates.io
≥ 37.0.0
< 45.0.3
45.0.3
wasmtime-wasi
crates.io
≥ 46.0.0
< 46.0.1
46.0.1

References

Frequently Asked Questions

What is CVE-2026-58494?
CVE-2026-58494 is a security vulnerability in Wasmtime involving WASI hard links bypass wasmtime-wasi's FilePerms for destination under CWE-863: Incorrect Authorization.
Which Wasmtime versions are affected?
Affected versions include releases prior to 24.0.11, 36.0.12, 45.0.3, 46.0.1 across affected packages: wasmtime-wasi.
What version fixes CVE-2026-58494?
Upgrading to 24.0.11, 36.0.12, 45.0.3, 46.0.1 (or the latest patched release for your respective branch) resolves the vulnerability.
Is wasmtime-wasi affected?
Yes, wasmtime-wasi is affected in releases prior to 24.0.11, 36.0.12, 45.0.3, 46.0.1. Upgrade your dependency to 24.0.11, 36.0.12, 45.0.3, 46.0.1 or later.
What is the CVSS score of CVE-2026-58494?
CVE-2026-58494 has a CVSS v3.1 base score of 6.5 (MODERATE) with vector string CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N.
What CWE is associated with CVE-2026-58494?
CVE-2026-58494 is classified under CWE-863: Incorrect Authorization (The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.).
How can I check crates.io dependencies for CVE-2026-58494?
Run the dependency tree command: 'inspect dependencies for wasmtime-wasi'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-4ch3-9j33-3pmj",
  "modified" : "2026-10-16T19:57:26Z",
  "published" : "2026-10-16T19:57:26Z",
  "aliases" : [ "CVE-2026-58494" ],
  "summary" : "Wasmtime: WASI hard links bypass wasmtime-wasi's FilePerms for destination",
  "details" : "## Summary\n\nWasmtime'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`.\n\nThis attack is possible through the wasip1, wasip2, and wasip3 interfaces to the WASI filesystem.\n\nThis attack is also possible through an indirection of renaming a hardlink into another preopen.\n\n### Details\n\n`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.\n\nThis makes an attack possible where:\n* a read-only file `target` exists in a preopen with only FilePerms::READ\n* a hardlink named `alias`, with destination to the `target`, is created in a preopen with FilePerms::READ | FilePerms::WRITE\n* the attacker opens the file `alias` for writing, in which they can overwrite `target`\n\nThe same attack is possible by way of renaming:\n* a read-only file `target` exists in a preopen with only FilePerms::READ\n* a hardlink named `alias`, with destination to the `target`, is created in that same preopen\n* the `alias` file is renamed into a preopen with FilePerms::READ | FilePerms::WRITE\n* the attacker opens the file `alias` for writing, in which they can overwrite `target`\n\nSymbolic 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.\n\n### Remediation\n\nThe 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.\n\n```rust\n        if self.perms != new_dir.perms || self.file_perms != new_dir.file_perms {\n            return Err(ErrorCode::NotPermitted);\n        }\n```\n\n### Impact\n\nOnly 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:\n\n```rust\nbuilder.preopened_dir(\"readwrite\", \"readwrite\", DirPerms::READ | DirPerms::MUTATE, FilePerms::READ | FilePerms::WRITE);\nbuilder.preopened_dir(\"readonly\", \"readonly\", DirPerms::READ | DirPerms::MUTATE, FilePerms::READ);\n```\n\nIn particular, the Wasmtime project's wasmtime-cli's use of wasmtime-wasi is not affected, because it always sets FilePerms::all() for all preopens.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "crates.io",
      "name" : "wasmtime-wasi"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "24.0.11"
      } ]
    } ]
  }, {
    "package" : {
      "ecosystem" : "crates.io",
      "name" : "wasmtime-wasi"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "25.0.0"
      }, {
        "fixed" : "36.0.12"
      } ]
    } ]
  }, {
    "package" : {
      "ecosystem" : "crates.io",
      "name" : "wasmtime-wasi"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "37.0.0"
      }, {
        "fixed" : "45.0.3"
      } ]
    } ]
  }, {
    "package" : {
      "ecosystem" : "crates.io",
      "name" : "wasmtime-wasi"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "46.0.0"
      }, {
        "fixed" : "46.0.1"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-4ch3-9j33-3pmj"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-58494"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/bytecodealliance/wasmtime/pull/13725"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/bytecodealliance/wasmtime/commit/5ddfd5f1ef28f2041fa07d237ad0336e167b0e0c"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/bytecodealliance/wasmtime/commit/7db94cdcf0c79cb3dfde884b534b653f2dd83367"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/bytecodealliance/wasmtime/commit/8a250aac0962ca1364b5f16525720e9d0b39edcd"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/bytecodealliance/wasmtime/commit/d3ceb56ec35f39e02496eeb4e2d9c7f4fb964d9e"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/bytecodealliance/wasmtime"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/bytecodealliance/wasmtime/releases/tag/v24.0.11"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/bytecodealliance/wasmtime/releases/tag/v36.0.12"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/bytecodealliance/wasmtime/releases/tag/v45.0.3"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/bytecodealliance/wasmtime/releases/tag/v46.0.1"
  }, {
    "type" : "WEB",
    "url" : "https://rustsec.org/advisories/RUSTSEC-2026-0188.html"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-281", "CWE-863" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-10-16T19:57:26Z",
    "nvd_published_at" : "2026-07-08T21:16:54Z"
  }
}