Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L
Network-reachable via app input with low complexity and no UI; PR:L since the attacker must reach an app already holding a Snowflake role; high C/I from SQLi, low A.
Primary rating from Vendor (SNOWFLAKE).
CVSS VectorVendor: SNOWFLAKE
Lifecycle Timeline
3DescriptionCVE.org
Snowflake SQLAlchemy versions prior to 1.11.0 contain several security vulnerabilities, including: Improper handling of user-supplied column identifiers in merge operations could allow SQL injection through attacker-controlled input keys. An attacker may be able to exploit this through request field names in a dynamic upsert endpoint, potentially enabling read access to data visible to the application's database role or modification of values within the same MERGE statement. Improper literal rendering of bound parameters when building certain Snowflake-specific table creation queries could allow SQL injection. An attacker may be able to exploit this by supplying a crafted string to any application endpoint that passes user-controlled data through the affected query-building API, potentially causing arbitrary data exfiltration within the scope of the connection role. Improper forwarding of connection configuration parameters could allow an attacker to cause the library to read arbitrary local files and transmit their contents to an attacker-controlled endpoint. An attacker may be able to exploit this in deployment environments that accept user-controlled connection parameters, potentially exposing sensitive files accessible to the application process. The fix is available in Snowflake SQLAlchemy version 1.11.0. Users must manually upgrade.
AnalysisAI
SQL injection and local file disclosure in Snowflake SQLAlchemy before 1.11.0 lets an authenticated application user abuse three distinct weaknesses: unsanitized column identifiers in MERGE/upsert operations, improper literal rendering of bound parameters in Snowflake-specific table-creation queries, and unsafe forwarding of connection parameters that can be coerced into reading arbitrary local files. Any application built on this dialect that passes user-controlled keys, strings, or connection settings into the affected APIs can leak or modify data within the connection role's scope and, in some deployments, exfiltrate local files to an attacker endpoint. No public exploit identified at time of analysis; the issues are reported by the vendor (Snowflake) and fixed in 1.11.0.
Technical ContextAI
Snowflake SQLAlchemy is the official Python SQLAlchemy dialect (cpe:2.3:a:snowflake:snowflake_sqlalchemy:*) used by applications and ORMs to talk to the Snowflake data warehouse. The root cause is CWE-89 (SQL Injection): the library concatenates user-influenced values into SQL text instead of consistently binding them - specifically attacker-controlled column identifier keys in MERGE/upsert construction, and bound parameters that are rendered as literals when generating Snowflake-specific CREATE TABLE queries, so a crafted string breaks out of its intended context. A third, related weakness is not classic SQLi but insecure handling of connection configuration: parameters passed through to the underlying driver are not validated, so an attacker who controls connection settings can point the library at file paths or endpoints, causing it to read local files and transmit their contents. All three funnel through query-building/connection APIs that many apps expose indirectly via ORM models or dynamic endpoints.
RemediationAI
Vendor-released patch: 1.11.0 - upgrade Snowflake SQLAlchemy to 1.11.0 or later, which the vendor notes must be applied manually (no automatic update). See the release notes at https://github.com/snowflakedb/snowflake-sqlalchemy/releases. Where immediate upgrade is not possible, apply compensating controls per weakness: for the MERGE/upsert SQLi, stop passing raw request field names as column identifiers and enforce a server-side allowlist of permitted column names, accepting the trade-off of rejecting legitimate dynamic schemas; for the table-creation SQLi, avoid passing user-supplied strings into the affected query-building API and validate/escape those values before use; for the file-read issue, never let end users control connection configuration parameters - hard-code or centrally manage connection settings and reject user-supplied connection options, at the cost of reduced deployment flexibility. Also restrict the Snowflake role used by the application to least privilege so a successful injection cannot exceed intended data scope.
Same weakness CWE-89 – SQL Injection
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-43679
GHSA-8g6f-qw9x-4q6q