Improper handling of untrusted remote references in Snowflake CLI versions prior to 3.19 allowed server-side request forgery. The SQL statement reader's !source/!load directives could reference remote URLs that were retrieved at runtime without sufficient restriction on the request destination. By supplying crafted SQL content processed through a vulnerable command path, an attacker could cause the victim's environment to issue unintended outbound requests to internal or otherwise non-public network locations, and could cause remote SQL content to be retrieved and executed in the context of the victim user's session. Successful exploitation requires the victim to process attacker-controlled content through a vulnerable command path and is limited by the privileges available to that session and environment. The fix is available in Snowflake CLI version 3.19, which adds an option to disable remote URL retrieval.

SQL injection vulnerabilities in the Snowflake Snowpark Python SDK (snowpark-python) versions prior to 1.53.0 could allow authenticated low-privilege users to execute SQL beyond their authorization scope. An attacker could exploit these vulnerabilities by embedding SQL payloads in source database column names to escalate privileges via the DataFrameReader.dbapi() API by supplying a specially crafted location parameter to DataFrameWriter write methods to redirect a COPY INTO to an arbitrary source query, or by including a backslash-single-quote sequence in an export path to defeat the normalizepath() sanitizer and inject SQL via DataFrame.tocsv(). Successful exploitation may result in source database compromise, unauthorized cross-tenant data exfiltration, or unauthorized read of Snowflake account data.

Multiple input validation vulnerabilities in the Snowflake Spark Connector (spark-snowflake) versions prior to 3.2.1 can allow attackers to exfiltrate OAuth client credentials, execute arbitrary SQL with the connector's Snowflake role, or redirect COPY operations to attacker-controlled storage. An attacker could exploit these vulnerabilities by supplying a crafted OAuth token request URL, placing malicious files in an ingestion pipeline, injecting SQL via staging options in a shared Spark environment , or issuing runtime SET commands in a shared Spark-SQL session to inject arbitrary SQL into the SnowflakeFallbackCatalog's option map, which executes under the cluster admin's JDBC credentials. Successful exploitation may result in credential theft, unauthorized access to Snowflake account data, or privilege escalation within connected infrastructure.

Improper TLS hostname verification in Snowflake Connector for Python versions prior to 4.7.1 and 3.18.1 may have allowed a network-positioned attacker to bypass certificate hostname validation on HTTPS connections made by the connector. An attacker with on-path network access could exploit this by intercepting or redirecting network traffic and presenting a certificate signed by any trusted CA for any domain, causing the connector to accept connections without validating that the certificate matched the requested hostname. Successful exploitation requires an on-path traffic interception capability (e.g. ARP/DNS poisoning, rogue access point, BGP hijacking, or malicious proxy/exit node). This vulnerability may have exposed credentials, query data, and staged file contents to interception and tampering, and may have enabled the attacker to issue arbitrary SQL within the context of the victim's connector session. Impact is limited by the privileges of the affected Snowflake role. The fix is available in Snowflake Connector for Python versions 4.7.1 and 3.18.1. Users must manually upgrade.

Improper neutralization in the Snowpark annotation processor callback template in Snowflake CLI versions prior to 3.19 allowed arbitrary code execution during application bundling or deployment. An attacker could exploit this by supplying crafted project content that is interpolated into generated Python code, causing Snowflake CLI to execute attacker-controlled code in the local context of the user running the CLI. Successful exploitation requires the victim to run the relevant bundling or deployment workflow against attacker-controlled project content, and any resulting code runs with the privileges of that local execution context. The fix is available in Snowflake CLI version 3.19, and users must manually upgrade.

Improper neutralization of attacker-controlled content in Snowflake CLI versions prior to 3.19 allowed unintended SQL execution. By supplying crafted repository content, project configuration, manifest data, or specification input, an attacker could cause Snowflake CLI to execute unintended SQL in the context of the victim user's Snowflake session. Successful exploitation requires the victim to process attacker-controlled content through a vulnerable command path and is limited by the privileges assigned to that session. The fix is available in Snowflake CLI version 3.19. Users must manually upgrade.

Snowflake Terraform Provider versions prior to 2.18.0 contain several security vulnerabilities, including SQL injection via an unsanitized data source input could result in arbitrary SQL execution under the provider's privileged Snowflake session, potentially enabling sensitive data exfiltration and minting of long-lived access credentials. Exploitation requires the ability for an attacker to influence a workspace variable in a pipeline where this data source was enabled. Improper neutralization of identifier content in user resource inputs could allow DDL injection into user management statements, potentially causing accounts to be created with attacker-controlled credentials and without the security controls configured by the operator. The fix is available in Snowflake Terraform Provider version 2.18.0. Users must manually upgrade.

Multiple security vulnerabilities in Snowflake libsnowflakeclient versions prior to 2.9.2 could allow remote code execution and credential exfiltration. A stack-based buffer overflow in the file download path could allow remote code execution on a victim host. An attacker could exploit this by uploading a file with a crafted encryption metadata field to a shared internal stage that a victim process later downloads, and impact would be limited to deployments where principals with different privilege levels share the same internal stage. A related out-of-bounds write in the same download path could allow memory corruption with attacker-controlled write primitives. An attacker may exploit this through a crafted initialization vector metadata field on a shared stage, and impact would be limited by the same stage-write precondition. Improper validation of connection parameters could allow an attacker-controlled input to redirect outbound authentication requests — including credentials and tokens — to an attacker-controlled endpoint. Impact is limited to embedding deployments where a lower-privileged principal can influence connection configuration while higher-privileged service credentials are in use. The fix is available in Snowflake libsnowflakeclient version 2.9.2. The Snowflake PHP PDO Driver and Snowflake ODBC Driver embed the affected library; fixes are available in versions 4.1.0 and 3.19.0 respectively. Users must manually upgrade.

Snowflake Computing Snowflake JDBC could allow a remote authenticated attacker to execute arbitrary commands on the system, caused by a command injection flaw in the SSO URL authentication. By persuading a victim to connect to a specially crafted server, an attacker could exploit this vulnerability to execute arbitrary commands on the system.

Issue Snowflake was informed via our bug bounty program of a command injection vulnerability in the Snowflake Python connector via SSO browser URL authentication.

Impacted driver package: snowflake-connector-python

Impacted version range: before Version 3.0.2

Attack Scenario In order to exploit the potential for command injection, an attacker would need to be successful in (1) establishing a malicious resource and (2) redirecting users to utilize the resource. The attacker could set up a malicious, publicly accessible server which responds to the SSO URL with an attack payload. If the attacker then tricked a user into visiting the maliciously crafted connection URL, the user’s local machine would render the malicious payload, leading to a remote code execution.

This attack scenario can be mitigated through URL whitelisting as well as common anti-phishing resources.

Solution On March 23rd, 2023, Snowflake merged a patch that fixed a command injection vulnerability in the Snowflake Python connector via SSO browser URL authentication. The vulnerability affected the Snowflake Python connector before Version 3.0.2. We strongly recommend users upgrade to Version 3.0.2 as soon as possible via the following resources: Snowflake Python Connector

Additional Information If you discover a security vulnerability in one of our products or websites, please report the issue to HackerOne. For more information, please see our Vulnerability Disclosure Policy.

Issue Snowflake was informed via our bug bounty program of a command injection vulnerability in the Snowflake .NET driver via SSO URL authentication.

Impacted driver package: snowflake-connector-net

Impacted version range: before Version 2.0.18

Attack Scenario In order to exploit the potential for command injection, an attacker would need to be successful in (1) establishing a malicious resource and (2) redirecting users to utilize the resource. The attacker could set up a malicious, publicly accessible server which responds to the SSO URL with an attack payload. If the attacker then tricked a user into visiting the maliciously crafted connection URL, the user’s local machine would render the malicious payload, leading to a remote code execution.

This attack scenario can be mitigated through URL whitelisting as well as common anti-phishing resources.

Solution On December 2nd, 2022, Snowflake merged a patch that fixed a command injection vulnerability in the Snowflake .NET driver via SSO URL authentication. The vulnerability affected the Snowflake .NET driver before Version 2.0.18. We strongly recommend upgrading to the latest driver version as soon as possible via the following resources: Snowflake .NET Driver.

Additional Information If you discover a security vulnerability in one of our products or websites, please report the issue to HackerOne. For more information, please see our Vulnerability Disclosure Policy.

Issue Snowflake was informed via our bug bounty program of a command injection vulnerability in the Snowflake Golang driver via SSO browser URL authentication.

Impacted driver package: gosnowflake

Impacted version range: before Version 1.6.19

Attack Scenario In order to exploit the potential for command injection, an attacker would need to be successful in (1) establishing a malicious resource and (2) redirecting users to utilize the resource. The attacker could set up a malicious, publicly accessible server which responds to the SSO URL with an attack payload. If the attacker then tricked a user into visiting the maliciously crafted connection URL, the user’s local machine would render the malicious payload, leading to a remote code execution.

This attack scenario can be mitigated through URL whitelisting as well as common anti-phishing resources.

Solution On March 21, 2023, Snowflake merged a patch that fixed a command injection vulnerability in the Snowflake Golang driver via SSO browser URL authentication. The vulnerability affected the Snowflake Golang driver before Version 1.6.19. We strongly recommend users upgrade to Version 1.6.19 as soon as possible via the following resources: Go Snowflake Driver

Additional Information If you discover a security vulnerability in one of our products or websites, please report the issue to HackerOne. For more information, please see our Vulnerability Disclosure Policy.

Issue Snowflake was informed via our bug bounty program of a command injection vulnerability in the Snowflake NodeJS driver via SSO browser URL authentication.

Impacted driver package: snowflake-connector-nodejs

Impacted version range: before Version 1.6.21

Attack Scenario In order to exploit the potential for command injection, an attacker would need to be successful in (1) establishing a malicious resource and (2) redirecting users to utilize the resource. The attacker could set up a malicious, publicly accessible server which responds to the SSO URL with an attack payload. If the attacker then tricked a user into visiting the maliciously crafted connection URL, the user’s local machine would render the malicious payload, leading to a remote code execution.

This attack scenario can be mitigated through URL whitelisting as well as common anti-phishing resources.

Solution On April 18, 2023, Snowflake merged a patch that fixed a command injection vulnerability in the Snowflake NodeJS driver via SSO browser URL authentication. The vulnerability affected the Snowflake NodeJS driver before Version 1.6.21. We strongly recommend users upgrade to Version 1.6.21 as soon as possible via the following resources: Snowflake NodeJS Driver

Additional Information If you discover a security vulnerability in one of our products or websites, please report the issue to HackerOne. For more information, please see our Vulnerability Disclosure Policy.

Improper validation of bash commands in Snowflake Cortex Code CLI versions prior to 1.0.25 allowed subsequent commands to execute outside the sandbox. An attacker could exploit this by embedding specially crafted commands in untrusted content, such as a malicious repository, causing the CLI agent to execute arbitrary code on the local device without user consent. Exploitation is non-deterministic and model-dependent. The fix is automatically applied upon relaunch with no user action required.

In affected Snowflake drivers, WORKLOADIDENTITY 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 WORKLOADIDENTITY 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.

Improper input validation in Snowflake CLI versions prior to 3.27.0 allowed unsanitized user-controlled values to be interpolated into SQL strings that are executed as multi-statement queries. An attacker who is able to supply a malicious project configuration file or craft command-line input can cause Snowflake CLI to execute attacker-controlled SQL statements in the context of the victim's Snowflake session and active role. Successful exploitation requires either write or pull-request access to a project repository whose CI/CD pipeline runs Snowflake CLI under an elevated service account role, or the ability to supply untrusted input to CLI-wrapping automation. Impact is limited by the privileges held by the configured Snowflake role at execution time. The fix is available in Snowflake CLI version 3.27.0, which also addresses several additional security findings. Users must manually upgrade.

Insufficient input sanitization in Snowflake Python API (snowflake.core) versions prior to 1.13.0 allowed confused-deputy privilege escalation through two related weaknesses: path traversal (CWE-22) via unencoded .. identifier path segments, and HTTP parameter pollution (CWE-141) via unencoded &/#/= characters in query string values. An attacker with access to a downstream application built on snowflake.core could exploit the path traversal by supplying .. as an object name, causing snowflake.core to issue REST requests against a parent resource or exploit the parameter pollution by injecting &/#/= into a free-form name field to override constraints on swap, clone, or rename operations — all executed under the application's privileged session. Successful exploitation requires the attacker to control an identifier or object-name string in an application built on snowflake.core that passes it to snowflake.core under a higher-privileged Snowflake session (e.g., an EXECUTE AS OWNER stored procedure, Streamlit app, or Native App). The fix is available in Snowflake Python API version 1.13.0, which also addresses several additional security findings. Users must manually upgrade.

Improper neutralization of parameters in Snowflake CLI versions prior to 3.19 allowed unintended SQL execution. An attacker could exploit this by supplying crafted values to vulnerable command paths, causing Snowflake CLI to execute unintended SQL in the context of the user’s Snowflake session. Successful exploitation required crafted values to reach vulnerable parameters, including through socially engineered input, malicious repository configuration, or compromised automation feeding external values into the CLI, and impact is limited by the privileges assigned to the active session. The fix is available in Snowflake CLI version 3.19, and users must manually upgrade.

Issue Snowflake discovered and remediated a vulnerability in the Snowflake JDBC Driver. When the EXTERNALBROWSER authentication method is used on Windows, an attacker with write access to a directory in the %PATH% can escalate their privileges to the user that runs the vulnerable JDBC Driver version.

This vulnerability affects versions 3.2.3 through 3.21.0 on Windows. Snowflake fixed the issue in version 3.22.0.

Vulnerability Details When the EXTERNALBROWSER authentication method is selected, the Snowflake JDBC Driver on non-macOS operating systems tries to open the SSO URL using xdg-open. Because xdg-open is a Linux program that doesn’t exist in a default Windows installation, a sufficiently privileged attacker could place a malicious executable in one of the directories on the %PATH% and achieve local privilege escalation to the user running the JDBC Driver.

Solution Snowflake released version 3.22.0 of the Snowflake JDBC Driver, which fixes this issue. We recommend users upgrade to version 3.22.0.

Additional Information If you discover a security vulnerability in one of our products or websites, please report the issue to HackerOne. For more information, please see our Vulnerability Disclosure Policy.

Issue Snowflake discovered and remediated a vulnerability in the Snowflake Connector for Python. The OCSP response cache uses pickle as the serialization format, potentially leading to local privilege escalation.

This vulnerability affects versions 2.7.12 through 3.13.0. Snowflake fixed the issue in version 3.13.1.

Vulnerability Details The OCSP response cache is saved locally on the machine running the Connector using the pickle serialization format. This can potentially lead to local privilege escalation if an attacker has write access to the OCSP response cache file.

Solution Snowflake released version 3.13.1 of the Snowflake Connector for Python, which fixes this issue. We recommend users upgrade to version 3.13.1.

Additional Information If you discover a security vulnerability in one of our products or websites, please report the issue to HackerOne. For more information, please see our Vulnerability Disclosure Policy.

An exponential ReDoS (Regular Expression Denial of Service) can be triggered in the snowflake-connector-python PyPI package, when an attacker is able to supply arbitrary input to the getfiletransfertype method.

SQL injection vulnerability in the T3BLOG extension 0.6.2 and earlier for TYPO3 allows remote attackers to execute arbitrary SQL commands via unspecified vectors.

Issue Snowflake recently received a report about a vulnerability in the Snowflake Connector .NET where the checks against the Certificate Revocation List (CRL) were not performed where the insecureMode flag was set to false, which is the default setting. The vulnerability affects versions between 2.0.25 and 2.1.4 (inclusive). Snowflake fixed the issue in version 2.1.5.

Attack Scenario Snowflake uses CRL to check if a TLS certificate has been revoked before its expiration date. The lack of correct validation of revoked certificates could, in theory, allow an attacker who has both access to the private key of a correctly issued Snowflake certificate and the ability to intercept network traffic to perform a Man-in-the-Middle (MitM) attack in order to compromise Snowflake credentials used by the driver.

