wasmtime-wasi

Version	Released
`48.0.2` patch	Sep 10, 2026
`36.0.15` patch	Sep 10, 2026
`49.0.0-rc.1` pre	Sep 05, 2026
`48.0.1` patch	Aug 24, 2026
`36.0.14` patch	Aug 20, 2026
`46.0.3` patch	Aug 20, 2026
`47.0.4` patch	Aug 20, 2026
`24.0.13` patch	Aug 20, 2026
`48.0.0` major	Aug 20, 2026
`47.0.3` patch	Jul 31, 2026
`46.0.2` patch	Jul 31, 2026
`36.0.13` patch	Jul 31, 2026
`24.0.12` patch	Jul 31, 2026
`47.0.2` patch	Jul 21, 2026
`47.0.1` patch	Jul 20, 2026
`47.0.0` major	Jul 20, 2026
`36.0.12` patch	Jun 24, 2026
`45.0.3` patch	Jun 24, 2026
`46.0.1` patch	Jun 24, 2026
`24.0.11` patch	Jun 24, 2026
`46.0.0` major 1 CVE	Jun 22, 2026
`24.0.10` patch 1 CVE	Jun 15, 2026
`44.0.3` patch 1 CVE	Jun 15, 2026
`45.0.2` patch 1 CVE	Jun 15, 2026
`36.0.11` patch 1 CVE	Jun 15, 2026
`45.0.1` patch 2 CVEs	Jun 05, 2026
`44.0.2` patch 2 CVEs	May 21, 2026
`36.0.10` patch 2 CVEs	May 21, 2026
`45.0.0` major 2 CVEs	May 21, 2026
`24.0.9` patch 2 CVEs	May 21, 2026
`36.0.9` patch 3 CVEs	May 05, 2026
`36.0.8` patch 3 CVEs	Apr 30, 2026
`43.0.2` patch 3 CVEs	Apr 30, 2026
`44.0.1` patch 3 CVEs	Apr 30, 2026
`24.0.8` patch 3 CVEs	Apr 30, 2026
`44.0.0` major 3 CVEs	Apr 20, 2026
`42.0.2` patch 3 CVEs	Apr 09, 2026
`43.0.1` patch 3 CVEs	Apr 09, 2026
`36.0.7` patch 3 CVEs	Apr 09, 2026
`24.0.7` patch 3 CVEs	Apr 09, 2026
`43.0.0` major 3 CVEs	Mar 20, 2026
`42.0.1` patch 3 CVEs	Feb 25, 2026
`41.0.4` patch 3 CVEs	Feb 24, 2026
`40.0.4` patch 3 CVEs	Feb 24, 2026
`42.0.0` major 3 CVEs	Feb 24, 2026
`24.0.6` patch 3 CVEs	Feb 24, 2026
`36.0.6` patch 3 CVEs	Feb 24, 2026
`41.0.3` patch 3 CVEs	Feb 04, 2026
`41.0.2` patch 3 CVEs	Feb 03, 2026
`40.0.3` patch 3 CVEs	Jan 27, 2026

48.0.2 patch

Sep 10, 2026

36.0.15 patch

Sep 10, 2026

49.0.0-rc.1 pre

Sep 05, 2026

48.0.1 patch

Aug 24, 2026

36.0.14 patch

Aug 20, 2026

46.0.3 patch

Aug 20, 2026

47.0.4 patch

Aug 20, 2026

24.0.13 patch

Aug 20, 2026

48.0.0 major

Aug 20, 2026

47.0.3 patch

Jul 31, 2026

46.0.2 patch

Jul 31, 2026

36.0.13 patch

Jul 31, 2026

24.0.12 patch

Jul 31, 2026

47.0.2 patch

Jul 21, 2026

47.0.1 patch

Jul 20, 2026

47.0.0 major

Jul 20, 2026

36.0.12 patch

Jun 24, 2026

45.0.3 patch

Jun 24, 2026

46.0.1 patch

Jun 24, 2026

24.0.11 patch

Jun 24, 2026

46.0.0 major

1 CVE

Jun 22, 2026

24.0.10 patch

1 CVE

Jun 15, 2026

44.0.3 patch

1 CVE

Jun 15, 2026

45.0.2 patch

1 CVE

Jun 15, 2026

36.0.11 patch

1 CVE

Jun 15, 2026

45.0.1 patch

2 CVEs

Jun 05, 2026

44.0.2 patch

2 CVEs

May 21, 2026

36.0.10 patch

2 CVEs

May 21, 2026

45.0.0 major

2 CVEs

May 21, 2026

24.0.9 patch

2 CVEs

May 21, 2026

36.0.9 patch

3 CVEs

CVE-2026-54786 GHSA-3p27-qvp9-27qf RUSTSEC-2026-0182 Aug 26, 2026

Wasmtime has a leak in WASIp1 `fd_renumber` implementation

Low

Network Low Low None

Impact

Wasmtime's native implementation of WASIp1 suffers from a leak in the fd_renumber function where the file descriptor being renumbered to is not properly closed. Wasmtime's implementation erroneously only updated the table of descriptors for WASIp1 and didn't update the underlying table of descriptors used by the host. This behavior means that while fd_renumber works correctly from a guest's perspective it ends up leaking resources in the host that aren't cleaned up until the corresponding Store is destroyed. This means that guests can, in a loop, use fd_renumber to cause hosts to exhaust resources or exhaust file descriptors.

This bug only affects the native implementation of WASIp1. This means that only runtimes which load core wasm modules and expose fd_renumber are affected. Runtimes are additionally only affected if they expose the ability to acquire a file descriptor, such as opening a file. For runtimes that deny access to files they are unaffected.

Patches

Wasmtime 24.0.10, 36.0.11, 44.0.3, and 45.0.2 have been released which fix this issue.

Workarounds

There are no workarounds for this issue and hosts are recommended to update.

Fixed in


          24.0.10


          36.0.11


          44.0.3


          45.0.2

References

Updated Aug 26, 2026 · Source: OSV.dev

CVE-2026-58494 RUSTSEC-2026-0188 GHSA-4ch3-9j33-3pmj Jun 24, 2026

