The execute_code tool's subprocess sandbox screened submitted programs against a fixed list of dangerous attribute names, and that list omitted the attribute that exposes the live builtins module, so a short program could still run operating system commands as the server user.

PraisonAI lets an agent run Python through an execute_code helper. A change in the 1.6 line moved that execution into a separate process and reused the older checks, but the check that walks the syntax tree only knew a fixed list of dangerous attribute names, and the list missed the attribute through which a bound CPython builtin exposes the module it belongs to. Because the same change also stopped running the text-pattern list in the default sandbox mode, and because names assembled from short string pieces never look dangerous to a static reader, the whole guard could be stepped around with a handful of statements. Anyone able to steer code into the helper, directly or through an agent prompt, gets command execution with the permissions of the service account: the published proof runs the identity command inside the sandbox and prints its output. The hardened release adds the missing attribute and the helper call to the blocked sets, also screens calls written as attribute access rather than bare names, and runs the same syntax check on the way into the sandboxed path, so the proof is refused before it starts.