CVE-2026-19594: Snowflake Python APIs injection

CISO Take

A confused-deputy flaw in Snowflake's Python API (snowflake.core, pre-1.13.0) lets an attacker who can influence an object-name or identifier field in a downstream app hijack a higher-privileged Snowflake session — either by walking up the resource path with unencoded '..' segments or by smuggling '&', '#', or '=' into a free-form name to override swap, clone, or rename constraints. This matters for any Streamlit-in-Snowflake app, Snowflake Native App, or EXECUTE AS OWNER stored procedure that passes user-controlled strings into snowflake.core, since the malicious request executes under the app's privileged context rather than the attacker's own low-privilege role. There's no CISA KEV listing, no public exploit or Nuclei template, EPSS sits at 0.4% (67th percentile), and CISA's SSVC decision is TRACK — so this isn't under active exploitation, but the 8.1 CVSS (network, low complexity, no user interaction, high integrity/availability impact) means it's cheap to weaponize once an attacker finds a vulnerable input path. Action: upgrade snowflake.core to >=1.13.0 in every app, service, or notebook that imports it, and until patched, audit any code that forwards user-supplied identifiers or names into snowflake.core calls running under an elevated session for injection risk.

Sources:NVDEPSSCISA KEV

What is the risk?

High severity (CVSS 8.1) but currently a theoretical/TRACK-level risk rather than an imminent threat: exploitation requires a specific architectural pattern (an application built on snowflake.core that forwards attacker-influenced identifiers into calls made under a higher-privileged session such as EXECUTE AS OWNER, a Streamlit app, or a Native App). No KEV listing, no public PoC, no scanner coverage, and a low EPSS score all point to low near-term exploitation likelihood. However, the low attack complexity and no-user-interaction requirement mean that once an attacker locates a suitable injection point in a real deployment, exploitation is straightforward and yields a genuine privilege escalation with high confidentiality-adjacent integrity/availability impact on the targeted Snowflake objects.

How does the attack unfold?

Initial access

Attacker with limited access to a downstream application built on snowflake.core supplies a malicious object name or identifier string, e.g. via a Streamlit-in-Snowflake or Native App input field.

Injection

The unencoded '..' path segment or '&'/'#'/'=' characters in the input escape the intended REST path or query string when snowflake.core constructs the API call.

Confused-deputy execution

The manipulated request executes under the application's higher-privileged Snowflake session (e.g., an EXECUTE AS OWNER stored procedure) rather than the attacker's own low-privilege role.

Impact

The attacker achieves unauthorized access to, or manipulation of, a parent-scope or unintended object via swap, clone, or rename operations that should have been restricted to their granted privileges.

Initial access

Attacker with limited access to a downstream application built on snowflake.core supplies a malicious object name or identifier string, e.g. via a Streamlit-in-Snowflake or Native App input field.

Injection

The unencoded '..' path segment or '&'/'#'/'=' characters in the input escape the intended REST path or query string when snowflake.core constructs the API call.

Confused-deputy execution

The manipulated request executes under the application's higher-privileged Snowflake session (e.g., an EXECUTE AS OWNER stored procedure) rather than the attacker's own low-privilege role.

Impact

The attacker achieves unauthorized access to, or manipulation of, a parent-scope or unintended object via swap, clone, or rename operations that should have been restricted to their granted privileges.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Snowflake Python APIs	—	—	No patch

Do you use Snowflake Python APIs? You're affected.

How severe is it?

CVSS 3.1

8.1 / 10

EPSS

0.5%

chance of exploitation in 30 days

Higher than 43% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AVNetwork

ACLow

PRLow

UINone

SUnchanged

CNone

IHigh

AHigh

What should I do?

1 step

Upgrade snowflake.core (the snowflake.core PyPI package) to version 1.13.0 or later across all applications, notebooks, and Native Apps that depend on it — this is a client-library fix that requires each consuming app to be redeployed with the patched dependency; there is no server-side compensating control. Until upgraded, audit code paths where user- or tenant-controlled strings (object names, identifiers, free-form name fields) are passed into snowflake.core calls that execute under an elevated session (EXECUTE AS OWNER procedures, Streamlit-in-Snowflake apps, Native Apps), and add input validation to reject '..' path segments and unencoded '&', '#', '=' characters in identifier/name inputs as a stopgap. For detection, review Snowflake query history and access history for swap/clone/rename operations issued by service accounts or app roles against objects outside the app's expected scope, and pin snowflake.core version checks into dependency-scanning/SCA tooling.