WASI hard links and renames bypass wasmtime-wasi's FilePerms for destination

6.5 / 10

Medium

Local Low Low None Changed None High None

This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-4ch3-9j33-3pmj For more information see the GitHub-hosted security advisory.

Fixed in


          24.0.11


          36.0.12


          45.0.3


          46.0.1

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-47261 GHSA-2r75-cxrj-cmph RUSTSEC-2026-0149 Jun 05, 2026

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

7.5 / 10

High

Network Low None None Unchanged None High None

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.

Fixed in


          24.0.9


          36.0.10


          44.0.2

References

Updated Sep 10, 2026 · Source: OSV.dev

May 05, 2026

36.0.8 patch

3 CVEs

CVE-2026-54786 GHSA-3p27-qvp9-27qf RUSTSEC-2026-0182 Aug 26, 2026

Wasmtime has a leak in WASIp1 `fd_renumber` implementation

Low

Network Low Low None

Impact

Wasmtime's native implementation of WASIp1 suffers from a leak in the fd_renumber function where the file descriptor being renumbered to is not properly closed. Wasmtime's implementation erroneously only updated the table of descriptors for WASIp1 and didn't update the underlying table of descriptors used by the host. This behavior means that while fd_renumber works correctly from a guest's perspective it ends up leaking resources in the host that aren't cleaned up until the corresponding Store is destroyed. This means that guests can, in a loop, use fd_renumber to cause hosts to exhaust resources or exhaust file descriptors.

This bug only affects the native implementation of WASIp1. This means that only runtimes which load core wasm modules and expose fd_renumber are affected. Runtimes are additionally only affected if they expose the ability to acquire a file descriptor, such as opening a file. For runtimes that deny access to files they are unaffected.

Patches

Wasmtime 24.0.10, 36.0.11, 44.0.3, and 45.0.2 have been released which fix this issue.

Workarounds

There are no workarounds for this issue and hosts are recommended to update.

Fixed in


          24.0.10


          36.0.11


          44.0.3


          45.0.2

References

Updated Aug 26, 2026 · Source: OSV.dev

CVE-2026-58494 RUSTSEC-2026-0188 GHSA-4ch3-9j33-3pmj Jun 24, 2026

WASI hard links and renames bypass wasmtime-wasi's FilePerms for destination

6.5 / 10

Medium

Local Low Low None Changed None High None

This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-4ch3-9j33-3pmj For more information see the GitHub-hosted security advisory.

Fixed in


          24.0.11


          36.0.12


          45.0.3


          46.0.1

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-47261 GHSA-2r75-cxrj-cmph RUSTSEC-2026-0149 Jun 05, 2026

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

7.5 / 10

High

Network Low None None Unchanged None High None

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.

Fixed in


          24.0.9


          36.0.10


          44.0.2

References

Updated Sep 10, 2026 · Source: OSV.dev

Apr 30, 2026

43.0.2 patch

3 CVEs

CVE-2026-54786 GHSA-3p27-qvp9-27qf RUSTSEC-2026-0182 Aug 26, 2026

Wasmtime has a leak in WASIp1 `fd_renumber` implementation

Low

Network Low Low None

Impact

Wasmtime's native implementation of WASIp1 suffers from a leak in the fd_renumber function where the file descriptor being renumbered to is not properly closed. Wasmtime's implementation erroneously only updated the table of descriptors for WASIp1 and didn't update the underlying table of descriptors used by the host. This behavior means that while fd_renumber works correctly from a guest's perspective it ends up leaking resources in the host that aren't cleaned up until the corresponding Store is destroyed. This means that guests can, in a loop, use fd_renumber to cause hosts to exhaust resources or exhaust file descriptors.

This bug only affects the native implementation of WASIp1. This means that only runtimes which load core wasm modules and expose fd_renumber are affected. Runtimes are additionally only affected if they expose the ability to acquire a file descriptor, such as opening a file. For runtimes that deny access to files they are unaffected.

Patches

Wasmtime 24.0.10, 36.0.11, 44.0.3, and 45.0.2 have been released which fix this issue.

Workarounds

There are no workarounds for this issue and hosts are recommended to update.

Fixed in


          24.0.10


          36.0.11


          44.0.3


          45.0.2

References

Updated Aug 26, 2026 · Source: OSV.dev

CVE-2026-58494 RUSTSEC-2026-0188 GHSA-4ch3-9j33-3pmj Jun 24, 2026

WASI hard links and renames bypass wasmtime-wasi's FilePerms for destination

6.5 / 10

Medium

Local Low Low None Changed None High None

This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-4ch3-9j33-3pmj For more information see the GitHub-hosted security advisory.

Fixed in


          24.0.11


          36.0.12


          45.0.3


          46.0.1

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-47261 GHSA-2r75-cxrj-cmph RUSTSEC-2026-0149 Jun 05, 2026

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

7.5 / 10

High

Network Low None None Unchanged None High None

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.

Fixed in


          24.0.9


          36.0.10


          44.0.2

References

Updated Sep 10, 2026 · Source: OSV.dev

Apr 30, 2026

44.0.1 patch

3 CVEs

CVE-2026-54786 GHSA-3p27-qvp9-27qf RUSTSEC-2026-0182 Aug 26, 2026

Wasmtime has a leak in WASIp1 `fd_renumber` implementation

Low

Network Low Low None

Impact

Wasmtime's native implementation of WASIp1 suffers from a leak in the fd_renumber function where the file descriptor being renumbered to is not properly closed. Wasmtime's implementation erroneously only updated the table of descriptors for WASIp1 and didn't update the underlying table of descriptors used by the host. This behavior means that while fd_renumber works correctly from a guest's perspective it ends up leaking resources in the host that aren't cleaned up until the corresponding Store is destroyed. This means that guests can, in a loop, use fd_renumber to cause hosts to exhaust resources or exhaust file descriptors.

This bug only affects the native implementation of WASIp1. This means that only runtimes which load core wasm modules and expose fd_renumber are affected. Runtimes are additionally only affected if they expose the ability to acquire a file descriptor, such as opening a file. For runtimes that deny access to files they are unaffected.

