Skip to content

Security: replace eval() with ast.literal_eval() and add path traversal checks - #1542

Open
johnpippett wants to merge 2 commits into
TransformerOptimus:mainfrom
johnpippett:security/critical-fixes-2026-04-28
Open

Security: replace eval() with ast.literal_eval() and add path traversal checks#1542
johnpippett wants to merge 2 commits into
TransformerOptimus:mainfrom
johnpippett:security/critical-fixes-2026-04-28

Conversation

@johnpippett

Copy link
Copy Markdown

Fixes two critical security findings:

  1. Arbitrary code execution via eval(): Replaced all eval() calls in LLM output handling, agent configs, and templates with ast.literal_eval() across 7 files.
  2. Path traversal: Added _validate_path_containment() in resource_helper.py to ensure all file operations stay within the designated root directory.

Syntax validated; standalone verification confirms malicious payloads are rejected.

… code execution

Replaces all eval() calls on LLM output and database-stored config values
with ast.literal_eval(), which only permits Python literals and cannot
execute arbitrary code.

Affected files:
- superagi/agent/output_handler.py
- superagi/agent/queue_step_handler.py
- superagi/models/agent_execution_config.py
- superagi/models/agent_template.py
- superagi/models/agent.py
- superagi/controllers/knowledges.py

Fixes critical finding: Arbitrary code execution via eval() on LLM output.
Adds _validate_path_containment() to ResourceHelper and applies it to
get_resource_path(), get_agent_write_resource_path(), and
get_agent_read_resource_path(). This prevents file tools from reading or
writing outside the intended resource directories via ../ sequences or
absolute path injection.

Affected files:
- superagi/helper/resource_helper.py

Fixes critical finding: Path traversal in file tools.

@Ujjawal0204 Ujjawal0204 left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice security pass. One edge case in the new containment check: in get_agent_read_resource_path(), validation happens before {agent_id} / {agent_execution_id} placeholders are expanded, while the write path validates after formatting.

If formatted names can contain path separators or traversal-like content, the final path may differ from the path that was validated. Could we either expand placeholders before _validate_path_containment(...) or revalidate after expansion for consistency with get_agent_write_resource_path()?

@johnpippett

Copy link
Copy Markdown
Author

@Ujjawal0204 I took a local look and I think your concern is valid.

I reproduced the path-shape issue against ResourceHelper: placeholder expansion uses agent.name.replace(" ", "") / agent_execution.name.replace(" ", ""), so names containing path separators or traversal segments are not sanitized. With names like ../../escape, the final normalized resource path can land outside the intended workspace/output tree.

One extra finding: this is not limited to get_agent_read_resource_path(). The write path expands placeholders earlier, but then validates file_name against the already-expanded root. If that expanded root has already escaped the configured output base, validation still passes because it only proves the file is inside the escaped root.

So the safer fix is to either sanitize the formatted agent/run path components so they cannot contain /, \, or traversal-like segments, or validate the final normalized path after placeholder expansion against the original configured input/output base directory.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants