Improper input validation of the auto-configuration account identifier in Snowflake JDBC Driver versions 4.2.0 through 4.3.3 allowed a credential-bearing login request to be redirected to an attacker-selected HTTPS endpoint. An attacker able to control the account value could cause the driver to transmit a reusable login credential to a host of their choosing and replay it to obtain the privileges granted to that credential. Successful exploitation requires an application using jdbc:snowflake:auto with a connections.toml section that omits an explicit host and a lower-trust principal able to set the account value; ordinary JDBC URLs are unaffected. The fix is available in Snowflake JDBC Driver version 4.3.4. Users must manually upgrade.

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 the patched versions listed above. 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.

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.

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.

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.

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.

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.

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.

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.

Insertion of sensitive information into log files in Snowflake CLI versions prior to 3.19 allowed plaintext credentials to be written to persistent local debug logs. An attacker could exploit this by obtaining read access to the affected user's local log files, causing credentials such as passwords, tokens, or private key material to be exposed without additional application-level safeguards. Successful exploitation requires credentials to be present in the affected connection context and the resulting logs to be accessible from the local environment. The fix is available in Snowflake CLI version 3.19, and 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 restriction of file path resolution in Snowflake CLI versions prior to 3.19 allowed arbitrary local file content to be read and transmitted to Snowflake services. An attacker could exploit this by supplying crafted repository or project content that referenced files outside the intended project boundary, causing Snowflake CLI to read local files and upload or embed their contents during deployment or SQL template processing. Successful exploitation required the victim to process attacker-controlled project content, and retrieval of exfiltrated data depended on access to the victim's Snowflake account artifacts such as query history or uploaded stage content. The fix is available in Snowflake CLI version 3.19, and users must manually upgrade.

Improper neutralization of local CLI parameters in Snowflake CLI versions prior to 3.19 allowed unintended SQL execution. A user could trigger this issue by supplying crafted values to vulnerable Cortex SQL or object listing command paths, causing Snowflake CLI to execute unintended SQL in the context of that user's Snowflake session. Successful exploitation is constrained to self-injection because the vulnerable parameters were supplied directly through local CLI arguments rather than through project files, repositories, or other external input sources, and impact is limited to the privileges already available to the current session. 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.

A vulnerability has been found in Streamlit up to 1.53.0. Impacted is an unknown function in the library lib/streamlit/runtime/caching/hashing.py of the component Palette Handler. Such manipulation leads to use of weak hash. Local access is required to approach this attack. The attack requires a high level of complexity. The exploitability is considered difficult. The exploit has been disclosed to the public and may be used. The pull request to fix this issue awaits acceptance.

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.

Streamlit Open Source Security Advisory

1. Impacted Products

Streamlit Open Source versions prior to 1.54.0 running on Windows hosts.

2. Introduction

Snowflake Streamlit Open Source addressed a security vulnerability affecting Windows deployments related to improper handling and validation of filesystem paths within component request handling. The vulnerability was reported through the responsible disclosure program and has been remediated in Streamlit Open Source version 1.54.0. This issue affects only Streamlit deployments running on Windows operating systems.

3. Server-Side Request Forgery (SSRF) and NTLM Credential Exposure

3.1 Description

Streamlit was informed by a security researcher of an unauthenticated Server-Side Request Forgery (SSRF) vulnerability. The vulnerability arises from improper validation of attacker-supplied filesystem paths. In certain code paths, including within the ComponentRequestHandler, filesystem paths are resolved using os.path.realpath() or Path.resolve() before sufficient validation occurs.

On Windows systems, supplying a malicious UNC path (e.g., \\attacker-controlled-host\share) can cause the Streamlit server to initiate outbound SMB connections over port 445. When Windows attempts to authenticate to the remote SMB server, NTLMv2 challenge-response credentials of the Windows user running the Streamlit process may be transmitted.

This behavior may allow an attacker to:

- Perform NTLM relay attacks against other internal services - Identify internally reachable SMB hosts via timing analysis

Note: The issue is unauthenticated and does not require user interaction.

Captured NTLMv2 challenge-response hashes could be subjected to offline brute-force attacks in an attempt to recover the associated plaintext account password. While NTLMv2 incorporates a server challenge (nonce) that mitigates the use of precomputed rainbow tables, it does not prevent targeted offline password cracking against weak credentials.

