Findings

CVE-2026-102734

asteval Sandbox Escape: arbitrary native memory read/write via numpy ctypes in default asteval Interpreter

Published Aug 20, 2026 · updated Oct 14, 2026

### Summary With its default configuration (numpy enabled, disabled), asteval's lets an attacker-controlled expression obtain a raw **arbitrary process-memory read and write** primitive, without using , any attribute, or / / . 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 ( ) blocks every name and blocks objects whose attribute value is *identity-equal* to one of the modules in . The **module** entry was added recently (commit 9d9d430) and correctly blocks . 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 wrapper using only ordinary (non-dunder) attribute names: zeros(1, dtype=int32).ctypes.shape._type_ -> exposes (a ctypes array) whose element type is . None of , , is a dunder, none is in , and the returned value is a *type*, not the ctypes module, so permits all of them. On that ctypes type, the metaclass method is reachable (non-dunder, not in ; it is not even listed by , which is likely why it was missed): * **Arbitrary read:** reads 8 bytes at any address. (a permitted builtin) supplies arbitrary object addresses. * **Arbitrary write:** writes 8 bytes to any address. The write half rides asteval's **unfiltered ** in (the branch performs with no attribute-name check). Root cause is two gaps: 1. blocks the ctypes *module* but not ctypes *types* / metaclass methods ( , , , , ) reachable via . 2. performs attribute writes ( ) and deletes ( ) with no attribute-name filtering. This belongs to the known "numpy is a large attack surface" class (the docs already note read and write), but this specific arbitrary memory read/write chain is undocumented and bypasses