Top/Articles/Snowflake CLI Had a Code-Injection Flaw Before 3.19.0: Building a Malicious Project Can Take Over Your Machine
snowflake-cli-cve-cover-en

Snowflake CLI Had a Code-Injection Flaw Before 3.19.0: Building a Malicious Project Can Take Over Your Machine

Snowflake CLI, the official tool for the Snowflake cloud data platform, has a code-injection flaw (CVE-2026-13749, CVSS 8.8): building or deploying a malicious project runs attacker code on your machine. Fixed in 3.19.0 β€” update now.

NewsPublished June 30, 2026Last updated July 24, 2026
Table of contents
Key takeaways

Snowflake CLI, the official tool for the Snowflake cloud data platform, has a code-injection flaw (CVE-2026-13749, CVSS 8.8): building or deploying a malicious project runs attacker code on your machine. Fixed in 3.19.0 β€” update now.

"Snowflake CLI," the official command-line tool for "Snowflake," the cloud service widely used for enterprise data analytics, carries a serious vulnerability before version 3.19.0. Simply building (assembling) or deploying a crafted project can run an attacker's program on the machine of the person doing the work (arbitrary code execution). The identifier is CVE-2026-13749, with a severity of CVSS 8.8 out of 10. Snowflake, the developer, published a security advisory, and the issue is fixed in version 3.19.0 and later; the latest as of July 2026 is 3.23.0. If your snow command is 3.19.0 or later, no further action is needed; if it is older, you need to update.

Snowflake CLI is the tool data professionals and engineers use from their own machines, via a local command (snow), to assemble and deploy apps and data processing on Snowflake. What makes this hole troublesome is that it requires no special privileges such as login, and is triggered by the everyday task of "building a project someone else prepared in your own environment." Rather than attacking Snowflake's servers directly, the attacker uses the developer's local work as a stepping stone.

