Rule Information
Tags
pythonparamikosshhost-keymitmCWE-322OWASP-A02
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-071 --project .1
2
3
4
5
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
paramiko.AutoAddPolicy() and paramiko.WarningPolicy() automatically accept SSH host keys for servers not in the known_hosts file. With AutoAddPolicy, unknown keys are silently accepted and added to known_hosts; with WarningPolicy, a warning is logged but the connection proceeds.
Both policies undermine SSH's protection against man-in-the-middle attacks. SSH host key verification ensures the client is connecting to the genuine server and not an attacker impersonating it. Without this verification, an attacker who can intercept or redirect the TCP connection can perform an MITM attack on the SSH session, capturing credentials and all session data.
paramiko.RejectPolicy() (the default if no policy is set) rejects connections to servers with unknown host keys and is the secure choice. Alternatively, pre-populate known_hosts with the expected host keys.
Security Implications
Potential attack scenarios if this vulnerability is exploited
1
SSH Session MITM via Key Substitution
An attacker who can intercept or redirect the SSH connection can present their own host key instead of the server's. With AutoAddPolicy, the client accepts and uses the attacker's key, decrypting all session data and enabling command injection into the session.
2
Credential Theft
During the SSH authentication phase, the client sends its username and authenticates (password or key challenge-response). With an MITM SSH session, the attacker captures the authentication credentials and can reuse them to authenticate directly to the real server.
3
Command Injection in Automated Workflows
Python scripts that automate SSH commands (deployment, configuration management, monitoring) with AutoAddPolicy trust the connection unverified. An MITM attacker can inject malicious commands into the session, executing them with the SSH user's privileges on the target server.
4
Known_hosts Pollution
AutoAddPolicy permanently adds attacker-controlled keys to known_hosts. Future connections using RejectPolicy will then trust the attacker's key, enabling ongoing MITM attacks even after the original vulnerability is noticed.
How to Fix
Recommended remediation steps
- 1Replace AutoAddPolicy() and WarningPolicy() with RejectPolicy(), which rejects connections to servers with unknown host keys.
- 2Pre-populate known_hosts with expected server host keys using ssh-keyscan in your deployment pipeline or configuration management.
- 3Load known host keys using ssh.load_system_host_keys() and ssh.load_host_keys(known_hosts_path) before connecting.
- 4For automated infrastructure where host keys change (auto-scaling), use SSH certificate authorities instead of individual host keys.
- 5Never suppress host key warnings in production code; treat unknown host keys as a potential MITM attack indicator.
Detection Scope
How Code Pathfinder analyzes your code for this vulnerability
This rule detects calls to paramiko.AutoAddPolicy() and paramiko.WarningPolicy() used as arguments to SSHClient.set_missing_host_key_policy(). Both policies bypass SSH host key verification and are flagged as security concerns.
Compliance & Standards
Industry frameworks and regulations that require detection of this vulnerability
NIST SP 800-53
IA-3: Device Identification and Authentication - verify remote host identity
OWASP Top 10
A02:2021 - Cryptographic Failures
PCI DSS v4.0
Requirement 8.6.1 - System accounts managed with authentication controls
CIS Benchmark SSH
Strict host key checking required for all SSH connections
References
External resources and documentation
Similar Rules
Explore related security rules for Python
HIGH
Unverified SSL Context Created
ssl._create_unverified_context() disables certificate verification entirely, making TLS connections vulnerable to man-in-the-middle attacks.
HIGH
Certificate Validation Disabled (verify=False)
TLS certificate validation is explicitly disabled via verify=False or CERT_NONE, making connections vulnerable to man-in-the-middle attacks.
MEDIUM
Paramiko exec_command() Usage
paramiko exec_command() runs commands on a remote host. Audit that command arguments are not derived from untrusted input to prevent command injection.
Frequently Asked Questions
Common questions about Paramiko Implicit Host Key Trust (AutoAddPolicy)
AutoAddPolicy is used because it avoids the friction of host key management in
development and CI/CD environments. The first connection to a new server raises
a paramiko.ssh_exception.SSHException when using RejectPolicy unless the key has
been pre-loaded. Developers use AutoAddPolicy as a quick fix. The correct solution
is to pre-populate known_hosts in deployment automation.
Use ssh-keyscan to fetch the server's host key and add it to known_hosts:
ssh-keyscan -H hostname >> ~/.ssh/known_hosts. In GitHub Actions, use the
ssh-action with host_key_check: true. In Ansible, use ssh-keyscan before
the playbook runs. Pre-populate known_hosts at deployment time, not at runtime.
Yes. During infrastructure provisioning, fetch the expected host key via a secure
out-of-band channel (the cloud provider API, a configuration management secret,
or an SSH CA certificate). Write it to known_hosts or a custom trusted key file
before the first paramiko connection. Never trust a key received from the same
network path as the SSH connection.
An SSH CA signs host certificates that include the hostname. Clients trust the CA
key, not individual host keys. This eliminates the need to distribute and update
individual host keys for auto-scaling infrastructure. paramiko supports SSH
certificate authentication. See paramiko's documentation for @cert-authority in
known_hosts.
Yes. paramiko.RejectPolicy() raises paramiko.ssh_exception.SSHException with the
message "Server {hostname!r} not found in known_hosts" when the server's key is
not in known_hosts. Catch this exception and handle it as a security event, not
a routine error to be suppressed.
No. WarningPolicy still proceeds with the connection despite the unknown key,
providing no actual protection against MITM. The warning may be missed, ignored,
or logged after the damage is done. Use RejectPolicy and treat unknown host keys
as security incidents, not warnings to be monitored.
New feature
Get these findings posted directly on your GitHub pull requests
The Paramiko Implicit Host Key Trust (AutoAddPolicy) rule runs in CI and posts inline review comments on the exact lines — no dashboard, no SARIF viewer.