Rule Information
Tags
pythonglobalsnamespace-injectiondynamic-executionCWE-95OWASP-A03
CWE References
Interactive Playground
Experiment with the vulnerable code and security rule below. Edit the code to see how the rule detects different vulnerability patterns.
pathfinder scan --ruleset python/PYTHON-LANG-SEC-004 --project .1
2
3
4
5
6
7
rule.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
About This Rule
Understanding the vulnerability and how it is detected
Python's built-in globals() function returns a reference to the current module's global namespace as a live, mutable dictionary. Any code that receives this dictionary can read all global variables, overwrite them, inject new names, or delete existing ones.
Passing globals() to eval(), exec(), or any function that modifies the dictionary enables an attacker to redefine security-critical functions, inject callable backdoors, overwrite configuration values, or access credentials stored in module-level constants.
Common dangerous patterns include passing globals() as the namespace argument to eval() or exec(), passing it to template rendering functions, serializing it to disk or network, or using it as a lookup table to resolve user-supplied function names.
Security Implications
Potential attack scenarios if this vulnerability is exploited
1
Global Namespace Corruption
An attacker who gains write access to the dictionary returned by globals() can overwrite any module-level variable or function. This includes authentication functions, access control checks, cryptographic keys, and database connection strings.
2
Code Execution via Namespace Injection
When globals() is passed as the namespace to eval() or exec(), an attacker controlling the evaluated code can define new entries in the global namespace that persist after the eval/exec call, creating persistent backdoors in the running process.
3
Credential Exposure
The global namespace typically contains imported modules, configuration constants, and application-level secrets. Serializing or logging globals() can expose API keys, database passwords, cryptographic secrets, and other sensitive values.
4
Authentication Bypass
Overwriting a global function such as is_authenticated or check_permission through the globals() dictionary allows an attacker to replace security checks with no-ops, effectively bypassing all authorization logic in the module.
How to Fix
Recommended remediation steps
- 1Replace globals()-based function lookup with an explicit dictionary mapping allowed names to their callables.
- 2Never pass globals() as the namespace argument to eval() or exec(); create a minimal, read-only namespace with only the names required.
- 3Do not serialize, log, or transmit the globals() dictionary as it contains credentials and sensitive configuration.
- 4Use getattr() with an allowlist on a specific module or object for dynamic dispatch rather than searching the entire global namespace.
- 5Audit all uses of globals() in code that processes external input to ensure no user-controlled key can reach the globals dict.
Detection Scope
How Code Pathfinder analyzes your code for this vulnerability
This rule detects all calls to the built-in globals() function in Python source code. It targets patterns where the return value of globals() is passed to another function, used as a namespace argument, stored in a variable for later use, or directly returned from a function.
Compliance & Standards
Industry frameworks and regulations that require detection of this vulnerability
CWE Top 25
CWE-95 - Eval Injection in the MITRE CWE Top 25 Most Dangerous Software Weaknesses
OWASP Top 10
A03:2021 - Injection
NIST SP 800-53
SI-10: Information Input Validation
PCI DSS v4.0
Requirement 6.2.4 - Protect web-facing applications against injection attacks
References
External resources and documentation
Similar Rules
Explore related security rules for Python
HIGH
Dangerous eval() Usage Detected
eval() executes arbitrary Python expressions from strings, enabling remote code execution when called with untrusted input.
HIGH
Dangerous exec() Usage Detected
exec() executes arbitrary Python statements from strings or code objects, enabling remote code execution when called with untrusted input.
MEDIUM
Non-literal Dynamic Import Detected
__import__() or importlib.import_module() with a non-literal argument can import arbitrary modules when called with untrusted input.
Frequently Asked Questions
Common questions about Dangerous globals() Usage Detected
Not always. globals() is safe when used for introspection in development tools, test
frameworks, or debugging utilities that only read from the dictionary. It becomes dangerous
when the dictionary is passed to code that can modify it, when it is used for user-controlled
name resolution, or when it is serialized and exposed over a network.
A shallow copy of globals() still contains references to all module objects. An attacker
who can call methods on those objects (e.g., imported modules) can still execute arbitrary
code. A deep copy is impractical and would not include live module state. The correct fix
is to use a minimal, purpose-built namespace with only required names.
Create an explicit allowlist dictionary mapping string names to their corresponding
callables. Check that the user-supplied name exists in the allowlist before calling it.
This is both more secure and more explicit about what operations are permitted.
Yes, all globals() calls are flagged. Module setup code in __init__.py typically does not
need to call globals() and is usually better expressed with explicit variable assignments.
If the usage is purely for package introspection during import (not at request time), it
can be reviewed and suppressed with a comment explaining the safety rationale.
When globals() is passed as the first (global namespace) argument to eval() or exec(),
any names defined in the evaluated code are written into the module's live global
namespace and persist after the eval/exec returns. This is one of the most dangerous
combinations possible in Python code.
globals() is O(1) and has minimal performance overhead. Performance is not a valid
reason to use globals() for dynamic dispatch; the security risk outweighs any benefit
compared to a simple allowlist dictionary lookup.
New feature
Get these findings posted directly on your GitHub pull requests
The Dangerous globals() Usage Detected rule runs in CI and posts inline review comments on the exact lines — no dashboard, no SARIF viewer.