The vulnerability is difficult to exploit given both conditions required and, at the time of this advisory's publication, Snowflake is not aware of any compromise of its certificates, nor unauthorized issuance of such by any publicly trusted Certificate Authority (CA). However, an upgrade to the newest version is recommended to ensure the highest level of security and protection against future unforeseen threats.

Solution On December 18, 2023, Snowflake released version 2.1.5 of the Snowflake Connector .NET, which fixes the issue, and we recommend users upgrade to version 2.1.5. Customers continuing to use the impacted versions of the connector should update their insecureMode flag to true.

Acknowledgement Snowflake would like to thank Timo Vink for reporting this vulnerability.

Additional Information If you discover a security vulnerability in one of our products or websites, please report the issue to HackerOne. For more information, please see our Vulnerability Disclosure Policy.

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. Successful exploitation requires that on-path position and the corresponding private key, and impact is limited to data carried within the intercepted connection. The fix is available in Snowflake Connector for Python v4.7.3, Snowflake Go Driver v2.2.0, Snowflake JDBC Driver v4.3.4 (including the snowflake-jdbc-fips and snowflake-jdbc-thin), and Snowflake Node.js Driver v3.3.0. Users must manually upgrade.

Issue Snowflake discovered and remediated a vulnerability in the Snowflake Connector for Python. A function from the snowflake.connector.pandastools module is vulnerable to SQL injection.

This vulnerability affects versions 2.2.5 through 3.13.0. Snowflake fixed the issue in version 3.13.1.

Vulnerability Details A function from the snowflake.connector.pandastools module is not sanitizing all of its arguments, and queries using them are not parametrized. An attacker controlling these arguments could achieve SQL injection by passing crafted input. Any SQL executed that way by an attacker would still run in the context of the current session.

Solution Snowflake released version 3.13.1 of the Snowflake Connector for Python, which fixes this issue. We recommend users upgrade to version 3.13.1.

Additional Information If you discover a security vulnerability in one of our products or websites, please report the issue to HackerOne. For more information, please see our Vulnerability Disclosure Policy.

Issue Snowflake discovered and remediated a vulnerability in the Go Snowflake Driver (“Driver”). When using the Easy Logging feature on Linux and macOS, the Driver didn’t correctly verify the permissions of the logging configuration file, potentially allowing an attacker with local access to overwrite the configuration and gain control over logging level and output location.

This vulnerability affects Driver versions from 1.7.0 up to, but not including, 1.13.3. Snowflake fixed the issue in version 1.13.3.

Vulnerability Details When using the Easy Logging feature on Linux and macOS, the Driver reads logging configuration from a user-provided file. On Linux and macOS the Driver verifies that the configuration file can be written to only by its owner. That check was vulnerable to a Time-of-Check to Time-of-Use (TOCTOU) race condition and failed to verify that the file owner matches the user running the Driver. This could allow a local attacker with write access to the configuration file or the directory containing it to overwrite the configuration and gain control over logging level and output location.

Solution Snowflake released version 1.13.3 of the Go Snowflake Driver, which fixes this issue. We recommend users upgrade to version 1.13.3.

Additional Information If you discover a security vulnerability in one of our products or websites, please report the issue to Snowflake through our Vulnerability Disclosure Program hosted at HackerOne. For more information, please see our Vulnerability Disclosure Policy.

Issue Snowflake discovered and remediated a vulnerability in the NodeJS Driver for Snowflake (“Driver”). When using the Easy Logging feature on Linux and macOS the Driver didn’t correctly verify the permissions of the logging configuration file, potentially allowing an attacker with local access to overwrite the configuration and gain control over logging level and output location.

This vulnerability affects Driver versions 1.10.0 through 2.0.3. Snowflake fixed the issue in version 2.0.4.

