Snowflake Platform — Security Assessment
Architecture review, attack-surface analysis, CVE inventory, and detection-gap analysis for enterprise Snowflake deployments.
Purpose: This assessment was built as a red-team exercise to illustrate the worst-case scenarios
facing enterprise Snowflake tenants, covering credential theft, AI-agent exploitation, supply-chain compromise via the
Native Apps Marketplace, and cross-cloud identity pivots. All exploit chains target publicly disclosed, patched CVEs.
No vendor systems were tested without authorization.
How to read this report: the executive summary
(this page) and the recommendations page are framed for
leadership, governance, and risk owners. The threat-landscape
and attack-chain pages give business stakeholders the
adversary's perspective in plain language. The CVE inventory
and detection pages are written for security engineering,
platform engineering, and SOC readers — they include SQL,
Sigma rules, and the Trail /
ACCOUNT_USAGE field
mapping needed to implement the recommendations end-to-end.
Shared responsibility model: Snowflake provides strong controls —
MFA enforcement (mandatory for human users since April 2025; service users on key-pair authentication are
out of scope by design — see the attack-chains page, Chain F), Trust Center, network policies, Cortex AI Guardrails,
and the Native App Anti-Abuse Pipeline. The findings here reflect gaps in customer adoption and
configuration choices, not deficiencies in the platform itself. Every recommendation can be
implemented using Snowflake's native tooling.
For covered entities and business associates:
the platform-generic chains in this report re-frame into
PHI-specific impact, HIPAA Security Rule citations, and
BAA-scope considerations on the
healthcare overlay
page. Service users on key-pair auth (Chain F) and partner
SaaS holding Snowflake credentials (Chain J) are the chains
where healthcare residual risk diverges most sharply from
the platform-generic baseline; the overlay names why.
Scope & assumptions: the assessment covers
Snowflake on AWS / Azure / GCP across the Standard, Enterprise,
Business Critical, and VPS editions. Snowflake on OCI / Alibaba
and on-premises deployments are out of scope. Each attack
chain carries a maturity badge —
EMPIRICAL (replays
a documented incident), MODELED (driven against the
lab mock; tenant-confirmed validation pending), or
HYPOTHESIS (reachable from documented primitives,
not yet exercised end-to-end). Items marked
[REQUIRES_TENANT] are deliberate hedges: details
the vendor's public advisories do not name and that the
assessment does not fabricate. The full scope statement is in
the analytical companion at
docs/analysis/snowflake-platform-attack-surface-2026.md.
Key findings
Maturity, in this table. Each row carries an inline maturity tag matching the
attack-chains page. Rows tagged
Empirical replay a documented public incident or vendor-named
misuse pattern. Rows tagged Modeled are exercised end-to-end
against the lab mock that mirrors the documented audit shape; tenant-side measurement remains a follow-on for
any organization with the underlying feature in production. A Hypothesis
row is reachable from documented primitives but not yet exercised end-to-end against either the mock or a tenant.
| Finding | Detail |
|---|---|
| Cortex AI sandbox escape (CVE-2026-6442) Hypothesis | Indirect prompt injection via an untrusted repository README caused Cortex Code CLI to execute arbitrary shell commands and exfiltrate cached Snowflake tokens. Fixed in Cortex Code CLI 1.0.25 (2026-02-28); disclosed by PromptArmor. The end-to-end exfil scenario built on top of the patched command-injection primitive is hypothesis-grade — see Chain B for the decomposition. |
| UNC5537 — multi-tenant credential-theft campaign (2024) Empirical | Financially motivated threat actor exfiltrated data from a large cohort of customer organizations using infostealer-harvested credentials against Snowflake accounts without MFA or network policies. AT&T, Ticketmaster, Santander among the confirmed victims. |
| JDBC privilege escalation (CVE-2025-24789) Empirical | Untrusted PATH search on Windows allowed privilege escalation from the JDBC driver process. CVSS 7.8. Affects any host running the driver in a shared environment. |
| Key-pair credentials under-protected Empirical | Service-user private keys found in CI runners, dbt profiles, and Airflow connections are high-value exfil targets. Network policies are not enforced on key-pair users by default. |
| Native Apps consent model has no approval workflow Modeled | A Marketplace app requesting MODIFY DATABASE grants triggers a one-time consent dialog.
Auto-update pushes new code without re-consent. A compromised provider account silently
updates every consumer tenant. Exercised against the lab mock's Marketplace + NAAAPS surfaces; no
public Snowflake-CVE'd incident anchors the chain end-to-end. |
| External functions / storage integrations widen cross-cloud blast radius Modeled | Over-privileged IAM roles bound to Storage Integrations enable S3/Azure/GCS enumeration and exfiltration as a Snowflake warehouse privilege escalation path. The inspection-depth × EAI-rule-shape matrix that drives the SPCS sub-finding (Chain H) is modeled against documented egress policy, not measured on a live tenant — inspection depth is not customer-tunable, and per-depth enforcement is a best-effort reading of vendor docs. Tenant-side confirmation remains a follow-on for any organization with an SPCS deployment under assessment. |
| Debug-log secret leakage across the connector stack Empirical | JDBC, Python, Node.js, C/C++ connectors all had CVEs in the 2025–2026 cohort for writing client-side encryption master keys or cached tokens to debug logs. |
| Partner-integration credential replay (Chain J) Empirical | A 2026 third-party SaaS incident showed the UNC5537 primitive recurs at vendor scale: a partner
holding Snowflake credentials is compromised, and credentials are replayed from the attacker's
infrastructure. Mitigation is a network policy bound to every partner-integration user,
with allowed_ip_list matching the partner's documented egress range. |
| Polaris / Iceberg catalog and OAuth scope drift (Chains K, L) Modeled | Two surfaces that grew alongside the primary chains: external Iceberg tables can be registered pointing at storage outside the customer's STORAGE INTEGRATION allowlist via the Polaris (Open Catalog) credential, and external OAuth integrations can drift to admin-class roles through IdP-side consent expansion without any Snowflake-side configuration change. Chain K is modeled against the Polaris REST catalog spec as of May 2026 — the catalog API is evolving and the tool should be validated against each deployment's actual Polaris version. |
| UDF EAI breakout and SPCS base-image substitution (Chain M, Chain H extension) Modeled | Python and Scala UDFs with EXTERNAL_ACCESS_INTEGRATIONS become exfil channels under
any analyst's session when callable by broad roles. SPCS services that pin images by tag rather
than by digest are substitutable between scan and deploy on the customer side. Both surfaces are
exercised against the lab mock's FUNCTIONS+INTEGRATIONS and
SERVICES specs; the container-image supply-chain class is empirical in the broader
ecosystem (npm, PyPI, Docker Hub typosquats) but Snowflake-specific incidents are not yet public. |
Scope
Platform Snowflake (multi-cloud: AWS, Azure, GCP)
Features in scope Authentication, Cortex AI (Code, Analyst, Search, Agents), Native Apps, SPCS, Streamlit-in-Snowflake, External Functions, Storage Integrations, Data Sharing, Tasks/UDFs/Procedures
CVE window 2022–2026 (Snowflake-attributed components)
Threat model frameFinancially motivated external attacker; malicious insider; compromised developer workstation; supply-chain attacker
Detection frame Account Usage views, Snowflake Trail, Trust Center, SIEM integration
Tooling reuse cloud-identity, llm-attacks, phishing/aitm-kits, supply-chain modules from this repository