Snowflake drivers can expose workload identity tokens to attacker-controlled hosts

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.

• Snowflake Connector for Python: package snowflake-connector-python, from 3.14.1 to less than 4.7.3 is affected. The record identifies 4.7.3 as patched.
• Snowflake Go Driver, v1: package github.com/snowflakedb/gosnowflake, from 1.15.0 through 1.19.1 is affected. The record does not provide a specific patched release for the v1 branch.
• Snowflake Go Driver, v2: package github.com/snowflakedb/gosnowflake/v2, from 2.0.0 to less than 2.2.0 is affected. The identified patched release is 2.2.0.
• Snowflake JDBC Driver, including the standard, FIPS, and Thin artifacts: from 3.24.0 to less than 4.3.4 is affected. The identified patched release is 4.3.4.
• Snowflake Node.js Driver: package snowflake-sdk, from 2.1.1 to less than 3.3.0 is affected. The identified patched release is 3.3.0.
• Snowflake Connector for.NET: package Snowflake.Data, from 4.7.0 to less than 6.1.0 is affected. The identified patched release is 6.1.0.
• Snowflake ODBC Driver: from 3.9.0 to less than 3.20.0 is affected. The identified patched release is 3.20.0.
• Snowflake PHP PDO Driver: from 3.6.0 to less than 4.2.0 is affected. The identified patched release is 4.2.0.
• Snowflake Libsnowflakeclient: from 2.2.0 to less than 2.10.0 is affected. The identified patched release is 2.10.0.
• Releases outside the boundaries listed above should not be inferred to be safe unless they belong to a branch confirmed by the vendor.

In affected Snowflake drivers, the WORKLOAD_IDENTITY authenticator obtains a cloud workload-identity attestation and attaches it to the login request before verifying that the destination host is a Snowflake endpoint. If an attacker can modify the connection configuration, the driver can mint a fresh attestation and send it to a host controlled by the attacker. The captured token can be replayed to Snowflake for its remaining lifetime when the workload identity is already registered in the relevant Snowflake account. On Azure, the token audience is also taken from the connection configuration, so an attacker-controlled host can cause the driver to request a Managed Identity access token for a non-Snowflake Azure resource and deliver it to the attacker. This is the only described path that extends impact beyond Snowflake, and it remains bounded by the token lifetime and the managed identity's permissions. The available evidence does not identify specific internal functions or code paths beyond the WORKLOAD_IDENTITY flow occurring before host validation.

• The attack can be triggered through a network-reachable connection path, but the attacker must first be able to modify the connection configuration.
• Exploitation requires the driver to use WORKLOAD_IDENTITY on a workload that already has an ambient cloud identity. The supplied vector describes low required privileges, high attack complexity, and no user interaction.
• Once the conditions are met, the driver creates the attestation and sends it to the configured host, so no additional user confirmation is required during the connection.
• The supplied record marks public_exploit as false and does not mark the issue as known exploited. That is the status of the available record, not proof that exploitation has never occurred.

The flaw turns the driver into a confused deputy: it uses the workload's ambient cloud identity to create a credential and then sends that credential to the host specified by the connection configuration. An attacker may replay the captured token to access Snowflake for the token's remaining lifetime when the identity is registered in the target account. The access and data-change capability is limited by the Snowflake roles assigned to that identity. On Azure, configuring an appropriate audience may produce a token for a non-Snowflake Azure resource, but that outcome remains bounded by the token lifetime and the managed identity's permissions. The available evidence does not establish arbitrary code execution, service disruption, or privileges beyond those already granted to the identity.

• A stolen workload identity token may allow access to Snowflake accounts where that identity is registered, with the permissions assigned to the identity. This can expose data or permit changes to Snowflake data and objects that the identity is authorized to access.
• On Azure, a Managed Identity token with an audience for a non-Snowflake resource may extend the impact to another Azure resource. That possibility is limited by the token lifetime and the managed identity's permissions.
• Investigation may need to cover multiple workloads, connection profiles, and cloud identities, particularly where configuration is distributed through files, secrets, or deployment systems.
• The record does not establish service disruption. The actual data and access consequences depend on the Snowflake roles and cloud permissions associated with the workload identity.

1. Manually upgrade to a patched release for the driver branch in use:

• snowflake-connector-python: upgrade to 4.7.3.
• github.com/snowflakedb/gosnowflake/v2: upgrade to 2.2.0.
• Snowflake JDBC Driver, FIPS, or Thin: upgrade to 4.3.4.
• snowflake-sdk: upgrade to 3.3.0.
• Snowflake.Data: upgrade to 6.1.0.
• Snowflake ODBC Driver: upgrade to 3.20.0.
• Snowflake PHP PDO Driver: upgrade to 4.2.0.
• Snowflake Libsnowflakeclient: upgrade to 2.10.0.

1. For Snowflake Go Driver v1, the record identifies versions 1.15.0 through 1.19.1 as affected but does not state a specific patched release. Do not assume another v1 release is safe without Snowflake confirmation. Obtain a v1 release containing the host-validation fix from the vendor or move to a branch confirmed as patched.
2. If an immediate upgrade is not possible, temporarily disable WORKLOAD_IDENTITY where practical or prevent untrusted sources from changing the host and related values in the connection configuration. This is an interim mitigation, not a replacement for upgrading.
3. Keep host validation limited to recognized Snowflake hosts. Use SNOWFLAKE_WIF_ALLOWED_HOST_SUFFIXES only for controlled internal suffixes that have been deliberately approved, and do not permit attacker-controlled values.
4. If an attestation or token may have been sent to an untrusted host, investigate connection and cloud audit logs, assess the related Snowflake roles and cloud permissions, and follow the organization's identity incident-response process for revocation, replacement, or restriction.

• Inventory all deployed Snowflake drivers, identifying the package, driver branch, and installed version for each workload.
• Find connection profiles or DSNs that use WORKLOAD_IDENTITY, especially on workloads with ambient AWS, Azure, or Google Cloud identities.
• Check whether configured hosts belong to trusted Snowflake hosts. Review SNOWFLAKE_WIF_ALLOWED_HOST_SUFFIXES and confirm that no suffix from an untrusted source has been added.
• For JDBC deployments, review for WORKLOAD_IDENTITY_FLOW_ERROR and the rejected host value when that diagnostic is logged.
• Review proxy, DNS, egress, and cloud audit logs for login requests or cloud identity requests sent to unexpected hosts. This is precautionary monitoring, and the absence of relevant logs does not prove that a workload is safe.
• On Azure, review Managed Identity token requests for an audience or target resource that is not Snowflake. Visibility depends on the logging enabled in the environment.