ItemDetails
CVECVE-2026-13749
TargetSnowflake CLI
(Snowflake's official command-line tool)
TypeCode injection
(malicious input into generated code)
What happensArbitrary program execution
during build/deploy β†’ takeover
Severity (CVSS)8.8 (NVD / CVSS v3.1)
Affected / Fixed2.4.0 to before 3.19.0 / 3.19.0+
(latest is 3.23.0)

*The update to the fixed 3.19.0 is not automatic; users must upgrade manually (release notes).

Who is at risk, and what is the damage

This hole can be exploited by an attacker who can get a data professional to build or deploy a booby-trapped Snowflake project. In practice, this covers running someone else's project in your own environment: a handy-looking sample or template in a public repository, a verification project attached to a technical article, a deliverable from an outsourcing partner, a boilerplate shared within a team. The attacker needs no Snowflake account or login β€” they just mix the trap into the project files.

The attacker slips project content into the program that Snowflake CLI auto-generates internally, so the attacker's code runs at the moment of building or deploying. To prepare data processing (Snowpark), the CLI assembles Python code behind the scenes, but it did not sufficiently neutralize the project descriptions used as the raw material β€” so the attacker's instructions end up mixed into the generated code and run. Execution happens with the privileges of the user doing the work.

The essence of the damage is that the machine of the person handling the data platform gets taken over. Such machines concentrate connection details and access tokens for Snowflake, cloud keys, and permissions to extract large volumes of data. Compromise one, and it can become a foothold to break into the data platform, exfiltrate confidential data, or even contaminate shipped artifacts (a supply-chain attack). Because the attack passes through a tool used in development and operations, it underscores the need to review the security of the software you depend on, all at once. Our OSS supply-chain scanner also covers the importance of inspecting these "weaknesses in foundational software." A command-line tool for a data platform becoming the entry point for takeover is the same family as the flaw in the workflow platform "Prefect" (CVE-2026-5366).

What Snowflake and its command-line tool are

Snowflake is a service (a cloud data platform) for storing large volumes of data in the cloud and analyzing it quickly. Many companies adopt it as the foundation for sales analysis, customer-data aggregation, and machine learning. One of the mechanisms for building apps and data processing on top of it is "Snowpark," which lets you transform data inside Snowflake using languages such as Python.

"Snowflake CLI" is the official tool for performing this work from a local command (snow). It can "build" a project and "deploy" it to Snowflake with a single command. To check whether you are affected, run snow --version and see whether it is older than 3.19.0. Versions from 2.4.0 up to before 3.19.0 are affected, and 3.19.0 or later is fixed (the latest as of July 2026 is 3.23.0). The main targets are data engineers and analytics professionals who work with Snowflake.

How it leads to takeover

When preparing Snowpark data processing, Snowflake CLI auto-generates "bridge" Python code based on information written in the project (the annotation processor mechanism). Values written on the project side should be treated safely as "data," but here they were embedded directly as part of the generated code β€” so when an attacker plants a code fragment inside a value, it runs as part of the legitimate code. This is the classic weakness known as "code injection" (CWE-94).

The trigger is the user running a build or deploy with snow against a project the attacker prepared. According to Snowflake, exploitation requires "running bundling or deployment workflows against attacker-controlled project content." Conversely, if you only handle projects made by you or a trusted team, an attack does not succeed outright. Version 3.19.0 reworked how these values are handled so they no longer slip into generated code, closing this hole. Snowflake CLI has kept releasing since then, and the latest as of July 2026 is 3.23.0, so moving to the latest version is the safe choice.

What to do now

The top priority is updating Snowflake CLI. Because updates are not applied automatically, you must upgrade manually. Depending on your install method, update with something like pip install --upgrade snowflake-cli, and confirm it is 3.19.0 or later (ideally the latest 3.23.0) with snow --version. If you use Snowflake CLI inside CI/CD (automated build and delivery), be sure to raise the version used there too.

If you cannot update right away, the interim defense is to not casually build or deploy Snowflake projects of unknown origin. Review received projects, and handle untrusted ones in an isolated environment (a disposable virtual machine or container) to limit the blast radius. If many people in your organization use Snowflake CLI, first identify which machines and automated processes still run old versions and update those first.

Summary

CVE-2026-13749 is a code injection flaw in "Snowflake CLI," Snowflake's official command-line tool. When a user builds or deploys an attacker-crafted project, the attacker's program runs on their machine and can lead to takeover. It is fixed in 3.19.0 and later (the latest as of July 2026 is 3.23.0), and because the update is manual, the key step is to check your environment's version and update.

Running projects made by others in your own environment is part of everyday data analysis and development. That is exactly why this is a good moment to both keep your tools up to date and revisit the habit of not casually running untrusted projects.

FAQ

I use Snowflake β€” am I necessarily at risk?

The danger arises when you use Snowflake CLI (the command-line tool) and build or deploy an untrusted project prepared by an attacker. People who use only the Snowflake service and web interface, or who handle only their own or a trusted team's projects, are not in immediate danger β€” but if you use the CLI, we recommend updating to 3.19.0 or later.

How do I check and update my version?

Run snow --version to see the version. If it is older than 3.19.0, you are affected. Depending on your install method, you can update with something like pip install --upgrade snowflake-cli. Since it does not auto-update, you must apply it manually.

I can't update right away β€” what can I do now?

The interim defense is to not build or deploy Snowflake projects of unknown origin. Handle untrusted projects in an isolated environment, such as a disposable virtual machine or container, so the blast radius stays limited even in the worst case.

Is it already being exploited?

As of July 23, 2026, we have not confirmed any public report of real-world exploitation (such as listing in the U.S. CISA "Known Exploited Vulnerabilities" catalog). Roughly a month after disclosure, that still holds. But the severity is high and an everyday development or operations task can be the trigger, so updating early is important.

Status as of July 23, 2026

  • β–ΈCVE-2026-13749 affects 2.4.0 up to before 3.19.0 and is fixed in 3.19.0 and later. Snowflake CLI has kept updating since; the latest is 3.23.0 (July 16, 2026).
  • β–ΈNo newer vulnerability in Snowflake CLI itself (the snow command) has been confirmed, roughly a month after disclosure.
  • β–ΈNo listing in the U.S. CISA Known Exploited Vulnerabilities catalog, and no report of real-world exploitation.

References

avatar-m-1

Makoto Horikawa

Backend Engineer / AWS / Django