Rule Information
Tags
pythonloggingcode-executionnetworkCWE-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-104 --project .1
2
3
4
5
6
7
8
rule.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
About This Rule
Understanding the vulnerability and how it is detected
This rule detects calls to logging.config.listen(), which starts a socket server that accepts logging configuration over the network. By default, the received configuration is processed using logging.config.dictConfig() or logging.config.fileConfig(), which can execute arbitrary Python code through handler class references and filter callables.
An attacker who can connect to the listening port can send a configuration dict that specifies a handler class like os.system, effectively achieving remote code execution. Python's own documentation warns that "this function is useful for updating logging configuration from a remote machine, but it is not secure."
The rule matches LoggingConfig.method("listen") and fires on any invocation.
Security Implications
Potential attack scenarios if this vulnerability is exploited
1
Remote Code Execution via Configuration
The listener accepts dictConfig-format payloads over TCP. A crafted config can specify arbitrary Python callables as handler classes, filter functions, or formatter factories. This executes code in the context of the application process with its full permissions.
2
No Authentication by Default
logging.config.listen() binds to a port with no authentication, encryption, or access control. Any process that can connect to the port can send config. On a server with a public IP, this is directly exploitable from the internet.
3
Privilege Escalation
If the application runs as root or with elevated permissions, an attacker who sends a malicious config gains those same permissions. In containerized environments, this can lead to container escape.
How to Fix
Recommended remediation steps
- 1Remove logging.config.listen() from production code entirely
- 2Use static logging configuration via dictConfig() or fileConfig() loaded at startup
- 3If remote logging reconfiguration is needed, implement it through your application's authenticated API, not through logging.config.listen()
- 4Bind logging listeners to localhost only if they must exist, and restrict access via firewall rules
- 5Use Python 3.2+ verify parameter to provide a verification function that validates configs before applying
Detection Scope
How Code Pathfinder analyzes your code for this vulnerability
This rule matches calls to logging.config.listen() via the QueryType pattern LoggingConfig.method("listen"). It fires on any invocation regardless of arguments, since the function opens a network socket that accepts executable configuration by default.
Compliance & Standards
Industry frameworks and regulations that require detection of this vulnerability
OWASP Top 10
A03:2021 - Injection
CWE
CWE-95 - Eval Injection
NIST SP 800-53
SI-10: Information Input Validation
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
Logger Credential Leak Risk
Detects logging calls (info, debug, warning, error, critical) that should be audited for accidental credential or secret leakage in log output.
Frequently Asked Questions
Common questions about logging.config.listen() Eval Risk
It opens a TCP socket that accepts Python logging configuration dicts.
Those dicts can specify arbitrary Python callables as handler classes.
Anyone who connects to the port can send a config that executes code.
Python 3.2+ added a verify parameter that lets you provide a function to
validate incoming configs. This helps but is difficult to get right since
you'd need to whitelist safe handler classes and reject everything else.
Removing listen() entirely is safer.
No. Any process on the same network (or localhost) can connect. In cloud
environments with flat networks, a compromised adjacent service can reach
the listener. Defense in depth means not relying solely on network isolation.
Run: pathfinder ci --ruleset python/lang --project .
New feature
Get these findings posted directly on your GitHub pull requests
The logging.config.listen() Eval Risk rule runs in CI and posts inline review comments on the exact lines — no dashboard, no SARIF viewer.