What does CISA's SSVC say?

DecisionTrack

Exploitationnone

AutomatableNo

Technical Impactpartial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth BypassAPIFramework

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.6.2.6-AI system security

NIST AI RMF

GOVERN 6.1-Third-party and supply chain risk management

Frequently Asked Questions

What is CVE-2026-19594?

A confused-deputy flaw in Snowflake's Python API (snowflake.core, pre-1.13.0) lets an attacker who can influence an object-name or identifier field in a downstream app hijack a higher-privileged Snowflake session — either by walking up the resource path with unencoded '..' segments or by smuggling '&', '#', or '=' into a free-form name to override swap, clone, or rename constraints. This matters for any Streamlit-in-Snowflake app, Snowflake Native App, or EXECUTE AS OWNER stored procedure that passes user-controlled strings into snowflake.core, since the malicious request executes under the app's privileged context rather than the attacker's own low-privilege role. There's no CISA KEV listing, no public exploit or Nuclei template, EPSS sits at 0.4% (67th percentile), and CISA's SSVC decision is TRACK — so this isn't under active exploitation, but the 8.1 CVSS (network, low complexity, no user interaction, high integrity/availability impact) means it's cheap to weaponize once an attacker finds a vulnerable input path. Action: upgrade snowflake.core to >=1.13.0 in every app, service, or notebook that imports it, and until patched, audit any code that forwards user-supplied identifiers or names into snowflake.core calls running under an elevated session for injection risk.

Is CVE-2026-19594 actively exploited?

No confirmed active exploitation of CVE-2026-19594 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-19594?

Upgrade snowflake.core (the `snowflake.core` PyPI package) to version 1.13.0 or later across all applications, notebooks, and Native Apps that depend on it — this is a client-library fix that requires each consuming app to be redeployed with the patched dependency; there is no server-side compensating control. Until upgraded, audit code paths where user- or tenant-controlled strings (object names, identifiers, free-form name fields) are passed into snowflake.core calls that execute under an elevated session (EXECUTE AS OWNER procedures, Streamlit-in-Snowflake apps, Native Apps), and add input validation to reject '..' path segments and unencoded '&', '#', '=' characters in identifier/name inputs as a stopgap. For detection, review Snowflake query history and access history for swap/clone/rename operations issued by service accounts or app roles against objects outside the app's expected scope, and pin snowflake.core version checks into dependency-scanning/SCA tooling.

What systems are affected by CVE-2026-19594?

This vulnerability affects the following AI/ML architecture patterns: ML/data pipelines on Snowflake (Snowpark), Streamlit-in-Snowflake ML/analytics apps, Snowflake Native Apps with EXECUTE AS OWNER stored procedures, agent/orchestration tooling managing Snowflake objects via snowflake.core.

What is the CVSS score for CVE-2026-19594?

CVE-2026-19594 has a CVSS v3.1 base score of 8.1 (HIGH). The EPSS exploitation probability is 0.50%.

What is the AI security impact?

Affected AI Architectures

ML/data pipelines on Snowflake (Snowpark)Streamlit-in-Snowflake ML/analytics appsSnowflake Native Apps with EXECUTE AS OWNER stored proceduresagent/orchestration tooling managing Snowflake objects via snowflake.core

Compliance Controls Affected

ISO 42001: A.6.2.6

NIST AI RMF: GOVERN 6.1

What are the technical details?

Original Advisory

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.

Exploitation Scenario

A tenant of a multi-tenant Streamlit-in-Snowflake or Native App is allowed to name or select an object (e.g., a dataset, model, or stage) within their own scope, and that name string is passed directly into a snowflake.core call executed under the app's privileged EXECUTE AS OWNER session. The attacker supplies '..' as the object name, causing the REST call to traverse to a parent-level resource outside their tenant boundary, or embeds '&target=<other-object>' into a free-form name field to override the intended target of a swap/clone/rename operation. Because the request runs under the app's higher-privileged session rather than the attacker's own role, the attacker can manipulate or access Snowflake objects — potentially belonging to other tenants or to the app owner — that their own privileges would never permit directly.

Weaknesses (CWE)

CWE-141Improper Neutralization of Parameter/Argument Delimiters CWE-141Improper Neutralization of Parameter/Argument Delimiters CWE-22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')CWE-22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

CWE-141 — Improper Neutralization of Parameter/Argument Delimiters: The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as parameter or argument delimiters when they are sent to a downstream component.

Developers should anticipate that parameter/argument delimiters will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.
[Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis

Source: MITRE CWE corpus.