Snowflake drivers vulnerabilities

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.

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.

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.