{"answers":{"affected":"2 open source packages ship an affected version, including evm. It affects 1 product.","exploited":"There is no known exploitation of CVE-2024-21629 in the wild and no public exploit code.","fix":"Upgrade evm to 0.41.1 or later.","what":"CVE-2024-21629 is a medium-severity vulnerability in rust-ethereum evm, published on 2 Jan 2024. An attacker can exploit it over the internet without logging in, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2024-21629 and fix it if it is affected.\n\nWhat it is: CVE-2024-21629 is a medium-severity vulnerability in rust-ethereum evm, published on 2 Jan 2024. An attacker can exploit it over the internet without logging in, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2024-21629 in the wild and no public exploit code.\n\nAffected packages and fixed versions:\n- evm (crates.io): affected all versions; fixed in 0.41.1\n- evm (crates.io): affected all versions; fixed in 0.41.1\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-2024-21629/ (Markdown: https://insights.sbomify.com/CVE-2024-21629/index.md)","id":"CVE-2024-21629","markdown":"https://insights.sbomify.com/CVE-2024-21629/index.md","name":"CVE-2024-21629","record":{"aliases":["GHSA-27wg-99g8-2v4v"],"analysis":{"component_type":"library","fix_type":"patch","impacts":["data_modify"],"network_reachable":"yes","non_default_config":true,"product_category":"Rust EVM interpreter","requires_auth":"none","summary":"Attackers can force state commitments despite failed contract creation if custom error handling is implemented, affecting Rust EVM library users.","user_interaction":"not_required","vuln_class":"business_logic"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"GitHub_M","cpe":[{"product":"evm","vendor":"evm_project"}],"cvss":{"score":5.9,"severity":"medium","source":"cna","vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N","version":"3.1"},"cwes":[{"id":"CWE-703","name":"Improper Check or Handling of Exceptional Conditions"}],"description":"Rust EVM is an Ethereum Virtual Machine interpreter. In `rust-evm`, a feature called `record_external_operation` was introduced, allowing library users to record custom gas changes. This feature can have some bogus interactions with the call stack. In particular, during finalization of a `CREATE` or `CREATE2`, in the case that the substack execution happens successfully, `rust-evm` will first commit the substate, and then call `record_external_operation(Write(out_code.len()))`. If `record_external_operation` later fails, this error is returned to the parent call stack, instead of `Succeeded`. Yet, the substate commitment already happened. This causes smart contracts able to commit state changes, when the parent caller contract receives zero address (which usually indicates that the execution has failed). This issue only impacts library users with custom `record_external_operation` that returns errors. The issue is patched in release 0.41.1. No known workarounds are available.","ecosystems":["crates.io"],"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":"Erroneous handling of `record_external_operation` error return","id":"CVE-2024-21629","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":"crates.io","product":null,"products":[],"type":"business_logic","year":"2024"},"n_packages":2,"n_references":4,"next":{"headline":"Zulip non-admins can invite new users to streams they would not otherwise be able to add existing users to","id":"CVE-2024-21630"},"packages":[{"ecosystem":"crates.io","fixed":["0.41.1"],"introduced":["0"],"last_affected":[],"package":"evm","purl":null,"source":"GHSA-27wg-99g8-2v4v"},{"ecosystem":"crates.io","fixed":["0.41.1"],"introduced":["0"],"last_affected":[],"package":"evm","purl":"pkg:cargo/evm","source":"GHSA-27wg-99g8-2v4v"}],"prev":{"headline":"XSS can be stored in DB from \"add a message form\" in order detail page (FO)","id":"CVE-2024-21628"},"products":["evm"],"published":"2024-01-02","related":[{"cvss_score":8.7,"headline":"Specification non-compliance in JUMPI","id":"CVE-2021-41153","kev_date_added":null,"published":"2021-10-18"},{"cvss_score":6.5,"headline":"Memory over-allocation in evm crate","id":"CVE-2021-29511","kev_date_added":null,"published":"2021-05-12"},{"cvss_score":5.9,"headline":"evm has incorrect is_static parameter for custom stateful precompiles","id":"CVE-2022-39354","kev_date_added":null,"published":"2022-10-25"}],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"CC BY 4.0","name":"GitHub Advisory Database","prefix":"GHSA"},{"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":"no","exploitation":"none","technical_impact":"partial"},"state":"PUBLISHED","updated":"2025-06-17","vendors":["rust-ethereum"]},"summary":"Attackers can force state commitments despite failed contract creation if custom error handling is implemented, affecting Rust EVM library users.","url":"https://insights.sbomify.com/CVE-2024-21629/"}