Patches

Wasmtime 24.0.10, 36.0.11, 44.0.3, and 45.0.2 have been released which fix this issue.

Workarounds

There are no workarounds for this issue and hosts are recommended to update.

Fixed in


          24.0.10


          36.0.11


          44.0.3


          45.0.2

References

Updated Aug 26, 2026 · Source: OSV.dev

CVE-2026-58494 RUSTSEC-2026-0188 GHSA-4ch3-9j33-3pmj Jun 24, 2026

WASI hard links and renames bypass wasmtime-wasi's FilePerms for destination

6.5 / 10

Medium

Local Low Low None Changed None High None

This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-4ch3-9j33-3pmj For more information see the GitHub-hosted security advisory.

Fixed in


          24.0.11


          36.0.12


          45.0.3


          46.0.1

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-47261 GHSA-2r75-cxrj-cmph RUSTSEC-2026-0149 Jun 05, 2026

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

7.5 / 10

High

Network Low None None Unchanged None High None

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.

Fixed in


          24.0.9


          36.0.10


          44.0.2

References

Updated Sep 10, 2026 · Source: OSV.dev

Apr 30, 2026

24.0.8 patch

3 CVEs

CVE-2026-54786 GHSA-3p27-qvp9-27qf RUSTSEC-2026-0182 Aug 26, 2026

Wasmtime has a leak in WASIp1 `fd_renumber` implementation

Low

Network Low Low None

Impact

Wasmtime's native implementation of WASIp1 suffers from a leak in the fd_renumber function where the file descriptor being renumbered to is not properly closed. Wasmtime's implementation erroneously only updated the table of descriptors for WASIp1 and didn't update the underlying table of descriptors used by the host. This behavior means that while fd_renumber works correctly from a guest's perspective it ends up leaking resources in the host that aren't cleaned up until the corresponding Store is destroyed. This means that guests can, in a loop, use fd_renumber to cause hosts to exhaust resources or exhaust file descriptors.

This bug only affects the native implementation of WASIp1. This means that only runtimes which load core wasm modules and expose fd_renumber are affected. Runtimes are additionally only affected if they expose the ability to acquire a file descriptor, such as opening a file. For runtimes that deny access to files they are unaffected.

Patches

Wasmtime 24.0.10, 36.0.11, 44.0.3, and 45.0.2 have been released which fix this issue.

Workarounds

There are no workarounds for this issue and hosts are recommended to update.

Fixed in


          24.0.10


          36.0.11


          44.0.3


          45.0.2

References

Updated Aug 26, 2026 · Source: OSV.dev

CVE-2026-58494 RUSTSEC-2026-0188 GHSA-4ch3-9j33-3pmj Jun 24, 2026

WASI hard links and renames bypass wasmtime-wasi's FilePerms for destination

6.5 / 10

Medium

Local Low Low None Changed None High None

This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-4ch3-9j33-3pmj For more information see the GitHub-hosted security advisory.

Fixed in


          24.0.11


          36.0.12


          45.0.3


          46.0.1

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-47261 GHSA-2r75-cxrj-cmph RUSTSEC-2026-0149 Jun 05, 2026

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

7.5 / 10

High

Network Low None None Unchanged None High None

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.

Fixed in


          24.0.9


          36.0.10


          44.0.2

References

Updated Sep 10, 2026 · Source: OSV.dev

Apr 30, 2026

44.0.0 major

3 CVEs

CVE-2026-54786 GHSA-3p27-qvp9-27qf RUSTSEC-2026-0182 Aug 26, 2026

Wasmtime has a leak in WASIp1 `fd_renumber` implementation

Low

Network Low Low None

Impact

Wasmtime's native implementation of WASIp1 suffers from a leak in the fd_renumber function where the file descriptor being renumbered to is not properly closed. Wasmtime's implementation erroneously only updated the table of descriptors for WASIp1 and didn't update the underlying table of descriptors used by the host. This behavior means that while fd_renumber works correctly from a guest's perspective it ends up leaking resources in the host that aren't cleaned up until the corresponding Store is destroyed. This means that guests can, in a loop, use fd_renumber to cause hosts to exhaust resources or exhaust file descriptors.

This bug only affects the native implementation of WASIp1. This means that only runtimes which load core wasm modules and expose fd_renumber are affected. Runtimes are additionally only affected if they expose the ability to acquire a file descriptor, such as opening a file. For runtimes that deny access to files they are unaffected.

Patches

Wasmtime 24.0.10, 36.0.11, 44.0.3, and 45.0.2 have been released which fix this issue.

Workarounds

There are no workarounds for this issue and hosts are recommended to update.

Fixed in


          24.0.10


          36.0.11


          44.0.3


          45.0.2

References

Updated Aug 26, 2026 · Source: OSV.dev

CVE-2026-58494 RUSTSEC-2026-0188 GHSA-4ch3-9j33-3pmj Jun 24, 2026

WASI hard links and renames bypass wasmtime-wasi's FilePerms for destination

6.5 / 10

Medium

Local Low Low None Changed None High None

This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-4ch3-9j33-3pmj For more information see the GitHub-hosted security advisory.

Fixed in


          24.0.11


          36.0.12


          45.0.3


          46.0.1

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-47261 GHSA-2r75-cxrj-cmph RUSTSEC-2026-0149 Jun 05, 2026

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

7.5 / 10

High

Network Low None None Unchanged None High None

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.

Fixed in


          24.0.9


          36.0.10


          44.0.2

References

Updated Sep 10, 2026 · Source: OSV.dev

Apr 20, 2026

42.0.2 patch

3 CVEs

CVE-2026-54786 GHSA-3p27-qvp9-27qf RUSTSEC-2026-0182 Aug 26, 2026

Wasmtime has a leak in WASIp1 `fd_renumber` implementation

Low

Network Low Low None

Impact

