Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🦀
🦀 crates.io
Not in CISA KEV
HIGH severity

GHSA-2r75-cxrj-cmph — wasmtime-wasi

HIGH

GHSA-2r75-cxrj-cmph is a high-severity (CVSS 7.5) CWE-284 vulnerability in wasmtime-wasi. A fix is available for wasmtime-wasi — see the affected versions and patch details below.

wasmtime-wasi: WASI path_open(TRUNCATE) bypasses `FilePerms::WRITE` host restriction

Also known asCVE-2026-47261RUSTSEC-2026-0149
Published
Jun 5, 2026
Updated
Sep 10, 2026
Affected
3 pkgs
Patched
3 / 3
Exploits
None indexed
Exploitation data as of Sep 27, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-2r75-cxrj-cmph.

EPSS Exploitation Probability

via FIRST.org ↗
0.5%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs40th percentile — riskier than 40% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

GHSA-2r75-cxrj-cmph by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 379,842 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

3 pkgs affected
🦀wasmtime-wasi🦀wasmtime-wasi🦀wasmtime-wasi

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.

Description

Summary

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 path_open interfaces by opening a file with OpenFlags::TRUNCATE oflag only, for example:

dir_descriptor.open_at(
   PathFlags::empty(),
   FILENAME,
   OpenFlags::TRUNCATE,
   DescriptorFlags::READ,
)
wasip1::path_open(
    dir_fd,
    0,
    FILENAME,
    wasip1::OFLAGS_TRUNC,
    wasip1::RIGHTS_FD_READ,
    0,
    0
)

The root cause is that the clause that considered OpenFlags::TRUNCATE did not set open_mode |= 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 path_open fail with error-code.not-permitted and ERRNO_PERM respectively.

The bug in crates/wasi/src/filesystem.rs, Dir::open_at, lines 967–969:

if oflags.contains(OpenFlags::TRUNCATE) {
    opts.truncate(true).write(true);
}

and the single line fix is:

if oflags.contains(OpenFlags::TRUNCATE) {
    opts.truncate(true).write(true);
    open_mode |= OpenMode::WRITE;
}

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:

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.

Affected Packages

3 total 3 fixed
EcosystemPackageVulnerable rangeFix
🦀crates.iowasmtime-wasi≥ 37.0.0&&< 44.0.244.0.2cargo update -p wasmtime-wasi --precise 44.0.2
🦀crates.iowasmtime-wasi≥ 25.0.0&&< 36.0.1036.0.10cargo update -p wasmtime-wasi --precise 36.0.10
🦀crates.iowasmtime-wasiall versions24.0.9cargo update -p wasmtime-wasi --precise 24.0.9

Affected Products

1 product · 3 configurations
Application
wasmtimebytecodealliance
≥ 37.0.0 && < 44.0.2
range

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for wasmtime-wasi, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update wasmtime-wasi to 44.0.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-2r75-cxrj-cmph is resolved across your whole dependency graph.

  3. Workarounds

    Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatModerate

Conditions for Exploitation: Successful exploitation relies on a highly specific configuration of wasmtime-wasi embeddings. The vulnerability only triggers if a filesystem preopen explicitly combines directory mutation permissions (DirPerms::MUTATE) with read-only file permissions (FilePerms::READ). Impact…

Workaround published by Red Hat
To mitigate this issue, ensure that `wasmtime-wasi` embeddings are not configured with a combination of `DirPerms::MUTATE` and `FilePerms::READ` for filesystem preopens. Review `WasiCtxBuilder` configurations to avoid this vulnerable permission combination, which allows an attacker to bypass access controls and truncate files that should otherwise be read-only.
Source: Red Hat security advisory for GHSA-2r75-cxrj-cmph (CC BY 4.0)

Frequently Asked Questions

## Summary 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 `path_open` interfaces by opening a file with `OpenFlags::TRUNCATE` oflag only, for example: ```rust dir_descriptor.open_at( PathFlags::empty(), FILENAME, OpenFlags::TRUNCATE, DescriptorFlags::READ, ) ``` ```rust wasip1::path_open( dir_fd, 0, FILENAME, wasip1::OFLAGS_TRUNC, wasip1::RIGHTS_FD_READ, 0,
O3 Security · Impact-Aware SCA

Is GHSA-2r75-cxrj-cmph in your dependencies?

Find it across crates.io, including transitive dependencies.

GHSA-2r75-cxrj-cmph: wasmtime-wasi | O3 Security