Additionally, Microsoft has publicly discouraged the continued use of NTLM in favor of Kerberos and is actively progressing toward disabling NTLM by default in future Windows releases. Organizations that enforce NTLM restrictions, disable outbound NTLM authentication, require SMB signing, or block NTLM authentication to remote servers can reduce or eliminate the risk associated with credential relay or hash exposure scenarios.

As NTLM is considered legacy and increasingly deprecated (though not fully sunset), environments that have already implemented Microsoft-recommended NTLM hardening controls are less likely to be materially impacted. The overall risk therefore depends on the organization's authentication configuration and network security posture.

3.2 Scenarios and Attack Vectors

Streamlit applications running on Windows were vulnerable if component endpoints were exposed to untrusted networks. By appending an attacker-controlled SMB hostname to the URI path and issuing a GET request, the Streamlit server could be coerced into initiating an outbound SMB authentication attempt.

This could result in the leakage of NTLMv2 credential hashes for the Windows account running the Streamlit process.

3.3 Resolution

- The vulnerability has been fixed in Streamlit Open Source version 1.54.0. - It is recommended that all Streamlit deployments on Windows be upgraded immediately to version 1.54.0 or later.

4. Contact

Please contact security@snowflake.com for any questions regarding this advisory.

If a security vulnerability is discovered in a Streamlit product or website, it should be reported through the responsible disclosure program. For more information, see the Vulnerability Disclosure Policy.

A weakness has been identified in Snowflake JDBC Driver up to 4.0.1. Impacted is the function SdkProxyRoutePlanner of the file src/main/java/net/snowflake/client/internal/core/SdkProxyRoutePlanner.java of the component JDBC URL Handler. Executing a manipulation of the argument nonProxyHosts can lead to inefficient regular expression complexity. The attack can only be executed locally. The exploit has been made available to the public and could be used for attacks. This patch is called 5fb0a8a318a2ed87f4022a1f56e742424ba94052. A patch should be applied to remediate this issue.

libsnowflakeclient is the Snowflake Connector for C/C++. Versions starting from 0.5.0 to before 2.2.0, are vulnerable to local logging of sensitive information. When the logging level was set to DEBUG, the Connector would log locally the client-side encryption master key of the target stage during the execution of GET/PUT commands. This key by itself does not grant access to any sensitive data without additional access authorizations, and is not logged server-side by Snowflake. This issue has been patched in version 2.2.0.

libsnowflakeclient is the Snowflake Connector for C/C++. Versions starting from 0.5.0 to before 2.2.0, incorrectly treat malformed requests that caused the HTTP response status code 400, as able to be retried. This could hang the application until SFCONMAXRETRY requests were sent. This issue has been patched in version 2.2.0.

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 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 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.

In Snowflake ODBC Driver before 3.7.0, in certain code paths, the Driver logged the whole SQL query at the INFO level, aka Insertion of Sensitive Information into a Log File.

Issue Snowflake discovered and remediated a vulnerability in the Snowflake JDBC driver (“Driver”). When the logging level was set to DEBUG, the Driver would log locally the client-side encryption master key of the target stage during the execution of GET/PUT commands. This key by itself does not grant access to any sensitive data without additional access authorizations, and is not logged server-side by Snowflake.

This vulnerability affects Driver versions 3.0.13 through 3.23.0. Snowflake fixed the issue in version 3.23.1.

Vulnerability Details When the logging level was set to DEBUG, the Driver would locally log the client-side encryption master key of the target stage during the execution of GET/PUT commands. The key was logged in a JSON object under the queryStageMasterKey key. The key by itself does not grant access to any sensitive data.

Solution Snowflake released version 3.23.1 of the Snowflake JDBC driver, which fixes this issue. We highly recommend users upgrade to version 3.23.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.

Issue Snowflake discovered and remediated a vulnerability in the Snowflake Connector for Python. On Linux systems, when temporary credential caching is enabled, the Snowflake Connector for Python will cache temporary credentials locally in a world-readable file.

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

Vulnerability Details On Linux, when either EXTERNALBROWSER or USERNAMEPASSWORDMFA authentication methods are used with temporary credential caching enabled, the Snowflake Connector for Python will cache the temporary credentials in a local file. In the vulnerable versions of the Driver, this file is created with world-readable permissions.

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 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.