Wasmtime's native implementation of WASIp1 suffers from a leak in the fd_renumber function where the file descriptor being renumbered to is not properly closed. Wasmtime's implementation erroneously only updated the table of descriptors for WASIp1 and didn't update the underlying table of descriptors used by the host. This behavior means that while fd_renumber works correctly from a guest's perspective it ends up leaking resources in the host that aren't cleaned up until the corresponding Store is destroyed. This means that guests can, in a loop, use fd_renumber to cause hosts to exhaust resources or exhaust file descriptors.

This bug only affects the native implementation of WASIp1. This means that only runtimes which load core wasm modules and expose fd_renumber are affected. Runtimes are additionally only affected if they expose the ability to acquire a file descriptor, such as opening a file. For runtimes that deny access to files they are unaffected.

Patches

Wasmtime 24.0.10, 36.0.11, 44.0.3, and 45.0.2 have been released which fix this issue.

Workarounds

There are no workarounds for this issue and hosts are recommended to update.

Fixed in


          24.0.10


          36.0.11


          44.0.3


          45.0.2

References

Updated Aug 26, 2026 · Source: OSV.dev

CVE-2026-58494 RUSTSEC-2026-0188 GHSA-4ch3-9j33-3pmj Jun 24, 2026

WASI hard links and renames bypass wasmtime-wasi's FilePerms for destination

6.5 / 10

Medium

Local Low Low None Changed None High None

This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-4ch3-9j33-3pmj For more information see the GitHub-hosted security advisory.

Fixed in


          24.0.11


          36.0.12


          45.0.3


          46.0.1

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-47261 GHSA-2r75-cxrj-cmph RUSTSEC-2026-0149 Jun 05, 2026

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

7.5 / 10

High

Network Low None None Unchanged None High None

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.

Fixed in


          24.0.9


          36.0.10


          44.0.2

References

Updated Sep 10, 2026 · Source: OSV.dev

Apr 09, 2026

43.0.1 patch

3 CVEs

CVE-2026-54786 GHSA-3p27-qvp9-27qf RUSTSEC-2026-0182 Aug 26, 2026

Wasmtime has a leak in WASIp1 `fd_renumber` implementation

Low

Network Low Low None

Impact

Wasmtime's native implementation of WASIp1 suffers from a leak in the fd_renumber function where the file descriptor being renumbered to is not properly closed. Wasmtime's implementation erroneously only updated the table of descriptors for WASIp1 and didn't update the underlying table of descriptors used by the host. This behavior means that while fd_renumber works correctly from a guest's perspective it ends up leaking resources in the host that aren't cleaned up until the corresponding Store is destroyed. This means that guests can, in a loop, use fd_renumber to cause hosts to exhaust resources or exhaust file descriptors.

This bug only affects the native implementation of WASIp1. This means that only runtimes which load core wasm modules and expose fd_renumber are affected. Runtimes are additionally only affected if they expose the ability to acquire a file descriptor, such as opening a file. For runtimes that deny access to files they are unaffected.

Patches

Wasmtime 24.0.10, 36.0.11, 44.0.3, and 45.0.2 have been released which fix this issue.

Workarounds

There are no workarounds for this issue and hosts are recommended to update.

Fixed in


          24.0.10


          36.0.11


          44.0.3


          45.0.2

References

Updated Aug 26, 2026 · Source: OSV.dev

CVE-2026-58494 RUSTSEC-2026-0188 GHSA-4ch3-9j33-3pmj Jun 24, 2026

WASI hard links and renames bypass wasmtime-wasi's FilePerms for destination

6.5 / 10

Medium

Local Low Low None Changed None High None

This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-4ch3-9j33-3pmj For more information see the GitHub-hosted security advisory.

Fixed in


          24.0.11


          36.0.12


          45.0.3


          46.0.1

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-47261 GHSA-2r75-cxrj-cmph RUSTSEC-2026-0149 Jun 05, 2026

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

7.5 / 10

High

Network Low None None Unchanged None High None

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.

Fixed in


          24.0.9


          36.0.10


          44.0.2

References

Updated Sep 10, 2026 · Source: OSV.dev

Apr 09, 2026

36.0.7 patch

3 CVEs

CVE-2026-54786 GHSA-3p27-qvp9-27qf RUSTSEC-2026-0182 Aug 26, 2026

Wasmtime has a leak in WASIp1 `fd_renumber` implementation

Low

Network Low Low None

Impact

Wasmtime's native implementation of WASIp1 suffers from a leak in the fd_renumber function where the file descriptor being renumbered to is not properly closed. Wasmtime's implementation erroneously only updated the table of descriptors for WASIp1 and didn't update the underlying table of descriptors used by the host. This behavior means that while fd_renumber works correctly from a guest's perspective it ends up leaking resources in the host that aren't cleaned up until the corresponding Store is destroyed. This means that guests can, in a loop, use fd_renumber to cause hosts to exhaust resources or exhaust file descriptors.

This bug only affects the native implementation of WASIp1. This means that only runtimes which load core wasm modules and expose fd_renumber are affected. Runtimes are additionally only affected if they expose the ability to acquire a file descriptor, such as opening a file. For runtimes that deny access to files they are unaffected.

Patches

Wasmtime 24.0.10, 36.0.11, 44.0.3, and 45.0.2 have been released which fix this issue.

Workarounds

There are no workarounds for this issue and hosts are recommended to update.

Fixed in


          24.0.10


          36.0.11


          44.0.3


          45.0.2

References

Updated Aug 26, 2026 · Source: OSV.dev

CVE-2026-58494 RUSTSEC-2026-0188 GHSA-4ch3-9j33-3pmj Jun 24, 2026

WASI hard links and renames bypass wasmtime-wasi's FilePerms for destination

6.5 / 10

Medium

Local Low Low None Changed None High None

This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-4ch3-9j33-3pmj For more information see the GitHub-hosted security advisory.

Fixed in


          24.0.11


          36.0.12


          45.0.3


          46.0.1

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-47261 GHSA-2r75-cxrj-cmph RUSTSEC-2026-0149 Jun 05, 2026

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

7.5 / 10

High

Network Low None None Unchanged None High None

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.

Fixed in


          24.0.9


          36.0.10


          44.0.2

References

Updated Sep 10, 2026 · Source: OSV.dev

