python-exploitationlisted

# Python Exploitation & Sandbox Escape ## Overview Offensive Python: breaking out of `eval`/`exec` jails, restricted unpicklers, template sandboxes, and audit-hook cages. Core principle — **a sandbox only removes *names*, never *reachability*.** Almost every escape is: find any live object → walk its attribute/frame graph back to a callable or `__globals__` that still holds the real `__builtins__` → import `os`. The single most common mistake (yours and other models'): **hardcoding subclass indices like `[104]`.** They drift across version and import order. Always filter by `__name__` / predicate. ## When to Use - An app runs attacker-influenced code through `eval`, `exec`, `compile`, an AST allowlist, `RestrictedPython`, or a custom pyjail - You face an import / builtins / attribute / dunder / character / byte / length blacklist - A deserialization sink: `pickle`, `marshal`, `PyYAML`, `multiprocessing`, `numpy.load`, `fickling` - Template SSTI in Jinja2 / Mako / `str.format` - An audit hook (PEP 578) or bytecode-opcode verifier guards the runtime - Reversing or weaponizing `.pyc` / raw bytecode **Not for:** defensive sandboxing design (the gotchas inform it, but this is the attacker view), or non-CPython unless noted (`id()`-address and subclass tricks fail on PyPy/Jython). ## Routing | Situation | Starter gadget | Deep dive | |---|---|---| | `__builtins__` emptied | `().__reduce_ex__(2).__globals__['__builtins__']` · `print.__self__` · `(x for x in()).gi_frame.f_bui