CVE-2026-86600 in Connector for Python
Summary
by MITRE • 09/08/2026
In affected Snowflake drivers, WORKLOAD_IDENTITY authentication requests a cloud workload-identity token and attaches it to the login request without verifying that the configured host is a Snowflake endpoint. An attacker who can modify the connection configuration can cause the driver to mint a fresh attestation and send it to a host they control. The captured token can be replayed to Snowflake for its remaining lifetime in accounts where that workload identity is already registered. On Azure, the token audience is also taken from connection configuration. Combined with an attacker-controlled host, the driver can request a Managed Identity access token scoped to a non-Snowflake Azure resource and deliver it to the attacker. That path is the only case in which impact extends beyond Snowflake; it is bounded by the token lifetime and the managed identity’s permissions. Successful exploitation requires WORKLOAD_IDENTITY authentication on a workload that already has an ambient cloud identity. Patched driver versions restrict this authenticator to recognized Snowflake hosts. Users must manually upgrade.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/08/2026
The vulnerability in question represents a critical flaw within Snowflake client drivers, specifically affecting the implementation of the WORKLOAD_IDENTITY authentication mechanism. This security issue stems from an insufficient verification process where the driver fails to validate that the target host specified in the connection configuration is actually a legitimate Snowflake endpoint before processing authentication requests. In normal operation, this authenticator type relies on cloud workload identity tokens, such as those provided by Azure Managed Identity or AWS IAM roles, to establish secure connections without requiring static credentials like passwords or keys. However, because the driver does not enforce host validation against a known list of trusted Snowflake domains, it allows for a man-in-the-middle style attack vector where an attacker can manipulate the connection parameters to redirect authentication traffic away from Snowflake infrastructure and toward a server under their control.
The operational impact of this flaw is significant due to the nature of cloud workload identities which are often granted broad permissions within their respective environments. When an attacker modifies the connection configuration, they can trick the driver into minting or retrieving a fresh attestation token intended for Snowflake but instead sending it to the attacker-controlled host. In scenarios where the targeted account has already registered this specific workload identity, the captured token retains its validity and can be replayed directly against the actual Snowflake service during its remaining lifetime. This allows an unauthorized actor to gain full access to the associated data warehouse resources without needing to compromise any static secrets or passwords, effectively bypassing multi-factor authentication controls that might otherwise protect traditional login methods.
A particularly severe aspect of this vulnerability occurs on Microsoft Azure environments where the token audience is derived directly from the connection configuration rather than being hardcoded by the driver. This design choice enables an attacker who controls both the host and the audience parameter to request a Managed Identity access token scoped to arbitrary non-Snowflake Azure resources. By delivering these tokens to their own infrastructure, attackers can potentially escalate their impact beyond just accessing Snowflake data. They could use these forged or redirected tokens to interact with other cloud services such as storage accounts, key vaults, or compute instances associated with the compromised managed identity. This extension of impact is bounded only by the token's expiration time and the specific permissions assigned to that managed identity, making it a high-risk vector for lateral movement within an organization’s Azure tenant.
From a technical classification perspective, this vulnerability aligns closely with CWE-295 Improper Certificate Validation or more accurately CWE-613 Insufficient Session Expiration as well as CWE-447 Unverified Use of Dangerous Prototype if considering the configuration manipulation aspect. In terms of MITRE ATT&CK framework mapping, this behavior facilitates Initial Access through Tactic TA0001 and potentially Lateral Movement via Tactic TA0008 depending on how broadly scoped the managed identity permissions are. The core failure lies in CWE-20 Improper Input Validation where the application fails to verify that input parameters conform to expected constraints regarding trusted hosts, allowing an attacker to supply malicious configuration data that alters program flow and security boundaries.
Mitigation for this issue requires immediate action by upgrading Snowflake drivers to patched versions that explicitly restrict the WORKLOAD_IDENTITY authenticator to recognized and verified Snowflake hostnames. Since automatic updates may not be feasible in all environments due to dependency management policies, users must manually upgrade their driver installations across all client systems connecting to Snowflake instances. Additionally, organizations should review their Azure Managed Identity permissions to ensure they adhere to the principle of least privilege, minimizing the blast radius if a token is compromised. Network-level controls such as strict egress filtering and monitoring for unusual authentication patterns can also provide supplementary defense-in-depth measures while driver updates are being deployed across the infrastructure.