CVE-2026-13750: Snowflake CLI Plaintext Credential Leakage in Debug Logs

Technical summary

The vulnerability stems from improper handling of sensitive data in logging routines (CWE-532: Insertion of Sensitive Information into Log Files). Debug logs generated by Snowflake CLI store connection parameters and authentication material in plaintext to the local filesystem, typically in user-accessible directories. An attacker with local file system read permissions can enumerate these logs and extract credentials for Snowflake account access. The attack vector is local (AV:L), requires low privileges (PR:L) to read user-owned files, involves no user interaction (UI:N), and has no scope crossing (S:U). The impact is confidentiality loss (C:H) with no integrity or availability impact. Remediation requires manual upgrade to version 3.19, where sensitive credential fields are either redacted or excluded from debug output.

Business impact

Exposed Snowflake credentials can be used to authenticate against Snowflake accounts without the owner's knowledge, potentially granting attackers query and data exfiltration capabilities, view or modify sensitive datasets, trigger resource-intensive queries to impact billing, or pivot into downstream data pipelines. Organizations relying on Snowflake CLI for automation, data engineering, or administrative tasks face credential compromise risk if machines running the tool are not isolated or if log files are not routinely purged. The impact severity depends on the scope of affected Snowflake accounts and the sensitivity of data they contain.

Affected systems

Snowflake CLI versions prior to 3.19 are affected. This includes all releases up to and including version 3.18. Users on Windows, macOS, and Linux are equally at risk if they have not manually upgraded. The vulnerability does not affect Snowflake's cloud service itself, only the locally-installed CLI tool. Verify your installed version by running `snowflake --version` or checking your installation directory.

Exploitability

Exploitation requires an attacker to already possess local file system read access on the machine running the affected CLI version. This could arise through compromised user accounts, malware with file-read permissions, shared system access, or physical device access. The vulnerability is not remotely exploitable and does not require social engineering or user interaction. Once an attacker reads the log files, credential extraction is trivial. However, the attack is not currently known to be exploited in the wild, and no automated tools are publicly weaponized against this specific leakage pattern.

Remediation

Upgrade Snowflake CLI to version 3.19 or later immediately. The fix removes or redacts sensitive credential material from debug logs. After upgrading, purge or securely delete old log files from affected machines (typically located in ~/.snowflake/logs or equivalent platform-specific paths). Additionally, audit Snowflake account activity logs to detect any unauthorized access during the window in which credentials could have been exposed. Consider rotating any credentials that may have been logged on machines that were potentially compromised or accessible to untrusted parties.

Patch guidance

Visit the Snowflake CLI release page and download version 3.19 or later. Installation methods vary by platform: pip install --upgrade snowflake-cli on Python environments, native installers on Windows, or Homebrew on macOS (brew upgrade snowflake-cli). After installation, verify the version with `snowflake --version`. No configuration changes are required post-upgrade. If you use Snowflake CLI in automated workflows (CI/CD, scheduled scripts), ensure all deployment environments are updated, including development, staging, and production systems. Test upgraded versions in a non-production environment first to confirm compatibility with your workflows.

Detection guidance

Review local log directories on machines running Snowflake CLI (e.g., ~/.snowflake/logs, %APPDATA%\Snowflake\logs on Windows) for plaintext credentials or token-like patterns. Search logs for patterns matching common credential formats (e.g., 'password=', 'token=', 'private_key'). Correlate logs with Snowflake account audit trails to identify whether exposed credentials were used for unauthorized access. Endpoint detection and response (EDR) tools can flag processes spawning the Snowflake CLI with credential arguments. Monitor for repeated login attempts or API calls from unexpected source IPs in Snowflake audit logs, which may indicate credential reuse by an attacker.

Why prioritize this

While the CVSS score is moderate (5.5), the practical impact is significant for organizations with sensitive data in Snowflake. The vulnerability is straightforward to remediate (a single upgrade), and no complex workarounds are required. Prioritize patching machines where Snowflake CLI is used by data engineers, analysts, or DevOps teams—roles with access to high-value credentials. If your organization uses Snowflake CLI in containerized or ephemeral environments, the risk is lower (logs are typically discarded). However, persistent development machines and on-premises data integration servers should be patched within one week of confirming your environment is affected.

Risk score, explained

The CVSS 3.1 score of 5.5 (MEDIUM) reflects the local-only attack vector and requirement for existing file-system privileges, which limits exposure to machines already compromised or accessible to insiders. However, the high confidentiality impact (C:H) accounts for the plaintext exposure of authentication credentials, which are inherently high-value targets. The score does not account for downstream impact if exposed credentials are used to access sensitive Snowflake data; organizational context and data sensitivity should drive internal prioritization above the base score.

Frequently asked questions