[Question] security contact

[siewer]

Your Question

I think i might have found a security concern in evoagentx - i didn't found a possibility to issue a security issue or security.md or security contact

Additional Context (Optional)

No response

[TedSIWEILIU]

Hi, can you please specify the security issue of evoagentx? We are happy to address it.

[siewer]

I’d like to share information about a potential security issue in EvoAgentX for your analysis. It concerns the built-in Python execution tool — the current “restricted” execution approach appears to be bypassable in a way that can lead to arbitrary code execution on the server.

Summary

The PythonInterpreter executes code using exec() and performs AST-based checks (e.g., blocking some imports). However, the execution context still exposes full Python __builtins__, which makes the restrictions trivially bypassable via __import__, eval, etc.

Details

Affected component: evoagentx/tools/interpreter_python.py
Issue: Restriction/sandbox bypass due to passing full builtins into exec().

The implementation (around the reported location) executes user/agent-provided code in a context similar to:

• exec(code, {"__builtins__": __builtins__})

Even if _analyze_code() blocks import ... statements via static AST inspection, runtime access to built-ins allows dynamic imports and OS command execution without using literal import statements that would be caught by the AST filter.

PoC

The following payload bypasses import restrictions and executes a command on the host:

eval("__import__('os').system('id')")

Equivalent example:

imp = __import__
os = imp("os")
os.system("cat /etc/passwd")

Impact

Impact: Server-side RCE → full compromise of the EvoAgentX process and host-level resources available to it (filesystem, environment variables, network, credentials available to the running service, etc.).

Preconditions: An attacker needs a path to get code executed by this interpreter. Common/realistic paths in agentic systems include:

• A user/tenant can create or modify agents/workflows that enable the python_execute tool.
• A user can submit executions/tasks that the system routes into this interpreter.
• Prompt injection or untrusted external data influences what code ultimately gets executed.

Because the tool is presented as “restricted” (via AST filtering), teams may enable it in contexts where they would not knowingly allow arbitrary code execution — this mismatch increases practical risk.

Suggested fix / mitigation

• Avoid passing full __builtins__ into the exec() globals. If you must use exec, provide a minimal allowlist of safe built-ins only (noting that this is still brittle).
• Treat AST filtering as insufficient for sandboxing. If “safe Python execution” is a goal, run code in a real sandbox:
  • isolated container/VM (e.g., Docker with strong isolation, gVisor, nsjail),
  • no network by default,
  • read-only filesystem or a dedicated scratch workspace,
  • strict CPU/memory/time quotas.
• Consider disabling this tool by default or gating it behind an explicit “dangerous mode” flag with clear warnings.

Advisory / coordinated disclosure note

If you decide to publish a fix, you may want to use GitHub Repository Security Advisories (helpful for coordinated disclosure and can support CVE-related workflows). Documentation:
https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/publishing-a-repository-security-advisory

Happy to help validate a patch and confirm the bypass is closed after changes.

[TedSIWEILIU]

Thanks. Your raised concern has been received. We will look into it.