Wasmtime: WASI path_open(TRUNCATE) bypasses `FilePerms::WRITE` host restriction
Wasmtime is a runtime for WebAssembly. In versions prior to 24.0.9, 36.0.10, and 44.0.2, when a filesystem preopen is given DirPerms::all() and FilePerms::READ without FilePerms::WRITE, this access control mechanism can be bypassed via the wasip2 descriptor.open-at or wasip1 path_open interfaces by opening a file with only the OpenFlags::TRUNCATE oflag. The root cause is that the clause handling OpenFlags::TRUNCATE in crates/wasi/src/filesystem.rs (Dir::open_at, lines 967–969) did not set open_mode |= OpenMode::WRITE;, which is later used for the access control check against FilePerms to determine whether opening the file is permitted; the single-line fix adds that missing assignment, after which the affected calls correctly fail with error-code.not-permitted and ERRNO_PERM respectively. Only wasmtime-wasi embeddings that combine DirPerms::MUTATE with FilePerms::READ are affected by this bug. 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. This issue has been fixed in versions 24.0.9, 36.0.10 and44.0.2.
- Products
- Not specified
- Affected versions
- Not specified
- Fixed versions
- Not specified
- CVEs
- CVE-2026-47261
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 3 Nov 2026, 11:30 UTC · Revision 1
Source evidence
Wasmtime: WASI path_open(TRUNCATE) bypasses `FilePerms::WRITE` host restriction
core-osv · Original sourcePublished 15 Jun 2026, 19:47 UTC
Wasmtime is a runtime for WebAssembly. In versions prior to 24.0.9, 36.0.10, and 44.0.2, when a filesystem preopen is given DirPerms::all() and FilePerms::READ without FilePerms::WRITE, this access control mechanism can be bypassed via the wasip2 descriptor.open-at or wasip1 path_open interfaces by opening a file with only the OpenFlags::TRUNCATE oflag. The root cause is that the clause handling OpenFlags::TRUNCATE in crates/wasi/src/filesystem.rs (Dir::open_at, lines 967–969) did not set open_mode |= OpenMode::WRITE;, which is later used for the access control check against FilePerms to determine whether opening the file is permitted; the single-line fix adds that missing assignment, after which the affected calls correctly fail with error-code.not-permitted and ERRNO_PERM respectively. Only wasmtime-wasi embeddings that combine DirPerms::MUTATE with FilePerms::READ are affected by this bug. 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. This issue has been fixed in versions 24.0.9, 36.0.10 and44.0.2.
osv:CVE-2026-47261
Complete source record
{
"id": "d54989add0243d27f28d084c63456ce1845ddda466c745b3136bb5500b5a71a2",
"url": "https://osv.dev/vulnerability/CVE-2026-47261",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "Wasmtime: WASI path_open(TRUNCATE) bypasses `FilePerms::WRITE` host restriction",
"summary": "Wasmtime is a runtime for WebAssembly. In versions prior to 24.0.9, 36.0.10, and 44.0.2, when a filesystem preopen is given DirPerms::all() and FilePerms::READ without FilePerms::WRITE, this access control mechanism can be bypassed via the wasip2 descriptor.open-at or wasip1 path_open interfaces by opening a file with only the OpenFlags::TRUNCATE oflag. The root cause is that the clause handling OpenFlags::TRUNCATE in crates/wasi/src/filesystem.rs (Dir::open_at, lines 967–969) did not set open_mode |= OpenMode::WRITE;, which is later used for the access control check against FilePerms to determine whether opening the file is permitted; the single-line fix adds that missing assignment, after which the affected calls correctly fail with error-code.not-permitted and ERRNO_PERM respectively. Only wasmtime-wasi embeddings that combine DirPerms::MUTATE with FilePerms::READ are affected by this bug. 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. This issue has been fixed in versions 24.0.9, 36.0.10 and44.0.2.",
"evidence": "osv:CVE-2026-47261",
"products": [],
"severity": "high",
"structured": {
"id": "CVE-2026-47261",
"aliases": [
"CVE-2026-47261",
"GHSA-2r75-cxrj-cmph",
"RUSTSEC-2026-0149"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://github.com/bytecodealliance/wasmtime",
"type": "GIT",
"events": [
{
"introduced": "0"
},
{
"fixed": "97ebe818494ff0555e5a686af40342cacb896752"
},
{
"introduced": "0b195ef5db76c02fb5392ec1418c58bdc5537d41"
},
{
"fixed": "1f63867b4c09de72c740282f21c9cd91ac54eb83"
},
{
"introduced": "7b3d6ae79e9153a2477668062f5622c10333925f"
},
{
"fixed": "d02210b714962f2c66891a8ee9d5d034bfb626f1"
},
{
"fixed": "377cd917af258d932d55b201a646917ecf193639"
}
],
"database_specific": {
"extracted_events": [
{
"cpe": "cpe:2.3:a:bytecodealliance:wasmtime:*:*:*:*:*:rust:*:*",
"range": [
{
"introduced": "0"
},
{
"fixed": "24.0.9"
}
],
"source": "CPE_RANGE"
},
{
"cpe": "cpe:2.3:a:bytecodealliance:wasmtime:*:*:*:*:*:rust:*:*",
"range": [
{
"introduced": "25.0.0"
},
{
"fixed": "36.0.10"
}
],
"source": "CPE_RANGE"
},
{
"cpe": "cpe:2.3:a:bytecodealliance:wasmtime:*:*:*:*:*:rust:*:*",
"range": [
{
"introduced": "37.0.0"
},
{
"fixed": "44.0.2"
}
],
"source": "CPE_RANGE"
},
{
"range": [
{
"fixed": "97ebe818494ff0555e5a686af40342cacb896752"
}
],
"source": "REFERENCES_TAG",
"original_tag": "v24.0.9"
},
{
"range": [
{
"fixed": "1f63867b4c09de72c740282f21c9cd91ac54eb83"
}
],
"source": "REFERENCES_TAG",
"original_tag": "v36.0.10"
},
{
"range": [
{
"fixed": "d02210b714962f2c66891a8ee9d5d034bfb626f1"
}
],
"source": "REFERENCES_TAG",
"original_tag": "v44.0.2"
},
{
"range": [
{
"fixed": "377cd917af258d932d55b201a646917ecf193639"
}
],
"source": "REFERENCES_TAG",
"original_tag": "v45.0.0"
}
]
}
}
],
"versions": [
"v44.0.1",
"v36.0.9",
"v24.0.8",
"v36.0.8",
"v36.0.7",
"v24.0.7",
"v44.0.0",
"v36.0.6",
"v24.0.6",
"v36.0.5",
"dev",
"v36.0.4",
"v24.0.5",
"v36.0.3",
"v36.0.2",
"v24.0.4",
"v36.0.1",
"v36.0.0",
"v24.0.3",
"v24.0.2",
"v24.0.1",
"v24.0.0",
"v0.35.0",
"v0.33.0",
"v0.34.0",
"v0.32.0",
"v0.31.0",
"v0.30.0",
"v0.29.0",
"v0.28.0",
"v0.27.0",
"v0.26.0",
"v0.25.0",
"v0.24.0",
"v0.23.0",
"v0.22.0",
"cranelift-v0.69.0",
"v0.21.0",
"v0.20.0",
"v0.19.0",
"v0.18.0",
"v0.17.0",
"v0.16.0",
"cranelift-v0.61.0",
"cranelift-v0.60.0",
"v0.12.0"
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-47261.json"
}
}
],
"modified": "2026-10-28T02:30:28.146395878Z",
"provider": "osv",
"references": [
"https://github.com/bytecodealliance/wasmtime/releases/tag/v24.0.9",
"https://github.com/bytecodealliance/wasmtime/releases/tag/v36.0.10",
"https://github.com/bytecodealliance/wasmtime/releases/tag/v44.0.2",
"https://github.com/bytecodealliance/wasmtime/releases/tag/v45.0.0",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/47xxx/CVE-2026-47261.json",
"https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-2r75-cxrj-cmph",
"https://nvd.nist.gov/vuln/detail/CVE-2026-47261"
],
"provider_metadata": {
"cwe_ids": [
"CWE-284"
],
"cna_assigner": "GitHub_M",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/47xxx/CVE-2026-47261.json"
}
},
"related_cves": [
{
"value": "CVE-2026-47261",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 494923,
"published_at": "2026-06-15T19:47:40.366+00:00"
}