Improper neutralization of parameters in Snowflake CLI versions prior to 3

CVE-2026-13752 is an *improper input neutralization* (CWE-89) flaw in the Snowflake CLI (snow) prior to 3.19. When the CLI processes certain user-supplied parameters — likely in YAML spec files, --variable substitutions, or identifier handling consistent with other 2026 Snowflake CLI fixes — the values are interpolated into the SQL sent to Snowflake without proper escaping. A crafted parameter value (e.g. embedding $$, single quotes, or identifier separators) can break out of the intended literal/identifier context and append attacker-chosen SQL that executes under the invoking user's Snowflake role.

Vendor scored this MEDIUM (6.0) with vector AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:N. That vector is honest: local attack, high complexity, requires the victim to run the CLI on attacker-influenced input. In practice this is a *trojaned project file* or *malicious teammate* threat model, not a remote pwn. For a defender managing 10,000 hosts, this is a developer-laptop / CI-runner concern with a narrow blast radius — Snowflake's MEDIUM is slightly hot for the typical deployment, hence the downgrade to LOW.

Why this verdict

• Local + UI:R + AC:H — three friction multipliers stacked. Attacker must place a file, get the victim to run a specific CLI command against it, and have the payload survive any review.
• Blast radius is role-scoped. Damage equals what the victim's Snowflake role can already do. Shops following Snowflake's documented least-privilege model (functional roles, no default ACCOUNTADMIN) contain this to a single dataset.
• Role multiplier: if a CI/CD service account running snow holds ACCOUNTADMIN or SECURITYADMIN, the chain ends in tenant-wide takeover of the Snowflake account. However, the affected component (CLI binary) is *not canonically* a high-value-role component the way a hypervisor or DC is — the high-value role share is well under 10% of installs (most snow invocations are interactive developer sessions with scoped roles), so the CRITICAL floor does not trip. HIGH floor also does not trip because the high-privilege-CI-account population is itself a minority of installs AND requires the trojaned-input prerequisite.
• No remote vector, no KEV, no PoC, no listener for scanners to find. EPSS will sit near zero.

Why not higher?

MEDIUM would be defensible if the CLI were commonly run by ACCOUNTADMIN-class automation against untrusted inputs — but the documented and best-practice pattern is scoped functional roles. HIGH is off the table because there is no remote vector, no unauthenticated path, and no service-listener exposure.

1. Upgrade snowflake-cli to 3.19.0+ on developer laptops and CI runners — This is a code-fix bug; the real remediation is the package bump. Pin in requirements.txt/pyproject.toml, rebuild base CI images. Per noisgate remediation SLA for LOW: backlog hygiene — fold into the normal dependency-refresh cycle, target within ~365 days but ideally next CI image rebuild.
2. Audit Snowflake roles used by CI service accounts and developer SSO — Confirm no automation runs snow under ACCOUNTADMIN/SECURITYADMIN. Move to functional roles (APP_DEPLOYER, SCHEMA_OWNER) with explicit grants. This is the single biggest blast-radius reducer for this CVE and the next one.
3. Enable Snowflake ACCESS_HISTORY + alerting on anomalous CLI sessions — Pipe QUERY_HISTORY and ACCESS_HISTORY into your SIEM. Alert on unexpected GRANT, CREATE USER, COPY INTO @stage from CLI client sessions. Catches both this and any successor injection bug.
4. Treat snowflake.yml and Snowflake project manifests as code — Require PR review, CODEOWNERS, and a semgrep/regex rule flagging suspicious $$, unbalanced quotes, or identifier separators in those files.

Run on each developer laptop or CI runner that has Python/Snowflake CLI installed. Invoke as python3 check_cve_2026_13752.py — no privileges required beyond reading the local Python environment. For CI, wire it into your image-build pipeline.

#!/usr/bin/env python3
# CVE-2026-13752 — Snowflake CLI SQL injection (<3.19)
# Exit codes: 0 PATCHED, 1 VULNERABLE, 2 UNKNOWN / not installed
import sys, shutil, subprocess, re

FIXED = (3, 19, 0)

def parse(v):
    m = re.match(r'(\d+)\.(\d+)\.(\d+)', v.strip())
    return tuple(int(x) for x in m.groups()) if m else None

def get_version():
    # 1) Try the `snow` binary
    snow = shutil.which('snow')
    if snow:
        try:
            out = subprocess.check_output([snow, '--version'], text=True, stderr=subprocess.STDOUT, timeout=10)
            m = re.search(r'(\d+\.\d+\.\d+)', out)
            if m: return m.group(1), 'snow --version'
        except Exception:
            pass
    # 2) Fall back to pip metadata
    try:
        import importlib.metadata as md
        return md.version('snowflake-cli'), 'pip metadata'
    except Exception:
        try:
            import importlib.metadata as md
            return md.version('snowflake-cli-labs'), 'pip metadata (labs)'
        except Exception:
            return None, None

ver, src = get_version()
if ver is None:
    print('UNKNOWN: snowflake-cli not installed on this host')
    sys.exit(2)

parsed = parse(ver)
if parsed is None:
    print(f'UNKNOWN: could not parse version string {ver!r} ({src})')
    sys.exit(2)

if parsed < FIXED:
    print(f'VULNERABLE: snowflake-cli {ver} < 3.19.0 ({src})')
    sys.exit(1)
print(f'PATCHED: snowflake-cli {ver} ({src})')
sys.exit(0)

Sources

1. Snowflake CLI 2026 release notes
2. Snowflake Security Bulletins
3. snowflake-cli on PyPI
4. snowflake-cli GitHub releases
5. OpenCVE — Snowflake vendor page
6. CWE-89 — SQL Injection
7. Snowflake CLI documentation
8. Datadog — Threat hunting in Snowflake