CVE-2024-21629
Evm Project Evm ≤ 0.41.1
Raw vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:NCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2024-21629 is a medium-severity Improper Check or Handling of Exceptional Conditions (CWE-703) vulnerability in Evm Project Evm. Its CVSS base score is 5.9 (Medium).
Operationally, ranked at the 46th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SC-24 (Fail in Known State) and SI-17 (Fail-safe Procedures) — see the control section below for these in your framework.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2024-0220
Vulnerability Data
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…
more
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.
- CWE(s)
Related Threats
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Enforces failure to a known state while preserving required properties, limiting impact of unhandled exceptions.
Mandates explicit fail-safe procedures triggered by indicated failures, structurally preventing unhandled exceptional conditions.
Requires application of security engineering principles that include robust exception and error handling during design.
Requires generation of safe, actionable error messages that directly addresses proper handling of exceptional conditions.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
A.8.26 only requires that security requirements (including resilience against attacks like SQL injection) be identified and specified during development or acquisition; it does not itself remove, fix, or eliminate any exceptional-condition handling defects already present in code.
A.8.28 mandates secure coding practices, principles, defect removal during coding/review, and prohibiting insecure techniques that directly produce improper exception handling; this removes most instances of the first-party code defect, with a bounded remainder in incomplete adoption or edge-case defects not captured by the baseline.
Hardening callouts derived
DISA STIG baselines are authored against specific weaknesses. Where this CVE cites a broad weakness class, the mapping is not asserted at that abstraction (owner ruling, 2026-09-25: grade only at Base and below), so no rule is shown here rather than a rule shown against the wrong grain.
- No fine-grained STIG row for CWE-703, a pillar-level weakness, and none of its children carries one either.