Improper neutralization of attacker-controlled content in Snowflake CLI versions prior to 3

CVE-2026-13744 is a SQL injection in the Snowflake CLI (snow) in versions *prior to 3.19*. The CLI fails to properly neutralize attacker-controlled content when constructing SQL — specifically in dollar-quoted YAML spec literals fed to snow spcs service create / execute-job / upgrade, in SHOW ... LIKE patterns under the default STANDARD_ESCAPE_SEQUENCES=FALSE session, and in FQN.sql_identifier paths where single quotes weren't escaped. A crafted YAML spec file or fully-qualified name can break out of the intended literal and append attacker SQL that executes with the CLI user's Snowflake role.

Snowflake's HIGH / 8.3 rating is fair. The AV:N / AC:H / PR:N / UI:R / S:C / C:H/I:H/A:H vector captures it well: no auth on the CLI side (the CLI carries the user's auth), but user interaction is required and complexity is high because the attacker needs to land malicious YAML or identifiers in front of the victim. The Scope:Changed bit matters — when a developer runs snow against a poisoned spec, the SQL executes under that developer's Snowflake role, crossing the CLI/Snowflake trust boundary cleanly.

Why this verdict

• Friction is real but not disqualifying: AC:H + UI:R means an attacker needs to land malicious YAML or identifiers in front of a victim — credible via PR/template poisoning but not drive-by.
• Scope:Changed earns the 7+ baseline: the CLI runs under the user's auth context and pushes SQL into the Snowflake control plane — that's a real trust boundary crossing, not just a local crash.
• Role multiplier — CI/CD pipelines: snow is increasingly used in IaC pipelines bound to SYSADMIN/ACCOUNTADMIN. A poisoned spec in a PR build = warehouse compromise. This is the verdict floor and the reason a friction-only argument can't drag it to MEDIUM.
• Role multiplier — interactive devs: typical data engineers run snow with scoped roles; blast radius is the schemas they already own. This is the MEDIUM half of the spectrum, but it doesn't set the floor.
• No active exploitation, no KEV, no public exploit kit — the only reasons it isn't being pushed to CRITICAL.

Why not higher?

Not CRITICAL because there's no unauthenticated remote path, AC:H and UI:R jointly demand a credible delivery mechanism (poisoned repo, manifest, or social engineering), and there is no observed in-the-wild exploitation. CRITICAL would require evidence of weaponization or a default-deployed high-value target.

Why not lower?

Not MEDIUM because the affected component is a tool widely used in CI/CD with elevated Snowflake credentials — the role-multiplier floor (privileged automation context) holds the verdict at HIGH regardless of how clean your developer workstations are. Downgrading would require evidence that <1% of snow invocations carry SYSADMIN-or-above authority, which is the opposite of typical pipeline usage.

1. Upgrade Snowflake CLI to 3.19 fleet-wide — Replace snow on every developer workstation, every CI runner, and every container image baked with the CLI. Pin >=3.19 in requirements.txt, brew formulae, and base images. Deploy within 30 days per the noisgate HIGH mitigation SLA; full remediation within 180 days per the remediation SLA, but pipelines should be fixed within days.
2. Audit CI service-account Snowflake roles — Catalog every pipeline that runs snow and confirm the bound role is least-privilege. Anything running as SYSADMIN/ACCOUNTADMIN should be downgraded to a project-scoped role with explicit grants. Do this in parallel with the upgrade — vulnerability or not, this is the right posture.
3. Require PR review for any YAML spec, manifest, or schemachange file — Branch protection + CODEOWNERS on *.yml, snowflake.yml, and SPCS spec directories. This breaks the poisoned-spec delivery vector regardless of CLI version.
4. Alert on anomalous Snowflake control-plane SQL from CI principals — Build SIEM rules over SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY for CREATE USER, GRANT ROLE, ALTER USER ... SET PASSWORD, and COPY INTO <external_stage> queries originating from service-account users. These are the post-exploitation signals.
5. Set STANDARD_ESCAPE_SEQUENCES=TRUE at account level if compatible — Doesn't fix the dollar-quote breakout but closes the backslash-LIKE path. Test in non-prod first; some legacy SQL depends on the default.

Run on any host that has snow installed (developer workstation, build agent, container image). No special privileges needed — invoke as bash check-snow-cli.sh. Returns VULNERABLE for snow --version < 3.19, PATCHED for >= 3.19, UNKNOWN if the CLI isn't found.

#!/usr/bin/env bash
# noisgate verification: CVE-2026-13744 (Snowflake CLI SQL injection)
# Exit 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN
set -u

FIXED_MAJOR=3
FIXED_MINOR=19

if ! command -v snow >/dev/null 2>&1; then
  echo "UNKNOWN: snow CLI not found in PATH"
  exit 2
fi

RAW="$(snow --version 2>/dev/null || true)"
# Expected format: 'Snowflake CLI version: 3.x.y'
VER="$(echo "$RAW" | grep -oE '[0-9]+\.[0-9]+(\.[0-9]+)?' | head -n1)"

if [ -z "$VER" ]; then
  echo "UNKNOWN: could not parse version from: $RAW"
  exit 2
fi

MAJ="$(echo "$VER" | cut -d. -f1)"
MIN="$(echo "$VER" | cut -d. -f2)"

if [ "$MAJ" -gt "$FIXED_MAJOR" ]; then
  echo "PATCHED: snow $VER"
  exit 0
fi
if [ "$MAJ" -eq "$FIXED_MAJOR" ] && [ "$MIN" -ge "$FIXED_MINOR" ]; then
  echo "PATCHED: snow $VER"
  exit 0
fi

echo "VULNERABLE: snow $VER (< ${FIXED_MAJOR}.${FIXED_MINOR})"
exit 1

Sources

1. Snowflake CLI release notes 2026
2. Snowflake Security Bulletins
3. Snowflake CVE considerations (Native Apps)
4. SYSTEM$CLIENT_VULNERABILITY_INFO reference
5. Related: snowflake-connector-python write_pandas SQLi (GHSA-2vpq-fh52-j3wv)
6. Snowflake CVE listing — OpenCVE
7. CWE-89: SQL Injection
8. CISA KEV catalog (check listing status)