GHSA-9w56-46f6-3qhx: Medium severity pip/asteval vulnerability
Summary With its default configuration (numpy enabled, import disabled), asteval's Interpreter lets an attacker-controlled expression obtain a raw arbitrary process-memory read and write primitive, without using import, any dunder attribute, or eval/exec/getattr. Arbitrary in-process read/write is equivalent to arbitrary code execution and is a complete escape of the sandbox whose entire purpose is "untrusted string in, no arbitrary execution out." Any application that feeds untrusted input to asteval with numpy installed (the default) is affected.
Details asteval's attribute filter (asteval/astutils.py: safegetattr) blocks every dunder name and blocks objects whose attribute value is identity-equal to one of the modules in UNSAFEMODULES = {io, os, sys, ctypes}. The ctypes module entry was added recently (commit 9d9d430) and correctly blocks ndarray.ctypes.ctypes.
However, the module check is identity-only against the ctypes module. It does not cover ctypes type objects and their metaclass methods, which are reachable through numpy's ndarray.ctypes wrapper using only ordinary (non-dunder) attribute names:
zeros(1, dtype=int32).ctypes.shape.type -> <class 'ctypes.clong'>
ndarray.ctypes exposes .shape (a ctypes array) whose element type .type is ctypes.clong. None of ctypes, .shape, .type is a dunder, none is in UNSAFEATTRS, and the returned value is a type, not the ctypes module, so safegetattr permits all of them.
On that ctypes type, the metaclass method fromaddress is reachable (non-dunder, not in UNSAFEATTRS; it is not even listed by dir(), which is likely why it was missed):
Arbitrary read: clong.fromaddress(addr).value reads 8 bytes at any address. id() (a permitted builtin) supplies arbitrary object addresses. Arbitrary write: cell = clong.fromaddress(addr); cell.value = X writes 8 bytes to any address. The write half rides asteval's unfiltered setattr in Interpreter.nodeassign (the ast.Attribute branch performs setattr(self.run(node.value), node.attr, val) with no attribute-name check).
Root cause is two gaps:
1. safegetattr blocks the ctypes module but not ctypes types / metaclass methods (fromaddress, frombuffer, frombuffercopy, indll, fromparam) reachable via ndarray.ctypes ... .type. 2. nodeassign performs attribute writes (setattr) and deletes (delattr) with no attribute-name filtering.
This belongs to the known "numpy is a large attack surface" class (the docs already note open() read and ndarray.tofile() write), but this specific arbitrary memory read/write chain is undocumented and bypasses the most recent ctypes-module hardening. All previously reported escapes (CVE-2025-24359 / GHSA-3wwr-3g9f-9gc7, GHSA-vp47-9734-prjw, reduce/reduceex, classic subclasses traversal) are patched on the current code; this one is live.
PoC Self contained POC here: https://gist.github.com/thegr1ffyn/16b67c5f9b5339a7e2bdc91423ff09e3 Environment: pip install asteval numpy (verified on asteval 1.0.8, numpy 2.4.6, CPython 3.12.3; the chain is numpy-1.x/2.x robust). Default Interpreter (usenumpy=True, import disabled).
Minimal one-expression arbitrary read (reads 8 bytes at an attacker-chosen address):
zeros(1,dtype=int32).ctypes.shape.type.fromaddress(id(zeros(1))).value
Minimal arbitrary write (writes 0x4142434445464748 to a chosen address; here our own array buffer, observed back through numpy):
a = zeros(2, dtype=int32) cell = a.ctypes.shape.type.fromaddress(a.ctypes.data) cell.value = 0x4142434445464748 # -> a[0]=0x45464748, a[1]=0x41424344
A full self-contained script is attached (pocastevalctypes.py); running it prints the recovered PyObject header of a private object (arbitrary read) and confirms a raw write landing at a chosen pointer (arbitrary write), all from a default, import-disabled interpreter.
Impact Sandbox escape / protection-mechanism failure leading to arbitrary in-process native memory read and write (RCE-equivalent). Impact:
Disclosure of any data in the host process's address space (secrets, keys, other users' data). Corruption of arbitrary memory -> control-flow hijack / arbitrary code execution and/or process crash (DoS).
Affected: any application that evaluates untrusted/attacker-influenced expressions with asteval while numpy is installed (the default). No authentication and no special configuration is required; import does not need to be enabled. Mitigation until patched: construct the interpreter with usenumpy=False.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/astevalto a version that resolves this vulnerability.Fixed in 1.0.9 - Configuration
Construct the asteval Interpreter with use_numpy=False as a mitigation until patched, since the default Interpreter uses numpy (use_numpy=True) and enables the attacker chain involving ndarray.ctypes and arbitrary in-process memory read/write.
asteval Interpreter use_numpy = False
Event History
Frequently Asked Questions
Which deployments should be prioritized for triage?
Any application that passes untrusted expressions to asteval's Interpreter while numpy is installed should be treated as affected. Numpy is enabled by default, including when asteval's import support is disabled.
Does disabling import or blocking dunder attributes prevent exploitation?
No. The described primitive does not use import, any dunder attribute, or eval, exec, or getattr. It reaches ctypes type objects through numpy's ndarray.ctypes wrapper using ordinary attribute names.
What is the practical impact if exploitation succeeds?
An attacker can obtain arbitrary read and write access to the process memory. The advisory states that arbitrary in-process memory access is equivalent to arbitrary code execution and represents a complete sandbox escape.