Apr 09, 2026

24.0.7 patch

3 CVEs

CVE-2026-54786 GHSA-3p27-qvp9-27qf RUSTSEC-2026-0182 Aug 26, 2026

Wasmtime has a leak in WASIp1 `fd_renumber` implementation

Low

Network Low Low None

Impact

Wasmtime's native implementation of WASIp1 suffers from a leak in the fd_renumber function where the file descriptor being renumbered to is not properly closed. Wasmtime's implementation erroneously only updated the table of descriptors for WASIp1 and didn't update the underlying table of descriptors used by the host. This behavior means that while fd_renumber works correctly from a guest's perspective it ends up leaking resources in the host that aren't cleaned up until the corresponding Store is destroyed. This means that guests can, in a loop, use fd_renumber to cause hosts to exhaust resources or exhaust file descriptors.

This bug only affects the native implementation of WASIp1. This means that only runtimes which load core wasm modules and expose fd_renumber are affected. Runtimes are additionally only affected if they expose the ability to acquire a file descriptor, such as opening a file. For runtimes that deny access to files they are unaffected.

Patches

Wasmtime 24.0.10, 36.0.11, 44.0.3, and 45.0.2 have been released which fix this issue.

Workarounds

There are no workarounds for this issue and hosts are recommended to update.

Fixed in


          24.0.10


          36.0.11


          44.0.3


          45.0.2

References

Updated Aug 26, 2026 · Source: OSV.dev

CVE-2026-58494 RUSTSEC-2026-0188 GHSA-4ch3-9j33-3pmj Jun 24, 2026

WASI hard links and renames bypass wasmtime-wasi's FilePerms for destination

6.5 / 10

Medium

Local Low Low None Changed None High None

This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-4ch3-9j33-3pmj For more information see the GitHub-hosted security advisory.

Fixed in


          24.0.11


          36.0.12


          45.0.3


          46.0.1

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-47261 GHSA-2r75-cxrj-cmph RUSTSEC-2026-0149 Jun 05, 2026

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

7.5 / 10

High

Network Low None None Unchanged None High None

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.

Fixed in


          24.0.9


          36.0.10


          44.0.2

References

Updated Sep 10, 2026 · Source: OSV.dev

Apr 09, 2026

43.0.0 major

3 CVEs

CVE-2026-54786 GHSA-3p27-qvp9-27qf RUSTSEC-2026-0182 Aug 26, 2026

Wasmtime has a leak in WASIp1 `fd_renumber` implementation

Low

Network Low Low None

Impact

Wasmtime's native implementation of WASIp1 suffers from a leak in the fd_renumber function where the file descriptor being renumbered to is not properly closed. Wasmtime's implementation erroneously only updated the table of descriptors for WASIp1 and didn't update the underlying table of descriptors used by the host. This behavior means that while fd_renumber works correctly from a guest's perspective it ends up leaking resources in the host that aren't cleaned up until the corresponding Store is destroyed. This means that guests can, in a loop, use fd_renumber to cause hosts to exhaust resources or exhaust file descriptors.

This bug only affects the native implementation of WASIp1. This means that only runtimes which load core wasm modules and expose fd_renumber are affected. Runtimes are additionally only affected if they expose the ability to acquire a file descriptor, such as opening a file. For runtimes that deny access to files they are unaffected.

Patches

Wasmtime 24.0.10, 36.0.11, 44.0.3, and 45.0.2 have been released which fix this issue.

Workarounds

There are no workarounds for this issue and hosts are recommended to update.

Fixed in


          24.0.10


          36.0.11


          44.0.3


          45.0.2

References

Updated Aug 26, 2026 · Source: OSV.dev

CVE-2026-58494 RUSTSEC-2026-0188 GHSA-4ch3-9j33-3pmj Jun 24, 2026

WASI hard links and renames bypass wasmtime-wasi's FilePerms for destination

6.5 / 10

Medium

Local Low Low None Changed None High None

This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-4ch3-9j33-3pmj For more information see the GitHub-hosted security advisory.

Fixed in


          24.0.11


          36.0.12


          45.0.3


          46.0.1

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-47261 GHSA-2r75-cxrj-cmph RUSTSEC-2026-0149 Jun 05, 2026

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

7.5 / 10

High

Network Low None None Unchanged None High None

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.

Fixed in


          24.0.9


          36.0.10


          44.0.2

References

Updated Sep 10, 2026 · Source: OSV.dev

Mar 20, 2026

42.0.1 patch

3 CVEs

CVE-2026-54786 GHSA-3p27-qvp9-27qf RUSTSEC-2026-0182 Aug 26, 2026

Wasmtime has a leak in WASIp1 `fd_renumber` implementation

Low

Network Low Low None

Impact

Wasmtime's native implementation of WASIp1 suffers from a leak in the fd_renumber function where the file descriptor being renumbered to is not properly closed. Wasmtime's implementation erroneously only updated the table of descriptors for WASIp1 and didn't update the underlying table of descriptors used by the host. This behavior means that while fd_renumber works correctly from a guest's perspective it ends up leaking resources in the host that aren't cleaned up until the corresponding Store is destroyed. This means that guests can, in a loop, use fd_renumber to cause hosts to exhaust resources or exhaust file descriptors.

This bug only affects the native implementation of WASIp1. This means that only runtimes which load core wasm modules and expose fd_renumber are affected. Runtimes are additionally only affected if they expose the ability to acquire a file descriptor, such as opening a file. For runtimes that deny access to files they are unaffected.

Patches

Wasmtime 24.0.10, 36.0.11, 44.0.3, and 45.0.2 have been released which fix this issue.

Workarounds

There are no workarounds for this issue and hosts are recommended to update.

Fixed in


          24.0.10


          36.0.11


          44.0.3


          45.0.2

References

Updated Aug 26, 2026 · Source: OSV.dev

CVE-2026-58494 RUSTSEC-2026-0188 GHSA-4ch3-9j33-3pmj Jun 24, 2026

WASI hard links and renames bypass wasmtime-wasi's FilePerms for destination

6.5 / 10

Medium