Vulnerability Details When using the Easy Logging feature on Linux and macOS the Driver reads logging configuration from a user-provided file. On Linux and macOS the Driver verifies that the configuration file can be written to only by its owner. That check was vulnerable to a Time-of-Check to Time-of-Use (TOCTOU) race condition and failed to verify that the file owner matches the user running the Driver. This could allow a local attacker with write access to the configuration file or the directory containing it to overwrite the configuration and gain control over logging level and output location.

Solution Snowflake released version 2.0.4 of the NodeJS Driver for Snowflake, which fixes this issue. We recommend users upgrade to version 2.0.4.

Additional Information If you discover a security vulnerability in one of our products or websites, please report the issue to Snowflake through our Vulnerability Disclosure Program hosted at HackerOne. For more information, please see our Vulnerability Disclosure Policy.

Issue Snowflake discovered and remediated a vulnerability in the Snowflake Connector for .NET (“Connector”). When using the Easy Logging feature on Linux and macOS, the Connector didn’t correctly verify the permissions of the logging configuration file, potentially allowing an attacker with local access to overwrite the configuration and gain control over logging level and output location.

This vulnerability affects Connector versions 2.1.2 through 4.4.0. Snowflake fixed the issue in version 4.4.1.

Vulnerability Details When using the Easy Logging feature on Linux and macOS, the Connector reads logging configuration from a user-provided file. On Linux and macOS, the Connector verifies that the configuration file can be written to only by its owner. That check was vulnerable to a Time-of-Check to Time-of-Use (TOCTOU) race condition and failed to verify that the file owner matches the user running the Connector. This could allow a local attacker with write access to the configuration file or the directory containing it to overwrite the configuration and gain control over logging level and output location.

Solution Snowflake released version 4.4.1 of the Snowflake Connector for .NET, which fixes this issue. We recommend users upgrade to version 4.4.1.

Additional Information If you discover a security vulnerability in one of our products or websites, please report the issue to Snowflake through our Vulnerability Disclosure Program hosted at HackerOne. For more information, please see our Vulnerability Disclosure Policy.

1. Impacted Products Streamilt Open Source versions before 1.37.0.

2. Introduction Snowflake Streamlit open source addressed a security vulnerability via the static file sharing feature. The vulnerability was patched on Jul 25, 2024, as part of Streamlit open source version 1.37.0. The vulnerability only affects Windows.

3. Path Traversal Vulnerability 3.1 Description On May 12, 2024, Streamlit was informed via our bug bounty program about a path traversal vulnerability in the open source library. We fixed and merged a patch remediating the vulnerability on Jul 25, 2024. The issue was determined to be in the moderate severity range with a maximum CVSSv3 base score of 5.9 3.2 Scenarios and attack vector(s) Users of hosted Streamlit app(s) on Windows were vulnerable to a path traversal vulnerability when the static file sharing feature is enabled. An attacker could utilize the vulnerability to leak the password hash of the Windows user running Streamlit. 3.3 Resolution The vulnerability has been fixed in all Streamlit versions released since Jul 25, 2024. We recommend all users upgrade to Version 1.37.0.

4. Contact Please contact security@snowflake.com if you have any questions regarding this advisory. If you discover a security vulnerability in one of our products or websites, please report the issue to HackerOne. For more information, please see our Vulnerability Disclosure Policy.

Insertion of sensitive information into log files in the 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 in circumstances where the available log redaction did not cover all affected log paths and data types. An attacker with read access to the log destination, whether the local filesystem, a log aggregation service, or a CI/CD artifact store, could obtain credentials and decryption keys that, if still valid at the time of access, could be used to authenticate to the corresponding Snowflake account or cloud-storage object. Successful exploitation requires read access to the log destination, and impact is bounded by credential lifetime and object scope. The fix is available in Snowflake Connector for Python v4.7.3, Snowflake Go Driver v2.2.0, Snowflake JDBC Driver v4.3.4 (including the snowflake-jdbc-fips and snowflake-jdbc-thin), Snowflake Node.js Driver v3.3.0, Snowflake PHP PDO Driver v4.2.0, and Snowflake ODBC Driver v3.20.0. Users must manually upgrade and should securely delete previously generated diagnostic logs containing sensitive information where retention is not required.