{"id":"CVE-2026-34946","aliases":["DEBIAN-CVE-2026-34946","EUVD-2026-21025","GHSA-q49f-xg75-m9xw","JLSEC-2026-1359","RUSTSEC-2026-0089","SUSE-SU-2026:21789-1","UBUNTU-CVE-2026-34946","openSUSE-SU-2026:20749-1"],"status":"published","title":"Wasmtime's host panics when Winch compiler executes `table.fill`","description":"Wasmtime is a runtime for WebAssembly. From 25.0.0 to before 36.0.7, 42.0.2, and 43.0.1, Wasmtime's Winch compiler contains a vulnerability where the compilation of the table.fill instruction can result in a host panic. This means that a valid guest can be compiled with Winch, on any architecture, and cause the host to panic. This represents a denial-of-service vulnerability in Wasmtime due to guests being able to trigger a panic. The specific issue is that a historical refactoring changed how compiled code referenced tables within the table.* instructions. This refactoring forgot to update the Winch code paths associated as well, meaning that Winch was using the wrong indexing scheme. Due to the feature support of Winch the only problem that can result is tables being mixed up or nonexistent tables being used, meaning that the guest is limited to panicking the host (using a nonexistent table), or executing spec-incorrect behavior and modifying the wrong table. This vulnerability is fixed in 36.0.7, 42.0.2, and 43.0.1.","severity":{"version":"4.0","score":5.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-10","score":0.00372,"percentile":0.31402,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-248","CWE-670"],"published":"2026-04-09T12:00:00Z","modified":"2026-10-28T02:30:53Z","fixes":[{"ecosystem":"crates.io","package":"wasmtime","fixed_in":["36.0.7","42.0.2","43.0.1"],"sources":["ghsa","osv"]},{"ecosystem":"Debian:14","package":"rust-wasmtime","fixed_in":["36.0.7+dfsg-1"],"sources":["osv"]},{"ecosystem":"Julia","package":"Wasmtime_jll","fixed_in":["45.0.1+0"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"crates.io","package":"wasmtime","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"25.0.0"},{"fixed":"36.0.7"}]}]},{"source":"ghsa","ecosystem":"crates.io","package":"wasmtime","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"37.0.0"},{"fixed":"42.0.2"}]}]},{"source":"ghsa","ecosystem":"crates.io","package":"wasmtime","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"43.0.0"},{"last_affected":"43.0.0"},{"fixed":"43.0.1"}]}],"versions":["43.0.0"]},{"source":"osv","ecosystem":"Debian:13","package":"rust-wasmtime","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["26.0.1+dfsg-10","26.0.1+dfsg-3","26.0.1+dfsg-4","26.0.1+dfsg-5","26.0.1+dfsg-6","26.0.1+dfsg-7","26.0.1+dfsg-8","26.0.1+dfsg-9","27.0.0+dfsg-2","27.0.0+dfsg-3","27.0.0+dfsg-4","28.0.1+dfsg-1","28.0.1+dfsg-2","28.0.1+dfsg-3","29.0.1+dfsg-1","29.0.1+dfsg-2","29.0.1+dfsg-3","29.0.1+dfsg-4","29.0.1+dfsg-5","29.0.1+dfsg-6","29.0.1+dfsg-7","29.0.1+dfsg-8","36.0.11+dfsg-1","36.0.12+dfsg-1","36.0.12+dfsg-2","36.0.12+dfsg-3","36.0.13+dfsg-1","36.0.5+dfsg-1","36.0.5+dfsg-2","36.0.5+dfsg-3","36.0.5+dfsg-4","36.0.5+dfsg-5","36.0.6+dfsg-1","36.0.6+dfsg-2","36.0.6+dfsg-3","36.0.6+dfsg-4","36.0.6+dfsg-5","36.0.6+dfsg-6","36.0.6+dfsg-7","36.0.7+dfsg-1","36.0.8+dfsg-1","36.0.9+dfsg-1","36.0.9+dfsg-2"]},{"source":"osv","ecosystem":"Debian:14","package":"rust-wasmtime","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"36.0.7+dfsg-1"}]}],"versions":["26.0.1+dfsg-10","26.0.1+dfsg-3","26.0.1+dfsg-4","26.0.1+dfsg-5","26.0.1+dfsg-6","26.0.1+dfsg-7","26.0.1+dfsg-8","26.0.1+dfsg-9","27.0.0+dfsg-2","27.0.0+dfsg-3","27.0.0+dfsg-4","28.0.1+dfsg-1","28.0.1+dfsg-2","28.0.1+dfsg-3","29.0.1+dfsg-1","29.0.1+dfsg-2","29.0.1+dfsg-3","29.0.1+dfsg-4","29.0.1+dfsg-5","29.0.1+dfsg-6","29.0.1+dfsg-7","29.0.1+dfsg-8","36.0.5+dfsg-1","36.0.5+dfsg-2","36.0.5+dfsg-3","36.0.5+dfsg-4","36.0.5+dfsg-5","36.0.6+dfsg-1","36.0.6+dfsg-2","36.0.6+dfsg-3","36.0.6+dfsg-4","36.0.6+dfsg-5","36.0.6+dfsg-6","36.0.6+dfsg-7"]},{"source":"osv","ecosystem":"crates.io","package":"wasmtime","ranges":[{"type":"SEMVER","events":[{"introduced":"25.0.0"},{"fixed":"36.0.7"}]}]},{"source":"osv","ecosystem":"crates.io","package":"wasmtime","ranges":[{"type":"SEMVER","events":[{"introduced":"37.0.0"},{"fixed":"42.0.2"}]}]},{"source":"osv","ecosystem":"crates.io","package":"wasmtime","ranges":[{"type":"SEMVER","events":[{"introduced":"43.0.0"},{"fixed":"43.0.1"}]}],"versions":["43.0.0"]},{"source":"osv","ecosystem":"Julia","package":"Wasmtime_jll","ranges":[{"type":"SEMVER","events":[{"introduced":"39.0.0+0"},{"fixed":"45.0.1+0"}]}]},{"source":"osv","ecosystem":"crates.io","package":"wasmtime","ranges":[{"type":"SEMVER","events":[{"introduced":"0.0.0-0"},{"fixed":"36.0.7"},{"introduced":"37.0.0"},{"fixed":"42.0.2"},{"introduced":"43.0.0"},{"fixed":"43.0.1"}]}]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"rust-wasmtime","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["10.0.1+dfsg-7","15.0.1+dfsg-4","16.0.0+dfsg-2","16.0.0+dfsg-3"]},{"source":"osv","ecosystem":"Ubuntu:25.10","package":"rust-wasmtime","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["26.0.1+dfsg-3"]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"rust-wasmtime","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["36.0.5+dfsg-1","36.0.13+dfsg-1"]},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"rust-wasmtime","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["26.0.1+dfsg-3","26.0.1+dfsg-4","28.0.1+dfsg-3","29.0.1+dfsg-5","36.0.5+dfsg-1"]}],"products":[{"vendor":"bytecodealliance","product":"wasmtime"}],"references":[{"url":"https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-q49f-xg75-m9xw","tags":["x_refsource_CONFIRM","Vendor Advisory","advisory","web","report"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-34946","tags":["advisory","web"]},{"url":"https://rustsec.org/advisories/RUSTSEC-2026-0089.html","tags":["web","advisory"]},{"url":"https://github.com/advisories/GHSA-q49f-xg75-m9xw","tags":["web"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/34xxx/CVE-2026-34946.json","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2026-34946","tags":["advisory"]},{"url":"https://github.com/bytecodealliance/wasmtime","tags":["package"]},{"url":"https://crates.io/crates/wasmtime","tags":["package"]},{"url":"https://github.com/bytecodealliance/wasmtime/pull/13010","tags":["web"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-202621789-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1259205","tags":["report"]},{"url":"https://bugzilla.suse.com/1261839","tags":["report"]},{"url":"https://bugzilla.suse.com/1261871","tags":["report"]},{"url":"https://bugzilla.suse.com/1261894","tags":["report"]},{"url":"https://bugzilla.suse.com/1261954","tags":["report"]},{"url":"https://bugzilla.suse.com/1261963","tags":["report"]},{"url":"https://bugzilla.suse.com/1261968","tags":["report"]},{"url":"https://bugzilla.suse.com/1261974","tags":["report"]},{"url":"https://bugzilla.suse.com/1262007","tags":["report"]},{"url":"https://bugzilla.suse.com/1262032","tags":["report"]},{"url":"https://bugzilla.suse.com/1262036","tags":["report"]},{"url":"https://bugzilla.suse.com/1262040","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34941","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34942","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34943","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34944","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34945","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34946","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34987","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34988","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-35186","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-35195","tags":["web"]},{"url":"https://ubuntu.com/security/CVE-2026-34946","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-34946","tags":["report"]},{"url":"","tags":["advisory"]}],"sources":{"cve":[{"id":"CVE-2026-34946","title":"Wasmtime's host panics when Winch compiler executes `table.fill`","description":"Wasmtime is a runtime for WebAssembly. From 25.0.0 to before 36.0.7, 42.0.2, and 43.0.1, Wasmtime's Winch compiler contains a vulnerability where the compilation of the table.fill instruction can result in a host panic. This means that a valid guest can be compiled with Winch, on any architecture, and cause the host to panic. This represents a denial-of-service vulnerability in Wasmtime due to guests being able to trigger a panic. The specific issue is that a historical refactoring changed how compiled code referenced tables within the table.* instructions. This refactoring forgot to update the Winch code paths associated as well, meaning that Winch was using the wrong indexing scheme. Due to the feature support of Winch the only problem that can result is tables being mixed up or nonexistent tables being used, meaning that the guest is limited to panicking the host (using a nonexistent table), or executing spec-incorrect behavior and modifying the wrong table. This vulnerability is fixed in 36.0.7, 42.0.2, and 43.0.1.","status":"published","published":"2026-04-09T18:43:39.137Z","modified":"2026-04-09T19:33:33.709Z","cvss":[{"version":"4.0","score":5.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"medium","assessor":"cna"}],"cwes":["CWE-670"],"updated_at":"2026-11-02T14:20:14.302133Z"}],"euvd":[{"id":"EUVD-2026-21025","description":"Wasmtime is a runtime for WebAssembly. From 25.0.0 to before 36.0.7, 42.0.2, and 43.0.1, Wasmtime's Winch compiler contains a vulnerability where the compilation of the table.fill instruction can result in a host panic. This means that a valid guest can be compiled with Winch, on any architecture, and cause the host to panic. This represents a denial-of-service vulnerability in Wasmtime due to guests being able to trigger a panic. The specific issue is that a historical refactoring changed how compiled code referenced tables within the table.* instructions. This refactoring forgot to update the Winch code paths associated as well, meaning that Winch was using the wrong indexing scheme. Due to the feature support of Winch the only problem that can result is tables being mixed up or nonexistent tables being used, meaning that the guest is limited to panicking the host (using a nonexistent table), or executing spec-incorrect behavior and modifying the wrong table. This vulnerability is fixed in 36.0.7, 42.0.2, and 43.0.1.","status":"published","published":"2026-04-09T18:43:39Z","modified":"2026-04-09T19:33:33Z","cvss":[{"version":"4.0","score":5.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"medium"}],"updated_at":"2026-11-02T19:24:30.341772Z"}],"ghsa":[{"id":"GHSA-q49f-xg75-m9xw","title":"Wasmtime has host panic when Winch compiler executes `table.fill`","description":"### Impact\n\nWasmtime's Winch compiler contains a vulnerability where the compilation of the `table.fill` instruction can result in a host panic. This means that a valid guest can be compiled with Winch, on any architecture, and cause the host to panic. This represents a denial-of-service vulnerability in Wasmtime due to guests being able to trigger a panic.\n\nThe specific issue is that a historical refactoring, #11254, changed how compiled code referenced tables within the `table.*` instructions. This refactoring forgot to update the Winch code paths associated as well, meaning that Winch was using the wrong indexing scheme. Due to the feature support of Winch the only problem that can result is tables being mixed up or nonexistent tables being used, meaning that the guest is limited to panicking the host (using a nonexistent table), or executing spec-incorrect behavior and modifying the wrong table.\n\n### Patches\n\nWasmtime 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this bug. Users are recommended to update to these patched versions of Wasmtime.\n\n### Workarounds\n\nUsers of Cranelift are not affected by this issue, but for users of Winch there is no workaround for this bug. Hosts are recommended to updated to a patched version of Wasmtime.","status":"published","published":"2026-04-09T20:23:21Z","modified":"2026-04-24T21:03:27Z","cvss":[{"version":"4.0","score":5.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"medium"},{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"cwes":["CWE-248","CWE-670"],"updated_at":"2026-11-02T14:39:57.650091Z"}],"nvd":[{"id":"CVE-2026-34946","description":"Wasmtime is a runtime for WebAssembly. From 25.0.0 to before 36.0.7, 42.0.2, and 43.0.1, Wasmtime's Winch compiler contains a vulnerability where the compilation of the table.fill instruction can result in a host panic. This means that a valid guest can be compiled with Winch, on any architecture, and cause the host to panic. This represents a denial-of-service vulnerability in Wasmtime due to guests being able to trigger a panic. The specific issue is that a historical refactoring changed how compiled code referenced tables within the table.* instructions. This refactoring forgot to update the Winch code paths associated as well, meaning that Winch was using the wrong indexing scheme. Due to the feature support of Winch the only problem that can result is tables being mixed up or nonexistent tables being used, meaning that the guest is limited to panicking the host (using a nonexistent table), or executing spec-incorrect behavior and modifying the wrong table. This vulnerability is fixed in 36.0.7, 42.0.2, and 43.0.1.","status":"published","published":"2026-04-09T19:16:24.49Z","modified":"2026-10-26T22:10:00.163Z","cvss":[{"version":"4.0","score":5.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"medium","assessor":"secondary"},{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high","assessor":"primary"}],"cwes":["CWE-670"],"updated_at":"2026-11-02T14:12:13.902911Z"}],"osv":[{"id":"CVE-2026-34946","title":"Wasmtime's host panics when Winch compiler executes `table.fill`","description":"Wasmtime is a runtime for WebAssembly. From 25.0.0 to before 36.0.7, 42.0.2, and 43.0.1, Wasmtime's Winch compiler contains a vulnerability where the compilation of the table.fill instruction can result in a host panic. This means that a valid guest can be compiled with Winch, on any architecture, and cause the host to panic. This represents a denial-of-service vulnerability in Wasmtime due to guests being able to trigger a panic. The specific issue is that a historical refactoring changed how compiled code referenced tables within the table.* instructions. This refactoring forgot to update the Winch code paths associated as well, meaning that Winch was using the wrong indexing scheme. Due to the feature support of Winch the only problem that can result is tables being mixed up or nonexistent tables being used, meaning that the guest is limited to panicking the host (using a nonexistent table), or executing spec-incorrect behavior and modifying the wrong table. This vulnerability is fixed in 36.0.7, 42.0.2, and 43.0.1.","status":"published","published":"2026-04-09T18:43:39.137Z","modified":"2026-10-28T02:30:53.967798173Z","cvss":[{"version":"4.0","score":5.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"medium"}],"cwes":["CWE-670"],"updated_at":"2026-11-02T15:45:02.673625Z"},{"id":"DEBIAN-CVE-2026-34946","description":"Wasmtime is a runtime for WebAssembly. From 25.0.0 to before 36.0.7, 42.0.2, and 43.0.1, Wasmtime's Winch compiler contains a vulnerability where the compilation of the table.fill instruction can result in a host panic. This means that a valid guest can be compiled with Winch, on any architecture, and cause the host to panic. This represents a denial-of-service vulnerability in Wasmtime due to guests being able to trigger a panic. The specific issue is that a historical refactoring changed how compiled code referenced tables within the table.* instructions. This refactoring forgot to update the Winch code paths associated as well, meaning that Winch was using the wrong indexing scheme. Due to the feature support of Winch the only problem that can result is tables being mixed up or nonexistent tables being used, meaning that the guest is limited to panicking the host (using a nonexistent table), or executing spec-incorrect behavior and modifying the wrong table. This vulnerability is fixed in 36.0.7, 42.0.2, and 43.0.1.","status":"published","published":"2026-04-09T19:16:24.49Z","modified":"2026-10-27T09:47:38.031908539Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"updated_at":"2026-11-02T15:45:54.587575Z"},{"id":"GHSA-q49f-xg75-m9xw","title":"Wasmtime has host panic when Winch compiler executes `table.fill`","description":"### Impact\n\nWasmtime's Winch compiler contains a vulnerability where the compilation of the `table.fill` instruction can result in a host panic. This means that a valid guest can be compiled with Winch, on any architecture, and cause the host to panic. This represents a denial-of-service vulnerability in Wasmtime due to guests being able to trigger a panic.\n\nThe specific issue is that a historical refactoring, #11254, changed how compiled code referenced tables within the `table.*` instructions. This refactoring forgot to update the Winch code paths associated as well, meaning that Winch was using the wrong indexing scheme. Due to the feature support of Winch the only problem that can result is tables being mixed up or nonexistent tables being used, meaning that the guest is limited to panicking the host (using a nonexistent table), or executing spec-incorrect behavior and modifying the wrong table.\n\n### Patches\n\nWasmtime 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this bug. Users are recommended to update to these patched versions of Wasmtime.\n\n### Workarounds\n\nUsers of Cranelift are not affected by this issue, but for users of Winch there is no workaround for this bug. Hosts are recommended to updated to a patched version of Wasmtime.","status":"published","published":"2026-04-09T20:23:21Z","modified":"2026-09-10T03:51:02.711372857Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"},{"version":"4.0","score":5.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"medium"}],"cwes":["CWE-248","CWE-670"],"updated_at":"2026-11-02T15:46:54.055966Z"},{"id":"JLSEC-2026-1359","title":"Wasmtime has host panic when Winch compiler executes `table.fill`","description":"### Impact\n\nWasmtime's Winch compiler contains a vulnerability where the compilation of the `table.fill` instruction can result in a host panic. This means that a valid guest can be compiled with Winch, on any architecture, and cause the host to panic. This represents a denial-of-service vulnerability in Wasmtime due to guests being able to trigger a panic.\n\nThe specific issue is that a historical refactoring, #11254, changed how compiled code referenced tables within the `table.*` instructions. This refactoring forgot to update the Winch code paths associated as well, meaning that Winch was using the wrong indexing scheme. Due to the feature support of Winch the only problem that can result is tables being mixed up or nonexistent tables being used, meaning that the guest is limited to panicking the host (using a nonexistent table), or executing spec-incorrect behavior and modifying the wrong table.\n\n### Patches\n\nWasmtime 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this bug. Users are recommended to update to these patched versions of Wasmtime.\n\n### Workarounds\n\nUsers of Cranelift are not affected by this issue, but for users of Winch there is no workaround for this bug. Hosts are recommended to updated to a patched version of Wasmtime.","status":"published","published":"2026-08-21T20:43:33.133Z","modified":"2026-08-21T21:14:22.345730658Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"},{"version":"4.0","score":5.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"medium"}],"updated_at":"2026-11-02T15:47:18.159338Z"},{"id":"RUSTSEC-2026-0089","title":"Host panic when Winch compiler executes `table.fill`","description":"This is an entry in the RustSec database for the Wasmtime security advisory\nlocated at\nhttps://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-q49f-xg75-m9xw\nFor more information see the GitHub-hosted security advisory.","status":"published","published":"2026-04-09T12:00:00Z","modified":"2026-10-12T18:00:13.553340442Z","cvss":[{"version":"4.0","score":5.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"medium"}],"updated_at":"2026-11-02T15:53:40.430679Z"},{"id":"UBUNTU-CVE-2026-34946","description":"Wasmtime is a runtime for WebAssembly. From 25.0.0 to before 36.0.7, 42.0.2, and 43.0.1, Wasmtime's Winch compiler contains a vulnerability where the compilation of the table.fill instruction can result in a host panic. This means that a valid guest can be compiled with Winch, on any architecture, and cause the host to panic. This represents a denial-of-service vulnerability in Wasmtime due to guests being able to trigger a panic. The specific issue is that a historical refactoring changed how compiled code referenced tables within the table.* instructions. This refactoring forgot to update the Winch code paths associated as well, meaning that Winch was using the wrong indexing scheme. Due to the feature support of Winch the only problem that can result is tables being mixed up or nonexistent tables being used, meaning that the guest is limited to panicking the host (using a nonexistent table), or executing spec-incorrect behavior and modifying the wrong table. This vulnerability is fixed in 36.0.7, 42.0.2, and 43.0.1.","status":"published","published":"2026-04-09T19:16:00Z","modified":"2026-10-17T13:00:02.911513779Z","cvss":[{"version":"4.0","score":5.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"medium"},{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"updated_at":"2026-11-02T16:56:16.036833Z"},{"id":"openSUSE-SU-2026:20749-1","title":"Security update for tree-sitter","description":"This update for tree-sitter fixes the following issues\n\nSecurity issues:\n\n- CVE-2026-34941: wasmtime: crafted input string can lead to an out-of-bound read (bsc#1261871).\n- CVE-2026-34942: wasmtime: unaligned pointers can lead to a denial of service (bsc#1261894).\n- CVE-2026-34943: wasmtime: lifting `flags` component value can lead to a denial of service (bsc#1261954).\n- CVE-2026-34944: wasmtime: out-of-bounds read during WebAssembly compilation can lead to a denial of service\n  (bsc#1261963).\n- CVE-2026-34945: wasmtime: incorrectly translated table.size could lead to disclosing data (bsc#1262007).\n- CVE-2026-34946: wasmtime: denial of service due to WebAssembly compilation error (bsc#1261974).\n- CVE-2026-34987: wasmtime: winch compiler backend may allow a sandbox-escaping memory access (bsc#1262032).\n- CVE-2026-34988: wasmtime: pooling allocator instances can cause data leakage (bsc#1261968).\n- CVE-2026-35186: wasmtime: translating the table.grow operator can cause a masked return value (bsc#1262036).\n- CVE-2026-35195: wasmtime: transcoding strings can lead to an out of bound write or a crash (bsc#1262040).\n\nChanges for tree-sitter:\n\n- update to 0.26.8:\n\n * fix(generate): allow disabling qjs-rt feature from CLI by @WillLillis in\n #5448\n * fix(lib): document invariants that must be upheld for TSInputEdit by\n @WillLillis in #5452\n * fix(cli): correct typo in parse command's help text by @WillLillis in #5465\n * perf(cli): misc. improvements by @tree-sitter-ci-bot[bot] in #5476\n * Fix wasm loading of languages w/ multiple reserved word sets by\n @tree-sitter-ci-bot[bot] in #5477\n * generate: avoid panicking when a supertype only has hidden external token\n children by @tree-sitter-ci-bot[bot] in #5478\n","status":"published","published":"2026-05-14T08:07:53Z","modified":"2026-05-19T18:23:48.124613698Z","updated_at":"2026-11-02T16:58:41.463445Z"},{"id":"SUSE-SU-2026:21789-1","title":"Security update for tree-sitter","description":"This update for tree-sitter fixes the following issues\n\nSecurity issues:\n\n- CVE-2026-34941: wasmtime: crafted input string can lead to an out-of-bound read (bsc#1261871).\n- CVE-2026-34942: wasmtime: unaligned pointers can lead to a denial of service (bsc#1261894).\n- CVE-2026-34943: wasmtime: lifting `flags` component value can lead to a denial of service (bsc#1261954).\n- CVE-2026-34944: wasmtime: out-of-bounds read during WebAssembly compilation can lead to a denial of service\n  (bsc#1261963).\n- CVE-2026-34945: wasmtime: incorrectly translated table.size could lead to disclosing data (bsc#1262007).\n- CVE-2026-34946: wasmtime: denial of service due to WebAssembly compilation error (bsc#1261974).\n- CVE-2026-34987: wasmtime: winch compiler backend may allow a sandbox-escaping memory access (bsc#1262032).\n- CVE-2026-34988: wasmtime: pooling allocator instances can cause data leakage (bsc#1261968).\n- CVE-2026-35186: wasmtime: translating the table.grow operator can cause a masked return value (bsc#1262036).\n- CVE-2026-35195: wasmtime: transcoding strings can lead to an out of bound write or a crash (bsc#1262040).\n\nChanges for tree-sitter:\n\n- update to 0.26.8:\n\n * fix(generate): allow disabling qjs-rt feature from CLI by @WillLillis in\n #5448\n * fix(lib): document invariants that must be upheld for TSInputEdit by\n @WillLillis in #5452\n * fix(cli): correct typo in parse command's help text by @WillLillis in #5465\n * perf(cli): misc. improvements by @tree-sitter-ci-bot[bot] in #5476\n * Fix wasm loading of languages w/ multiple reserved word sets by\n @tree-sitter-ci-bot[bot] in #5477\n * generate: avoid panicking when a supertype only has hidden external token\n children by @tree-sitter-ci-bot[bot] in #5478\n","status":"published","published":"2026-05-14T08:09:11Z","modified":"2026-05-28T18:24:08.686123956Z","updated_at":"2026-11-02T15:54:02.654057Z"}]}}