{"answers":{"affected":"It affects 2 products.","exploited":"There is no known exploitation of CVE-2021-39219 in the wild and no public exploit code.","fix":"Upgrade to a fixed version.","what":"CVE-2021-39219 is a medium-severity memory corruption vulnerability in Fedoraproject Fedora, published on 17 Sep 2021. It can only be exploited from the same machine or local network, and only if a user opens a file or follows a link."},"fix_prompt":"Check this codebase for CVE-2021-39219 and fix it if it is affected.\n\nWhat it is: CVE-2021-39219 is a medium-severity memory corruption vulnerability in Fedoraproject Fedora, published on 17 Sep 2021. It can only be exploited from the same machine or local network, and only if a user opens a file or follows a link.\nExploitation: There is no known exploitation of CVE-2021-39219 in the wild and no public exploit code.\n\nAffected product: Fedoraproject Fedora. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2021-39219/ (Markdown: https://insights.sbomify.com/CVE-2021-39219/index.md)","id":"CVE-2021-39219","markdown":"https://insights.sbomify.com/CVE-2021-39219/index.md","name":"CVE-2021-39219","record":{"aliases":[],"analysis":{"component_type":"library","fix_type":"upgrade","impacts":["code_execution"],"network_reachable":"adjacent_or_local","non_default_config":true,"product_category":"WebAssembly runtime library","requires_auth":"none","summary":"Type confusion in Wasmtime allows memory corruption and potential code execution when using multiple Engine instances with a Linker.","user_interaction":"required","vuln_class":"memory_corruption"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"GitHub_M","cpe":[{"product":"wasmtime","vendor":"bytecodealliance"},{"product":"fedora","vendor":"fedoraproject"}],"cvss":{"score":6.3,"severity":"medium","source":"cna","vector":"CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:H","version":"3.1"},"cwes":[{"id":"CWE-843","name":"Access of Resource Using Incompatible Type"}],"description":"Wasmtime is an open source runtime for WebAssembly \u0026 WASI. Wasmtime before version 0.30.0 is affected by a type confusion vulnerability. As a Rust library the `wasmtime` crate clearly marks which functions are safe and which are `unsafe`, guaranteeing that if consumers never use `unsafe` then it should not be possible to have memory unsafety issues in their embeddings of Wasmtime. An issue was discovered in the safe API of `Linker::func_*` APIs. These APIs were previously not sound when one `Engine` was used to create the `Linker` and then a different `Engine` was used to create a `Store` and then the `Linker` was used to instantiate a module into that `Store`. Cross-`Engine` usage of functions is not supported in Wasmtime and this can result in type confusion of function pointers, resulting in being able to safely call a function with the wrong type. Triggering this bug requires using at least two `Engine` values in an embedding and then additionally using two different values with a `Linker` (one at the creation time of the `Linker` and another when instantiating a module with the `Linker`). It's expected that usage of more-than-one `Engine` in an embedding is relatively rare since an `Engine` is intended to be a globally shared resource, so the expectation is that the impact of this issue is relatively small. The fix implemented is to change this behavior to `panic!()` in Rust instead of silently allowing it. Using different `Engine` instances with a `Linker` is a programmer bug that `wasmtime` catches at runtime. This bug has been patched and users should upgrade to Wasmtime version 0.30.0. If you cannot upgrade Wasmtime and are using more than one `Engine` in your embedding it's recommended to instead use only one `Engine` for the entire program if possible. An `Engine` is designed to be a globally shared resource that is suitable to have only one for the lifetime of an entire process. If using multiple `Engine`s is required then code should be audited to ensure that `Linker` is only used with one `Engine`.","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"Wrong type for `Linker`-define functions when used across two `Engine`s","id":"CVE-2021-39219","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"fedoraproject:fedora","products":["fedoraproject:fedora"],"type":"memory_corruption","year":"2021"},"n_packages":0,"n_references":5,"next":{"headline":"Bypass of image blocking in Nextcloud Mail","id":"CVE-2021-39220"},"packages":[],"prev":{"headline":"Out-of-bounds read/write and invalid free with `externref`s and GC safepoints in Wasmtime","id":"CVE-2021-39218"},"products":["wasmtime"],"published":"2021-09-17","related":[{"cvss_score":9,"headline":"Wasmtime miscompiled guest heap access enables sandbox escape on aarch64 Cranelift","id":"CVE-2026-34971","kev_date_added":null,"published":"2026-04-09"},{"cvss_score":9,"headline":"Wasmtime with Winch compiler backend on aarch64 may allow a sandbox-escaping memory access","id":"CVE-2026-34987","kev_date_added":null,"published":"2026-04-09"},{"cvss_score":8.6,"headline":"Wasmtime vulnerable to data leakage between instances in the pooling allocator","id":"CVE-2022-39393","kev_date_added":null,"published":"2022-11-10"},{"cvss_score":8.1,"headline":"Use after free in Wasmtime","id":"CVE-2022-24791","kev_date_added":null,"published":"2022-03-31"},{"cvss_score":7.5,"headline":"Wasmtime: WASI path_open(TRUNCATE) bypasses `FilePerms::WRITE` host restriction","id":"CVE-2026-47261","kev_date_added":null,"published":"2026-06-15"},{"cvss_score":6.9,"headline":"Wasmtime has a Heap OOB read in component model UTF-16 to latin1+utf16 string transcoding","id":"CVE-2026-34941","kev_date_added":null,"published":"2026-04-09"},{"cvss_score":6.9,"headline":"Wasmtime is vulnerable to panic when dropping a `[Typed]Func::call_async` future","id":"CVE-2026-27195","kev_date_added":null,"published":"2026-02-24"}],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"US public information, NVD API terms","name":"NVD"},{"class":"attribution","licence":"CWE Terms of Use","name":"CWE (MITRE)"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2024-08-04","vendors":["bytecodealliance"]},"summary":"Type confusion in Wasmtime allows memory corruption and potential code execution when using multiple Engine instances with a Linker.","url":"https://insights.sbomify.com/CVE-2021-39219/"}