Skip to content

Warn that overriding __builtins__ for eval is not a security mechanism#145773

Open
StanFromIreland wants to merge 2 commits intopython:mainfrom
StanFromIreland:eval_sec
Open

Warn that overriding __builtins__ for eval is not a security mechanism#145773
StanFromIreland wants to merge 2 commits intopython:mainfrom
StanFromIreland:eval_sec

Conversation

@StanFromIreland
Copy link
Member

@StanFromIreland StanFromIreland commented Mar 10, 2026

This misleads users as it gives the impression that the above warning can be ignored.


📚 Documentation preview 📚: https://cpython-previews--145773.org.readthedocs.build/

Copy link
Contributor

@sethmlarson sethmlarson left a comment

Choose a reason for hiding this comment

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

LGTM, thank you!


This function executes arbitrary code. Calling it with
user-supplied input may lead to security vulnerabilities.
user-supplied input will lead to security vulnerabilities.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
user-supplied input will lead to security vulnerabilities.
un-trusted user-supplied input can easily lead to security vulnerabilities.

Copy link
Member Author

Choose a reason for hiding this comment

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

We are generally trying to strengthen the warning (we held a little vote, people are in favour), but IMO this suggestion reverts that. Might I ask why exactly you want it to be so?

Comment on lines +708 to +709
names, but it is **not** a security mechanism, the executed code can
still access builtins.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
names, but it is **not** a security mechanism, the executed code can
still access builtins.
names, but is **not** a security mechanism: the executed code can
still access all builtins.

Comment on lines +618 to +619
names, but it is **not** a security mechanism, the executed code can
still access builtins.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
names, but it is **not** a security mechanism, the executed code can
still access builtins.
names, but this is **not** a security mechanism: the executed code can
still access all builtins.


This function executes arbitrary code. Calling it with
user-supplied input may lead to security vulnerabilities.
user-supplied input will lead to security vulnerabilities.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
user-supplied input will lead to security vulnerabilities.
un-trusted user-supplied input can easily lead to security vulnerabilities.

@picnixz
Copy link
Member

picnixz commented Mar 10, 2026

I'm always torn when we change these kind of notes. I don't agree that this will lead to security vulnerabilities. It depends on your threat model. So the "may"/"can" formulation is for me the correct one.

What I do find correct however is that untrusted input can lead to security vulnerabilities. I would honestly drop the "easily" part as again it depends on where the untrusted input comes from. For instance, the user can supply an arbitrary string, and that arbitrary string is processed with (highly non-trivial, but still polynomial-time evaluable) reversible transformations that eventually output a string that is then evaled. In this case, you can consider that you have a security vulnerability, but not necessarily "easily" achievable (but still achievable if you spend time to reverse the transformations).

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

Labels

Projects

Status: Todo

Development

Successfully merging this pull request may close these issues.

5 participants