CVE-2026-40583
Ultradag 0.1.0
Raw vector
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/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:RedSummary
CVE-2026-40583 is a high-severity Improper Cleanup on Thrown Exception (CWE-460) vulnerability in Ultradag Ultradag. Its CVSS base score is 8.8 (High).
Operationally, ranked at the 31th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SC-24 (Fail in Known State) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-40583 is a vulnerability in UltraDAG, a minimal DAG-BFT blockchain implemented in Rust, affecting version 0.1. It enables a non-council attacker to submit a signed SmartOp::Vote transaction that passes initial signature, nonce, and balance prechecks but fails authorization only after state mutation has already occurred. The issue carries a CVSS v3.1 base score of 8.2 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H) and maps to CWE-460 and CWE-696.
A remote attacker requires no privileges, authentication, or user interaction to exploit this over the network with low complexity. Successful exploitation triggers unintended state mutation prior to authorization failure, resulting in low integrity impact and high availability disruption.
The UltraDAG core GitHub repository addresses the vulnerability via commits 2f5a3a237ea519b48d71e6e3093c89f60694c7be and 45bcf7064741897319b6196d3d9f9e1307093511, with additional mitigation details in security advisory GHSA-q8wx-2crx-c7pp.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-24179
Vulnerability Data
UltraDAG is a minimal DAG-BFT blockchain in Rust. In version 0.1, a non-council attacker can submit a signed SmartOp::Vote transaction that passes signature, nonce, and balance prechecks, but fails authorization only after state mutation has already occurred.
- CWE(s)
Related Threats
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation at post-design stages can discover incorrect ordering of related behaviors before deployment.
Requires the system to fail to a known state on indicated failures, directly forcing proper state cleanup instead of leaving inconsistent state after an exception.
Mandates explicit fail-safe procedures on failures, which structurally enforces cleanup actions that the weakness omits.
Vulnerability scanning may surface order-related weaknesses after code is built but does not address their root cause.
Mandating a documented development process and standards enforces review of behavior ordering within the software lifecycle.
Requires application of security engineering principles (e.g., fail-safe, complete mediation) during design that would eliminate improper exception cleanup.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly enforce proper exception handling and resource cleanup.
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.
Security testing can detect missing cleanup paths, thereby mitigating the weakness before deployment.
Secure SDLC mandates exception-handling and cleanup practices that reduce improper state after thrown exceptions.
Application security requirements can specify robust exception handling and resource-release rules.
Secure architecture principles include designing for safe failure and guaranteed cleanup on exceptions.
Secure coding standards directly require proper resource release and state restoration after exceptions.
Change management may catch order-related issues during reviews but does not address root cause.