Local Low Low None Changed None High None

This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-4ch3-9j33-3pmj For more information see the GitHub-hosted security advisory.

Fixed in


          24.0.11


          36.0.12


          45.0.3


          46.0.1

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-47261 GHSA-2r75-cxrj-cmph RUSTSEC-2026-0149 Jun 05, 2026

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

7.5 / 10

High

Network Low None None Unchanged None High None

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.

Fixed in


          24.0.9


          36.0.10


          44.0.2

References

Updated Sep 10, 2026 · Source: OSV.dev

Feb 25, 2026

41.0.4 patch

3 CVEs

CVE-2026-54786 GHSA-3p27-qvp9-27qf RUSTSEC-2026-0182 Aug 26, 2026

Wasmtime has a leak in WASIp1 `fd_renumber` implementation

Low

Network Low Low None

Impact

Wasmtime's native implementation of WASIp1 suffers from a leak in the fd_renumber function where the file descriptor being renumbered to is not properly closed. Wasmtime's implementation erroneously only updated the table of descriptors for WASIp1 and didn't update the underlying table of descriptors used by the host. This behavior means that while fd_renumber works correctly from a guest's perspective it ends up leaking resources in the host that aren't cleaned up until the corresponding Store is destroyed. This means that guests can, in a loop, use fd_renumber to cause hosts to exhaust resources or exhaust file descriptors.

This bug only affects the native implementation of WASIp1. This means that only runtimes which load core wasm modules and expose fd_renumber are affected. Runtimes are additionally only affected if they expose the ability to acquire a file descriptor, such as opening a file. For runtimes that deny access to files they are unaffected.

Patches

Wasmtime 24.0.10, 36.0.11, 44.0.3, and 45.0.2 have been released which fix this issue.

Workarounds

There are no workarounds for this issue and hosts are recommended to update.

Fixed in


          24.0.10


          36.0.11


          44.0.3


          45.0.2

References

Updated Aug 26, 2026 · Source: OSV.dev

CVE-2026-58494 RUSTSEC-2026-0188 GHSA-4ch3-9j33-3pmj Jun 24, 2026

WASI hard links and renames bypass wasmtime-wasi's FilePerms for destination

6.5 / 10

Medium

Local Low Low None Changed None High None

This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-4ch3-9j33-3pmj For more information see the GitHub-hosted security advisory.

Fixed in


          24.0.11


          36.0.12


          45.0.3


          46.0.1

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-47261 GHSA-2r75-cxrj-cmph RUSTSEC-2026-0149 Jun 05, 2026

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

7.5 / 10

High

Network Low None None Unchanged None High None

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.

Fixed in


          24.0.9


          36.0.10


          44.0.2

References

Updated Sep 10, 2026 · Source: OSV.dev

Feb 24, 2026

40.0.4 patch

3 CVEs

CVE-2026-54786 GHSA-3p27-qvp9-27qf RUSTSEC-2026-0182 Aug 26, 2026

Wasmtime has a leak in WASIp1 `fd_renumber` implementation

Low

Network Low Low None

Impact

Wasmtime's native implementation of WASIp1 suffers from a leak in the fd_renumber function where the file descriptor being renumbered to is not properly closed. Wasmtime's implementation erroneously only updated the table of descriptors for WASIp1 and didn't update the underlying table of descriptors used by the host. This behavior means that while fd_renumber works correctly from a guest's perspective it ends up leaking resources in the host that aren't cleaned up until the corresponding Store is destroyed. This means that guests can, in a loop, use fd_renumber to cause hosts to exhaust resources or exhaust file descriptors.

This bug only affects the native implementation of WASIp1. This means that only runtimes which load core wasm modules and expose fd_renumber are affected. Runtimes are additionally only affected if they expose the ability to acquire a file descriptor, such as opening a file. For runtimes that deny access to files they are unaffected.

Patches

Wasmtime 24.0.10, 36.0.11, 44.0.3, and 45.0.2 have been released which fix this issue.

Workarounds

There are no workarounds for this issue and hosts are recommended to update.

Fixed in


          24.0.10


          36.0.11


          44.0.3


          45.0.2

References

Updated Aug 26, 2026 · Source: OSV.dev

CVE-2026-58494 RUSTSEC-2026-0188 GHSA-4ch3-9j33-3pmj Jun 24, 2026

WASI hard links and renames bypass wasmtime-wasi's FilePerms for destination

6.5 / 10

Medium

Local Low Low None Changed None High None

This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-4ch3-9j33-3pmj For more information see the GitHub-hosted security advisory.

Fixed in


          24.0.11


          36.0.12


          45.0.3


          46.0.1

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-47261 GHSA-2r75-cxrj-cmph RUSTSEC-2026-0149 Jun 05, 2026

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

7.5 / 10

High

Network Low None None Unchanged None High None

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.

Fixed in


          24.0.9


          36.0.10


          44.0.2

References

Updated Sep 10, 2026 · Source: OSV.dev

Feb 24, 2026

42.0.0 major

3 CVEs

CVE-2026-54786 GHSA-3p27-qvp9-27qf RUSTSEC-2026-0182 Aug 26, 2026

Wasmtime has a leak in WASIp1 `fd_renumber` implementation

Low

Network Low Low None

Impact

Wasmtime's native implementation of WASIp1 suffers from a leak in the fd_renumber function where the file descriptor being renumbered to is not properly closed. Wasmtime's implementation erroneously only updated the table of descriptors for WASIp1 and didn't update the underlying table of descriptors used by the host. This behavior means that while fd_renumber works correctly from a guest's perspective it ends up leaking resources in the host that aren't cleaned up until the corresponding Store is destroyed. This means that guests can, in a loop, use fd_renumber to cause hosts to exhaust resources or exhaust file descriptors.

This bug only affects the native implementation of WASIp1. This means that only runtimes which load core wasm modules and expose fd_renumber are affected. Runtimes are additionally only affected if they expose the ability to acquire a file descriptor, such as opening a file. For runtimes that deny access to files they are unaffected.

Patches

Wasmtime 24.0.10, 36.0.11, 44.0.3, and 45.0.2 have been released which fix this issue.

