Snowflake Python Connector CVE-2026-15925

Exploitation requires the attacker to already hold an active on-path traffic-interception position between the victim connector and Snowflake - concretely ARP or DNS poisoning on the local segment, a rogue/evil-twin access point, BGP hijacking of the route, or operation of a malicious proxy or Tor-style exit node the victim's traffic traverses. Given that position, the only other prerequisite is any certificate signed by a publicly trusted CA (for any domain, not necessarily Snowflake's), which the attacker presents during the TLS handshake. Limiting factors: the attacker cannot exploit this purely remotely without that interception capability (reflected as AT:P in the CVSS 4.0 vector), so victims on fully trusted networks are not exposed; the blast radius is further bounded by the privileges of the affected Snowflake role, so a low-privilege service role limits the SQL an attacker can issue. No end-user interaction or prior authentication to the connector is needed (PR:N/UI:N) once the traffic is intercepted.

The vendor CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:L) scores 9.2, but the decisive metric is AT:P - a specific Attack Requirement is present, namely a privileged on-path network position. That requirement is the true rate-limiter and is not captured by the headline score alone: an attacker cannot exploit this from anywhere on the internet, only where they can already intercept or redirect the victim's traffic (ARP/DNS poisoning, rogue AP, BGP hijack, or a malicious proxy/exit node). No EPSS score was provided, KEV status is not listed (not actively exploited per available data), and no POC was referenced, so this is a high-severity-but-conditional issue rather than a mass-exploitation threat. The most likely real-world exposure is connectors running over untrusted networks (public Wi-Fi, shared/hostile infrastructure, or through interceptable proxies). Note the impact asymmetry the vector encodes: high confidentiality and integrity impact (credential/data theft and SQL tampering) but only low availability impact (VA:L). Signals are internally consistent; the main caveat is that all data originates from the vendor's own advisory, with no independent NVD enrichment, EPSS, or third-party confirmation yet.

A data engineer runs a Python job using a vulnerable connector while connected through a rogue Wi-Fi access point or a compromised proxy. The attacker redirects the TLS session to their own endpoint, presents a legitimately CA-signed certificate for an unrelated domain, and because hostname matching is skipped the connector completes the handshake - letting the attacker capture the Snowflake credentials and query data and inject arbitrary SQL within the victim's role. No public exploit code is currently identified, but the technique (any-CA-signed cert accepted for any host) is well understood and straightforward to weaponize given the on-path position.