CVE-2026-15925: Improper TLS Hostname Verification in Snowflake Connector for Python
Improper TLS hostname verification in Snowflake Connector for Python versions prior to 4.7.1 and 3.18.1 may have allowed a network-positioned attacker to bypass certificate hostname validation on HTTPS connections made by the connector. An attacker with on-path network access could exploit this by intercepting or redirecting network traffic and presenting a certificate signed by any trusted CA for any domain, causing the connector to accept connections without validating that the certificate matched the requested hostname. Successful exploitation requires an on-path traffic interception capability (e.g. ARP/DNS poisoning, rogue access point, BGP hijacking, or malicious proxy/exit node). This vulnerability may have exposed credentials, query data, and staged file contents to interception and tampering, and may have enabled the attacker to issue arbitrary SQL within the context of the victim's connector session. Impact is limited by the privileges of the affected Snowflake role. The fix is available in Snowflake Connector for Python versions 4.7.1 and 3.18.1. Users must manually upgrade.
Security readout for executives and security teams
Plain-English summary
This flaw could let someone positioned on the network intercept a Python application’s Snowflake connection because hostname checks on TLS certificates were incomplete. If successful, they could see or alter Snowflake traffic, including credentials, query data, staged files, and actions allowed by the victim’s Snowflake role.
Executive priority
Treat this as urgent for any production system using the Python connector. The issue can expose sensitive Snowflake data and credentials, but exploitation requires network-positioned access. Prioritize upgrade validation and credential review for high-value data pipelines first.
Technical view
CVE-2026-15925 is CWE-297 improper TLS hostname verification in Snowflake Connector for Python before 3.18.1 and 4.7.1. The connector could accept a certificate signed by any trusted CA without matching the requested hostname. Exploitation requires on-path traffic interception capability.
Likely exposure
Exposure is most likely in Python services, jobs, notebooks, or pipelines using Snowflake Connector for Python versions prior to 3.18.1 or 4.7.1. Risk is higher where traffic crosses untrusted networks, proxies, VPN exits, shared Wi-Fi, or complex enterprise routing paths.
Exploitation context
The source bundle reports no KEV listing and provides no evidence of active exploitation. Exploitation is not remote-only in practice; the attacker must be able to intercept or redirect network traffic between the connector and Snowflake.
Researcher notes
The public data identifies TLS hostname validation failure and fixed versions, but does not include exploit artifacts, patch details, or observed exploitation. Analysis should focus on version inventory, session exposure, privilege scope, and Snowflake activity during the vulnerable deployment window.
Mitigation direction
Manually upgrade Snowflake Connector for Python to 3.18.1 or 4.7.1.
Rebuild and redeploy affected applications, containers, jobs, and notebooks.
Review Snowflake release notes and vendor guidance for branch-specific instructions.
Rotate Snowflake credentials if network interception is plausible.
Review role privileges to limit impact from compromised connector sessions.
Validation and detection
Inventory direct and transitive uses of snowflake-connector-python.
Check lockfiles, container images, notebooks, and runtime environments for affected versions.
Confirm deployed workloads run connector version 3.18.1 or 4.7.1 or later.
Review Snowflake query history for unusual activity from affected clients.
Check network architecture for proxies, exit nodes, or paths enabling interception.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-297: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
1ADP providers
3Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: yesTechnical Impact: total
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-297 · source CWE mapping
Improper Validation of Certificate with Host Mismatch
Improper Validation of Certificate with Host Mismatch represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.