Workarounds

There are no workarounds for this issue and hosts are recommended to update.

Fixed in


          24.0.10


          36.0.11


          44.0.3


          45.0.2

References

Updated Aug 26, 2026 · Source: OSV.dev

CVE-2026-58494 RUSTSEC-2026-0188 GHSA-4ch3-9j33-3pmj Jun 24, 2026

WASI hard links and renames bypass wasmtime-wasi's FilePerms for destination

6.5 / 10

Medium

Local Low Low None Changed None High None

This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-4ch3-9j33-3pmj For more information see the GitHub-hosted security advisory.

Fixed in


          24.0.11


          36.0.12


          45.0.3


          46.0.1

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-47261 GHSA-2r75-cxrj-cmph RUSTSEC-2026-0149 Jun 05, 2026

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

7.5 / 10

High

Network Low None None Unchanged None High None

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.

Fixed in


          24.0.9


          36.0.10


          44.0.2

References

Updated Sep 10, 2026 · Source: OSV.dev

Feb 24, 2026

24.0.6 patch

3 CVEs

CVE-2026-54786 GHSA-3p27-qvp9-27qf RUSTSEC-2026-0182 Aug 26, 2026

Wasmtime has a leak in WASIp1 `fd_renumber` implementation

Low

Network Low Low None

Impact

Wasmtime's native implementation of WASIp1 suffers from a leak in the fd_renumber function where the file descriptor being renumbered to is not properly closed. Wasmtime's implementation erroneously only updated the table of descriptors for WASIp1 and didn't update the underlying table of descriptors used by the host. This behavior means that while fd_renumber works correctly from a guest's perspective it ends up leaking resources in the host that aren't cleaned up until the corresponding Store is destroyed. This means that guests can, in a loop, use fd_renumber to cause hosts to exhaust resources or exhaust file descriptors.

This bug only affects the native implementation of WASIp1. This means that only runtimes which load core wasm modules and expose fd_renumber are affected. Runtimes are additionally only affected if they expose the ability to acquire a file descriptor, such as opening a file. For runtimes that deny access to files they are unaffected.

Patches

Wasmtime 24.0.10, 36.0.11, 44.0.3, and 45.0.2 have been released which fix this issue.

Workarounds

There are no workarounds for this issue and hosts are recommended to update.

Fixed in


          24.0.10


          36.0.11


          44.0.3


          45.0.2

References

Updated Aug 26, 2026 · Source: OSV.dev

CVE-2026-58494 RUSTSEC-2026-0188 GHSA-4ch3-9j33-3pmj Jun 24, 2026

WASI hard links and renames bypass wasmtime-wasi's FilePerms for destination

6.5 / 10

Medium

Local Low Low None Changed None High None

This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-4ch3-9j33-3pmj For more information see the GitHub-hosted security advisory.

Fixed in


          24.0.11


          36.0.12


          45.0.3


          46.0.1

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-47261 GHSA-2r75-cxrj-cmph RUSTSEC-2026-0149 Jun 05, 2026

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

7.5 / 10

High

Network Low None None Unchanged None High None

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.

Fixed in


          24.0.9


          36.0.10


          44.0.2

References

Updated Sep 10, 2026 · Source: OSV.dev

Feb 24, 2026

36.0.6 patch

3 CVEs

CVE-2026-54786 GHSA-3p27-qvp9-27qf RUSTSEC-2026-0182 Aug 26, 2026

Wasmtime has a leak in WASIp1 `fd_renumber` implementation

Low

Network Low Low None

Impact

Wasmtime's native implementation of WASIp1 suffers from a leak in the fd_renumber function where the file descriptor being renumbered to is not properly closed. Wasmtime's implementation erroneously only updated the table of descriptors for WASIp1 and didn't update the underlying table of descriptors used by the host. This behavior means that while fd_renumber works correctly from a guest's perspective it ends up leaking resources in the host that aren't cleaned up until the corresponding Store is destroyed. This means that guests can, in a loop, use fd_renumber to cause hosts to exhaust resources or exhaust file descriptors.

This bug only affects the native implementation of WASIp1. This means that only runtimes which load core wasm modules and expose fd_renumber are affected. Runtimes are additionally only affected if they expose the ability to acquire a file descriptor, such as opening a file. For runtimes that deny access to files they are unaffected.

Patches

Wasmtime 24.0.10, 36.0.11, 44.0.3, and 45.0.2 have been released which fix this issue.

Workarounds

There are no workarounds for this issue and hosts are recommended to update.

Fixed in


          24.0.10


          36.0.11


          44.0.3


          45.0.2

References

Updated Aug 26, 2026 · Source: OSV.dev

CVE-2026-58494 RUSTSEC-2026-0188 GHSA-4ch3-9j33-3pmj Jun 24, 2026

WASI hard links and renames bypass wasmtime-wasi's FilePerms for destination

6.5 / 10

Medium

Local Low Low None Changed None High None

This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-4ch3-9j33-3pmj For more information see the GitHub-hosted security advisory.

Fixed in


          24.0.11


          36.0.12


          45.0.3


          46.0.1

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-47261 GHSA-2r75-cxrj-cmph RUSTSEC-2026-0149 Jun 05, 2026

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

7.5 / 10

High

Network Low None None Unchanged None High None

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.

Fixed in


          24.0.9


          36.0.10


          44.0.2

References

Updated Sep 10, 2026 · Source: OSV.dev

Feb 24, 2026

41.0.3 patch

3 CVEs

CVE-2026-54786 GHSA-3p27-qvp9-27qf RUSTSEC-2026-0182 Aug 26, 2026

Wasmtime has a leak in WASIp1 `fd_renumber` implementation

Low

Network Low Low None

Impact

Wasmtime's native implementation of WASIp1 suffers from a leak in the fd_renumber function where the file descriptor being renumbered to is not properly closed. Wasmtime's implementation erroneously only updated the table of descriptors for WASIp1 and didn't update the underlying table of descriptors used by the host. This behavior means that while fd_renumber works correctly from a guest's perspective it ends up leaking resources in the host that aren't cleaned up until the corresponding Store is destroyed. This means that guests can, in a loop, use fd_renumber to cause hosts to exhaust resources or exhaust file descriptors.

