Snowflake Jdbc Driver
Monthly
Workload Identity Federation authentication in all major Snowflake client drivers transmits cloud attestation tokens to the configured host without first verifying that host is a recognized Snowflake endpoint, enabling token exfiltration and replay. An attacker who can modify connection configuration redirects the driver to an attacker-controlled server, which receives a freshly minted cloud workload-identity token that can be replayed against real Snowflake accounts for the token's remaining lifetime. On Azure, the attack surface is wider: the driver also fetches a Managed Identity access token scoped to an arbitrary Azure resource chosen by the attacker, extending potential impact beyond Snowflake to any Azure service that workload identity can reach. No public exploit has been identified at time of analysis, but vendor-confirmed patches were released September 3, 2026 across all eight affected driver packages.
Improper OCSP response validation across the Snowflake Python, Go, JDBC, and Node.js drivers allowed a revoked TLS certificate to be treated as valid, enabling a man-in-the-middle attacker to intercept and tamper with driver-to-Snowflake TLS sessions. The root flaw is twofold: OCSP stapled or fetched responses were not reliably bound to the specific certificate under validation, and definitive OCSP verification failures were treated as transient errors (soft-fail), causing the driver to proceed with a connection rather than abort it. Exploitation requires a network-adjacent or on-path position combined with possession of a revoked certificate and its corresponding private key for a Snowflake or storage-stage hostname; no public exploit is identified at time of analysis and EPSS data was not provided, but the CVSS AC:H reflects these steep prerequisites.
Sensitive credential material - including authentication tokens, query-result encryption keys, pre-signed cloud-storage URLs, and SAML assertions - was written to diagnostic log files across six Snowflake client drivers (Python, Go, JDBC, Node.js, PHP PDO, and ODBC) due to incomplete log-redaction coverage. An attacker with read access to the log destination, whether a local filesystem, a log aggregation pipeline, or a CI/CD artifact store, can extract valid credentials and decryption keys. Exploitation impact is bounded by credential lifetime and object scope, but successful use of harvested tokens provides authenticated access to the corresponding Snowflake account or cloud-storage objects. No public exploit is identified at time of analysis; vendor-released patches are available for all six drivers as of September 3, 2026.
Credential redirect vulnerability in Snowflake JDBC Driver 4.2.0-4.3.3 allows a lower-trust principal who can control the account identifier to cause the driver to transmit login credentials to an attacker-chosen HTTPS endpoint rather than Snowflake's legitimate servers. The attack is exclusively exercisable through the jdbc:snowflake:auto connection scheme when the connections.toml configuration omits an explicit host value; applications using ordinary JDBC URLs are entirely unaffected. Captured credentials are reusable and can be replayed against Snowflake infrastructure to gain the full privileges of the victimized account. Vendor-released patch 4.3.4 is available and requires manual upgrade; no public exploit or CISA KEV listing has been identified at time of analysis.
Workload Identity Federation authentication in all major Snowflake client drivers transmits cloud attestation tokens to the configured host without first verifying that host is a recognized Snowflake endpoint, enabling token exfiltration and replay. An attacker who can modify connection configuration redirects the driver to an attacker-controlled server, which receives a freshly minted cloud workload-identity token that can be replayed against real Snowflake accounts for the token's remaining lifetime. On Azure, the attack surface is wider: the driver also fetches a Managed Identity access token scoped to an arbitrary Azure resource chosen by the attacker, extending potential impact beyond Snowflake to any Azure service that workload identity can reach. No public exploit has been identified at time of analysis, but vendor-confirmed patches were released September 3, 2026 across all eight affected driver packages.
Improper OCSP response validation across the Snowflake Python, Go, JDBC, and Node.js drivers allowed a revoked TLS certificate to be treated as valid, enabling a man-in-the-middle attacker to intercept and tamper with driver-to-Snowflake TLS sessions. The root flaw is twofold: OCSP stapled or fetched responses were not reliably bound to the specific certificate under validation, and definitive OCSP verification failures were treated as transient errors (soft-fail), causing the driver to proceed with a connection rather than abort it. Exploitation requires a network-adjacent or on-path position combined with possession of a revoked certificate and its corresponding private key for a Snowflake or storage-stage hostname; no public exploit is identified at time of analysis and EPSS data was not provided, but the CVSS AC:H reflects these steep prerequisites.
Sensitive credential material - including authentication tokens, query-result encryption keys, pre-signed cloud-storage URLs, and SAML assertions - was written to diagnostic log files across six Snowflake client drivers (Python, Go, JDBC, Node.js, PHP PDO, and ODBC) due to incomplete log-redaction coverage. An attacker with read access to the log destination, whether a local filesystem, a log aggregation pipeline, or a CI/CD artifact store, can extract valid credentials and decryption keys. Exploitation impact is bounded by credential lifetime and object scope, but successful use of harvested tokens provides authenticated access to the corresponding Snowflake account or cloud-storage objects. No public exploit is identified at time of analysis; vendor-released patches are available for all six drivers as of September 3, 2026.
Credential redirect vulnerability in Snowflake JDBC Driver 4.2.0-4.3.3 allows a lower-trust principal who can control the account identifier to cause the driver to transmit login credentials to an attacker-chosen HTTPS endpoint rather than Snowflake's legitimate servers. The attack is exclusively exercisable through the jdbc:snowflake:auto connection scheme when the connections.toml configuration omits an explicit host value; applications using ordinary JDBC URLs are entirely unaffected. Captured credentials are reusable and can be replayed against Snowflake infrastructure to gain the full privileges of the victimized account. Vendor-released patch 4.3.4 is available and requires manual upgrade; no public exploit or CISA KEV listing has been identified at time of analysis.