EUVD-2026-43679
GHSA-8g6f-qw9x-4q6q
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate to vulnerable app (PR:L)
-
DeliverySubmit crafted column key or string to upsert/table endpoint
-
ExploitBreak out of identifier/literal context (CWE-89)
-
ExecutionInject SQL into MERGE/CREATE statement
-
PersistRead or modify data in role scope
-
ImpactExfiltrate results or local files
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization Parameterized queries, prepared statements
MITRE ATT&CK
2 techniques across 2 tactics: Initial Access, Persistence The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires the target application to be built on Snowflake SQLAlchemy < 1.11.0 AND to pass user-controlled data into one of the affected code paths: (1) attacker-controlled request field names used as column identifier keys in a dynamic MERGE/upsert endpoint, (2) user-supplied strings routed through the Snowflake-specific table-creation query-building API, or (3) user-controlled connection configuration parameters for the local-file-read variant. The attacker needs at least low-privileged access to reach the vulnerable endpoint (CVSS PR:L), and impact is bounded by the Snowflake role the application connects with. Limiting factors: the file-read/exfiltration path only works in deployments that accept user-controlled connection parameters (a non-default design choice), and the SQLi paths only trigger where the app forwards raw user input into identifiers/queries rather than using safe bindings, so hardened applications that already allowlist columns and fix connection settings are not exposed. |
| Impact | The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L, base 8.3) indicates a network-reachable, low-complexity attack requiring only low privileges and no user interaction, with high confidentiality and integrity impact - consistent with SQL injection exploitable through normal application input. PR:L is important: this is not an unauthenticated internet-wide bug but requires the attacker to reach an application that already holds a Snowflake connection role, so real-world risk is highest for multi-tenant or user-facing apps that pass request data into the affected APIs. No EPSS score, KEV listing, POC, or SSVC data was provided, so exploitation probability cannot be quantified from the input; the absence of these signals lowers urgency relative to a KEV-listed bug but does not reduce the technical severity. The file-read/exfiltration variant is more conditional - it only applies where the deployment accepts user-controlled connection parameters - so its practical risk is narrower than the SQLi variants. Overall this is a genuine priority for anyone running the affected library in a data-plane-facing service, not an inflated high-CVSS-low-real-risk finding. |
| Exploit ScenarioDerived | An application exposes a dynamic upsert endpoint that maps incoming JSON request field names to Snowflake column identifiers via the vulnerable MERGE builder. An authenticated user submits a crafted field name that breaks out of the identifier context, injecting SQL that reads or modifies additional data visible to the application's Snowflake role within the same MERGE statement. No public POC is known, but the low attack complexity (AC:L) and network vector (AV:N) make exploitation straightforward once such an endpoint is identified. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jul 14, 2026
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.
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.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in pypi
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
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.
Know when Snowflake Sqlalchemy gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
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
2DescriptionCVE.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.
Executive ViewAI
Snowflake SQLAlchemy contains multiple SQL injection and file disclosure vulnerabilities affecting authenticated application users, with no public exploit identified at time of analysis. Any application using this dialect with user-controlled input in affected operations faces potential data breach and compliance violation exposure. Immediate assessment of deployment scope and emergency upgrade planning required.
No vendor-released patch identified at time of analysis. Until version 1.11.0 becomes available, implement strict input validation for all user-supplied values passed to column identifiers and table creation operations; restrict Snowflake user roles to minimum necessary permissions; disable or sanitize connection parameter forwarding; implement query logging and monitoring for suspicious SQL patterns; conduct code review of all dynamic query construction in affected applications.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
SQL injection exploits the way applications construct database queries by mixing user input directly into SQL statements.
Exploit-DB