GHSA-4CH3-9J33-3PMJ

Vulnerability from github – Published: 2026-10-16 19:57 – Updated: 2026-10-16 19:57
VLAI
Summary
Wasmtime: WASI hard links bypass wasmtime-wasi's FilePerms for destination
Details

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.

        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:

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.

Severity
6.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime-wasi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "24.0.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime-wasi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "25.0.0"
            },
            {
              "fixed": "36.0.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime-wasi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "37.0.0"
            },
            {
              "fixed": "45.0.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime-wasi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "46.0.0"
            },
            {
              "fixed": "46.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-58494"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-281",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-16T19:57:26Z",
    "nvd_published_at": "2026-07-08T21:16:54Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nWasmtime\u0027s 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\u0027s `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\u0027s wasmtime-cli\u0027s use of wasmtime-wasi is not affected, because it always sets FilePerms::all() for all preopens.",
  "id": "GHSA-4ch3-9j33-3pmj",
  "modified": "2026-10-16T19:57:26Z",
  "published": "2026-10-16T19:57:26Z",
  "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"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Wasmtime: WASI hard links bypass wasmtime-wasi\u0027s FilePerms for destination"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.