Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.0",
  "pubDate": "2026-09-14T20:16:47.640Z",
  "pubdate": "2026-09-14T20:16:47.640Z",
  "executiveSummary": "ASTEVAL versions prior to 1.0.9 are susceptible to a Denial of Service (DoS) vulnerability arising from improper exception handling within the interpreter's evaluation logic.\nThe vulnerability stems from the exposure of non-Exception BaseException subclasses, specifically BaseException, SystemExit, KeyboardInterrupt, and GeneratorExit, to the interpreter's evaluation environment.\nBecause the ASTEVAL engine utilizes catch-all blocks targeting only the Exception class, these critical base-level exceptions bypass existing safety mechanisms.\nAn attacker capable of injecting or controlling an expression passed to asteval.Interpreter.eval() can trigger these exceptions, forcing them to propagate into the calling application's stack.\nSuccessful exploitation results in the abrupt termination of the host process, disruption of critical signal handling, or interference with application cleanup procedures, thereby causing a service outage.\nThe vulnerability requires the ability to provide untrusted input to the interpreter; however, it does not require authentication if the application exposes an evaluation interface to an attacker.\nThis represents a significant risk for services relying on ASTEVAL for the dynamic processing of user-provided Python expressions.",
  "technicalDetails": "The root cause of this vulnerability lies in the combination of unsafe attribute exposure in asteval/astutils.py and insufficient exception trapping in asteval/asteval.py.\nIn asteval/astutils.py, the FROM_PY mechanism erroneously exposes high-level Python system exceptions—specifically BaseException, SystemExit, KeyboardInterrupt, and GeneratorExit—to the evaluator's namespace. These classes represent system-level events rather than standard application-level errors.\nThe interpreter's core evaluation logic, located in asteval/asteval.py, relies on try-except blocks that target only the Exception class. In Python, Exception is a subclass of BaseException, meaning that any exception inheriting directly from BaseException (such as SystemExit) will not be caught by standard application-level try-except blocks.\nThe attack flow proceeds as follows: An attacker submits a malicious expression containing a statement such as 'raise SystemExit()' or 'raise KeyboardInterrupt()'. When this expression is processed by asteval.Interpreter.eval(), the ASTEVAL engine invokes on_raise(), which subsequently passes the exception class to raise_exception().\nBecause the caught exception does not inherit from Exception, it bypasses the internal handler in ASTEVAL. The exception propagates out of the interpreter's sandbox and into the host application's runtime environment.\nFor an application consuming ASTEVAL, this means that a single untrusted evaluation can trigger a process exit (in the case of SystemExit) or interrupt asynchronous workflows (in the case of KeyboardInterrupt), effectively crashing the service or forcing it into an inconsistent state.\nThe vulnerability is restricted to versions prior to 1.0.9. It does not involve the read-only open() capability, which is handled via different mechanisms. No specialized privileges are required beyond the ability to influence the expression being evaluated by the interpreter, making this a critical concern for any system that dynamically executes user-supplied code."
}