CVE-2026-86600
HighCVSS 8.2Summary
In affected Snowflake drivers, WORKLOAD_IDENTITY authentication attaches a cloud workload-identity token to the login request without verifying the configured host is a Snowflake endpoint. An attacker who can modify connection configuration can cause the token to be sent to a host they control. The captured token can be replayed to Snowflake for its remaining lifetime. On Azure, the token audience is also taken from connection configuration, potentially allowing access to non-Snowflake resources.
Risk Assessment
Token capture and replay could lead to unauthorized access to Snowflake data or, in Azure scenarios, to cloud resources. However, exploitation requires the attacker to modify connection configuration.
Recommendation
Manually upgrade Snowflake drivers to patched versions that restrict WORKLOAD_IDENTITY authentication to recognized Snowflake hosts. Additionally, secure connection configuration against unauthorized changes.
Other vulnerabilities in Snowflake drivers
See all- CVE-2026-86597Medium
Insertion of sensitive information into log files in Snowflake Python, Go, JDBC, Node.js, PHP PDO, and ODBC drivers allowed authentication tokens, query-result encryption keys, pre-signed cloud-storage URLs, and SAML assertions to be written to diagnostic logs where log redaction did not cover all paths and data types. An attacker with read access to logs could obtain credentials and decryption keys, potentially authenticating to Snowflake or cloud storage. Exploitation requires read access to logs; impact is bounded by credential lifetime and object scope. Fix available in patched versions. Users must manually upgrade and securely delete previously generated diagnostic logs containing sensitive information if retention is not required.
- CVE-2026-85525High
Improper OCSP response validation in the Snowflake Python, Go, JDBC, and Node.js drivers allowed a revoked TLS certificate to be accepted as valid, because OCSP responses were not reliably bound to the certificate being validated and definitive verification failures were treated as transient. A man-in-the-middle attacker holding a revoked certificate and its private key for a Snowflake or stage hostname could cause the driver to establish a TLS session to the attacker-controlled endpoint anyway, allowing the attacker to read and modify data transmitted within that connection.
Original NVD description (English source)
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.