Rule Information
Tags
pythonssltlscertificate-validationmitmCWE-295OWASP-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-050 --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
ssl._create_unverified_context() creates an SSL context that does not verify the server's certificate. With certificate verification disabled, a TLS connection provides only encryption confidentiality — it does not authenticate the server, meaning an attacker on the network path can perform a man-in-the-middle (MITM) attack by presenting any TLS certificate and intercepting all traffic.
The leading underscore in the function name signals that it is a private, internal function not intended for general use. It exists to provide a workaround for legacy code that cannot use valid certificates. The public API ssl.create_default_context() is the correct function to use, as it enables certificate verification with proper CA chain validation.
This function is sometimes used as a quick fix for certificate errors in development, then accidentally committed to production code. Its presence in production code is always a critical security finding.
Security Implications
Potential attack scenarios if this vulnerability is exploited
1
Man-in-the-Middle Attack
Without certificate verification, any attacker on the network path can present a self-signed or fraudulent TLS certificate. The Python client accepts it without validation, and the attacker can read and modify all "encrypted" traffic.
2
Credential and Session Token Interception
Unverified TLS connections protect data from passive eavesdropping but not from MITM attacks. Login credentials, session tokens, API keys, and sensitive data transmitted over these connections can be captured by an attacker positioned between the client and server.
3
Data Integrity Failure
MITM attackers can modify request and response data in transit, injecting malicious content into responses, altering financial transaction amounts, or replacing software downloads with malicious binaries.
4
Regulatory Compliance Violation
Disabling certificate verification violates PCI DSS Requirement 4.2.1 (secure transmission of cardholder data), HIPAA technical safeguards, and most data protection regulations that mandate proper TLS implementation.
How to Fix
Recommended remediation steps
- 1Replace ssl._create_unverified_context() with ssl.create_default_context() which enables certificate verification with the system CA store.
- 2If connecting to a server with a self-signed or private CA certificate, use ssl.create_default_context(cafile=path_to_ca) to specify the trusted CA.
- 3Never disable certificate verification as a workaround for certificate errors; fix the underlying certificate issue instead.
- 4In development environments, use a local CA (such as mkcert) to issue development certificates trusted by your machine rather than disabling verification.
- 5Audit all SSL context creation in the codebase to ensure CERT_REQUIRED is the validation mode and no custom cert verification bypass is present.
Detection Scope
How Code Pathfinder analyzes your code for this vulnerability
This rule detects calls to ssl._create_unverified_context() in Python source code. All call sites are flagged since this function unconditionally disables certificate verification and is never appropriate for production use.
Compliance & Standards
Industry frameworks and regulations that require detection of this vulnerability
PCI DSS v4.0
Requirement 4.2.1 - Use strong cryptography for cardholder data transmission (proper TLS required)
OWASP Top 10
A02:2021 - Cryptographic Failures
NIST SP 800-52 Revision 2
Certificate validation required for all TLS connections
HIPAA Security Rule
45 CFR 164.312(e)(2)(ii) - Encryption and decryption of data in transit
References
External resources and documentation
Similar Rules
Explore related security rules for Python
HIGH
Weak SSL/TLS Protocol Version
SSLContext configured with SSLv2, SSLv3, TLSv1.0, or TLSv1.1 uses deprecated protocols with known vulnerabilities. Use TLS 1.2 or TLS 1.3.
MEDIUM
Deprecated ssl.wrap_socket() Usage
ssl.wrap_socket() is deprecated since Python 3.7 and should be replaced with SSLContext.wrap_socket() for proper TLS configuration.
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.
Frequently Asked Questions
Common questions about Unverified SSL Context Created
It exists to support legacy code that needs TLS encryption without certificate
validation, such as connecting to internal development servers with self-signed
certificates before proper PKI is set up. The underscore prefix signals it is
an internal function not intended for general use. It should never appear in
production code.
Certificate errors indicate a real problem: an expired certificate, a hostname mismatch,
an untrusted CA, or a self-signed certificate. Fix the error by: renewing the certificate,
correcting the hostname, adding the CA certificate to the trust store, or using
ssl.create_default_context(cafile=path) for private CA certificates. Never bypass
the error.
In unit tests that mock network calls or run against a local test server, disabling
verification may be acceptable. However, it is better to use a test CA with mkcert
or similar tools, or to use Python's ssl.create_default_context() with the test
server's CA certificate. This ensures tests validate the same configuration used
in production.
Both disable certificate verification. ssl._create_unverified_context() returns a
pre-configured context with verification disabled. ssl.SSLContext() with
ctx.verify_mode = ssl.CERT_NONE achieves the same result through explicit configuration.
See PYTHON-LANG-SEC-053 for rules covering the CERT_NONE pattern.
Yes. ssl.create_default_context(cafile="/path/to/corporate-ca.crt") loads the corporate
CA certificate and uses it for validation. Alternatively, add the corporate CA to the
system trust store, which ssl.create_default_context() uses by default.
For localhost connections to locally controlled services, the MITM risk is low since
an attacker would need local process access to intercept the connection. However,
even localhost TLS should use proper certificates for consistency with production
configuration and to prevent errors if the connection is accidentally redirected.
New feature
Get these findings posted directly on your GitHub pull requests
The Unverified SSL Context Created rule runs in CI and posts inline review comments on the exact lines — no dashboard, no SARIF viewer.