This bug only affects the native implementation of WASIp1. This means that only runtimes which load core wasm modules and expose fd_renumber are affected. Runtimes are additionally only affected if they expose the ability to acquire a file descriptor, such as opening a file. For runtimes that deny access to files they are unaffected.

Patches

Wasmtime 24.0.10, 36.0.11, 44.0.3, and 45.0.2 have been released which fix this issue.

Workarounds

There are no workarounds for this issue and hosts are recommended to update.

Fixed in


          24.0.10


          36.0.11


          44.0.3


          45.0.2

References

Updated Aug 26, 2026 · Source: OSV.dev

CVE-2026-58494 RUSTSEC-2026-0188 GHSA-4ch3-9j33-3pmj Jun 24, 2026

WASI hard links and renames bypass wasmtime-wasi's FilePerms for destination

6.5 / 10

Medium

Local Low Low None Changed None High None

This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-4ch3-9j33-3pmj For more information see the GitHub-hosted security advisory.

Fixed in


          24.0.11


          36.0.12


          45.0.3


          46.0.1

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-47261 GHSA-2r75-cxrj-cmph RUSTSEC-2026-0149 Jun 05, 2026

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

7.5 / 10

High

Network Low None None Unchanged None High None

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.

Fixed in


          24.0.9


          36.0.10


          44.0.2

References

Updated Sep 10, 2026 · Source: OSV.dev

Feb 04, 2026

41.0.2 patch

3 CVEs

CVE-2026-54786 GHSA-3p27-qvp9-27qf RUSTSEC-2026-0182 Aug 26, 2026

Wasmtime has a leak in WASIp1 `fd_renumber` implementation

Low

Network Low Low None

Impact

Wasmtime's native implementation of WASIp1 suffers from a leak in the fd_renumber function where the file descriptor being renumbered to is not properly closed. Wasmtime's implementation erroneously only updated the table of descriptors for WASIp1 and didn't update the underlying table of descriptors used by the host. This behavior means that while fd_renumber works correctly from a guest's perspective it ends up leaking resources in the host that aren't cleaned up until the corresponding Store is destroyed. This means that guests can, in a loop, use fd_renumber to cause hosts to exhaust resources or exhaust file descriptors.

This bug only affects the native implementation of WASIp1. This means that only runtimes which load core wasm modules and expose fd_renumber are affected. Runtimes are additionally only affected if they expose the ability to acquire a file descriptor, such as opening a file. For runtimes that deny access to files they are unaffected.

Patches

Wasmtime 24.0.10, 36.0.11, 44.0.3, and 45.0.2 have been released which fix this issue.

Workarounds

There are no workarounds for this issue and hosts are recommended to update.

Fixed in


          24.0.10


          36.0.11


          44.0.3


          45.0.2

References

Updated Aug 26, 2026 · Source: OSV.dev

CVE-2026-58494 RUSTSEC-2026-0188 GHSA-4ch3-9j33-3pmj Jun 24, 2026

WASI hard links and renames bypass wasmtime-wasi's FilePerms for destination

6.5 / 10

Medium

Local Low Low None Changed None High None

This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-4ch3-9j33-3pmj For more information see the GitHub-hosted security advisory.

Fixed in


          24.0.11


          36.0.12


          45.0.3


          46.0.1

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-47261 GHSA-2r75-cxrj-cmph RUSTSEC-2026-0149 Jun 05, 2026

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

7.5 / 10

High

Network Low None None Unchanged None High None

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.

Fixed in


          24.0.9


          36.0.10


          44.0.2

References

Updated Sep 10, 2026 · Source: OSV.dev

Feb 03, 2026

40.0.3 patch

3 CVEs

CVE-2026-54786 GHSA-3p27-qvp9-27qf RUSTSEC-2026-0182 Aug 26, 2026

Wasmtime has a leak in WASIp1 `fd_renumber` implementation

Low

Network Low Low None

Impact

Wasmtime's native implementation of WASIp1 suffers from a leak in the fd_renumber function where the file descriptor being renumbered to is not properly closed. Wasmtime's implementation erroneously only updated the table of descriptors for WASIp1 and didn't update the underlying table of descriptors used by the host. This behavior means that while fd_renumber works correctly from a guest's perspective it ends up leaking resources in the host that aren't cleaned up until the corresponding Store is destroyed. This means that guests can, in a loop, use fd_renumber to cause hosts to exhaust resources or exhaust file descriptors.

This bug only affects the native implementation of WASIp1. This means that only runtimes which load core wasm modules and expose fd_renumber are affected. Runtimes are additionally only affected if they expose the ability to acquire a file descriptor, such as opening a file. For runtimes that deny access to files they are unaffected.

Patches

Wasmtime 24.0.10, 36.0.11, 44.0.3, and 45.0.2 have been released which fix this issue.

Workarounds

There are no workarounds for this issue and hosts are recommended to update.

Fixed in


          24.0.10


          36.0.11


          44.0.3


          45.0.2

References

Updated Aug 26, 2026 · Source: OSV.dev

CVE-2026-58494 RUSTSEC-2026-0188 GHSA-4ch3-9j33-3pmj Jun 24, 2026

WASI hard links and renames bypass wasmtime-wasi's FilePerms for destination

6.5 / 10

Medium

Local Low Low None Changed None High None

This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-4ch3-9j33-3pmj For more information see the GitHub-hosted security advisory.

Fixed in


          24.0.11


          36.0.12


          45.0.3


          46.0.1

References

Updated Jul 13, 2026 · Source: OSV.dev

CVE-2026-47261 GHSA-2r75-cxrj-cmph RUSTSEC-2026-0149 Jun 05, 2026

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

7.5 / 10

High

Network Low None None Unchanged None High None

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.

Fixed in


          24.0.9


          36.0.10


          44.0.2

References

Updated Sep 10, 2026 · Source: OSV.dev

Jan 27, 2026

Activity

Reach

Details