CVE-2026-55244 in asteval
Summary
by MITRE • 09/14/2026
ASTEVAL is an evaluator of Python expressions and statements. Prior to 1.0.9, FROM_PY in asteval/astutils.py exposes BaseException, SystemExit, KeyboardInterrupt, and GeneratorExit to expressions evaluated by asteval.Interpreter.eval(), while run() and eval() in asteval/asteval.py catch Exception rather than these non-Exception BaseException subclasses. When an attacker-controlled expression raises one of these classes, on_raise() passes the class to raise_exception(), and the resulting exception bypasses the interpreter's safety handlers and propagates into the calling application. A consuming service that evaluates untrusted expressions can therefore be terminated or have signal and cleanup handling disrupted, causing denial of service. The separately documented read-only open() capability is not part of this vulnerability. This issue is fixed in version 1.0.9.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/19/2026
The ASTEVAL library serves as a secure evaluator for Python expressions and statements, designed to allow the execution of user-supplied code within a restricted sandbox environment. In versions prior to 1.0.9, a critical architectural flaw exists in how exception handling is implemented during the evaluation process. The vulnerability stems from an inconsistency between the exceptions exposed by the internal utility module and those caught by the main interpreter loop. Specifically, the FROM_PY function in asteval/astutils.py exposes BaseException subclasses such as SystemExit, KeyboardInterrupt, GeneratorExit, and BaseException itself to expressions evaluated via the Interpreter.eval() method. However, the run() and eval() methods in the primary asteval module are configured to catch only Exception instances, which is a subclass of BaseException that excludes these specific critical exception types.
This discrepancy creates a bypass mechanism for safety handlers intended to contain malicious or erroneous code execution. When an attacker-controlled expression triggers one of these uncaught exceptions, such as SystemExit or KeyboardInterrupt, the on_raise() handler passes the class to raise_exception(). Because the main evaluation loop does not catch BaseException subclasses other than Exception, the exception propagates directly out of the ASTEVAL interpreter and into the calling application. This behavior effectively neutralizes the sandboxing mechanism for these specific error conditions, allowing external input to influence the control flow of the host process in unintended ways.
The operational impact of this vulnerability is primarily a denial of service against services that rely on ASTEVAL to evaluate untrusted expressions. By forcing the interpreter to raise SystemExit or KeyboardInterrupt, an attacker can abruptly terminate the consuming application's execution thread. Furthermore, raising GeneratorExit or other BaseException types can disrupt signal handling and cleanup routines, leading to resource leaks, incomplete transactions, or unstable system states. This is particularly dangerous in web services or API endpoints that process user input as Python expressions, where a single malicious payload could crash the service instance without requiring any privilege escalation or remote code execution capabilities beyond what is already permitted by the sandboxed environment.
From a classification perspective, this vulnerability aligns with CWE-754: Improper Check for Unusual or Exceptional Conditions and CWE-269: Improvement of Privileges. The failure to handle all potential exception types raised within a restricted context represents an improper check that allows control flow to escape the intended boundary. In terms of attack vectors, this relates to MITRE ATT&CK techniques involving Denial of Service via application crash or resource exhaustion, specifically leveraging logic flaws in error handling mechanisms rather than buffer overflows or injection attacks. The vulnerability highlights the importance of ensuring that exception handlers in sandboxed environments are comprehensive and cover all possible exit paths defined by the language runtime.
The recommended mitigation is to upgrade ASTEVAL to version 1.0.9 or later, where this issue has been resolved. Developers should ensure that their dependency management systems enforce this minimum version requirement across all affected services. For organizations unable to immediately patch, implementing a wrapper around the eval() function that catches BaseException and handles it safely within the application logic can provide temporary relief, although upgrading remains the only definitive solution. It is also advisable to review other third-party libraries used for code evaluation to ensure they do not exhibit similar flaws in exception handling or sandbox boundary enforcement.