Security: Unsafe eval in safe_eval.py allows code injection via globals parameter

[tomaioo]

Summary

Security: Unsafe eval in safe_eval.py allows code injection via globals parameter

Problem

Severity: High | File: packages/core/src/robotcode/core/utils/safe_eval.py:L50

The safe_eval function in safe_eval.py accepts a globals parameter that is passed directly to eval(). While the Transformer class restricts access to names, the globals dictionary can contain arbitrary callables or objects that bypass name-based restrictions. An attacker could pass a crafted globals dict with __import__, open, or other dangerous builtins disguised as allowed names, or use dunder methods on allowed types to execute arbitrary code. The function also uses eval() with compile() output, which can still execute arbitrary code if the AST is not fully sanitized.

Solution

Remove the globals parameter entirely, or strictly validate all values in the globals dict to ensure they are not callable and do not have dangerous dunder methods. Consider using ast.literal_eval instead of eval for simple data structures, or implement a proper sandbox using RestrictedPython.

Changes

• packages/core/src/robotcode/core/utils/safe_eval.py (modified)

[d-biehl]

Can you clarify how you concluded that this is a security issue?

From what I see, globals is intentional here and used with RobotCode-controlled SAFE_GLOBALS. This PR removes that behavior without considering the existing callers, tests, and documented use cases.

If this is meant to address a real security vulnerability, why was it submitted as a public PR instead of following the contribution guidelines for security-related issues?

Also, this does not seem to follow the general contribution guidelines: the change is not verified with updated tests/docs, and the commit is not signed.

Please don’t take this personally, but first-time security-related contributions without prior interaction with the project are something I need to fact-check carefully. That’s not meant as an accusation, just due diligence given the number of low-context security PRs and OSS supply-chain incidents in recent years.

Opening PRs in projects without prior context or a clearly demonstrated issue creates review and verification work for maintainers. That is fine when there is a solid reason and the contribution follows the project guidelines, but in this case the problem statement, threat model, and verification are still unclear.

If this was created with the help of AI tools, automation, or a scanner, please disclose that as required by the AI and Automated Contribution Policy and explain how you manually verified the finding against RobotCode’s actual usage.