CVE-2026-41490 — SQL Injection in Dagster database I/O managers via dynamic partition keys

Severity: High (CVSS 8.3) CWE: CWE-89 — SQL Injection Affected: Dagster core <= 1.13.0 and integration packages <= 0.29.0 Fixed in: Dagster core 1.13.1 and integration packages 0.29.1 Advisory: GHSA-mjw2-v2hm-wj34 NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-41490 Credit: Romain Deperne

TL;DR

Every Dagster database I/O manager builds its WHERE clause by f-string-interpolating partition key values directly into SQL. When an asset uses DynamicPartitionsDefinition, partition keys can be set at runtime through the GraphQL API (addDynamicPartition) — which is unauthenticated in the default webserver deployment. A malicious partition key flows unescaped into both SELECT (load) and DELETE (cleanup) queries, yielding SQL injection against the backing warehouse (Snowflake, BigQuery, DuckDB, DeltaLake, …).

Analysis

The same helper, _static_where_clause, is copy-pasted across five I/O-manager packages. Each one does:

def _static_where_clause(table_partition):
    partitions = ", ".join(f"'{partition}'" for partition in table_partition.partitions)
    return f"""{table_partition.partition_expr} in ({partitions})"""

partition is wrapped in single quotes with no escaping. The question was whether partition is ever attacker-controlled. For static partitions it is developer-defined — not interesting. For DynamicPartitionsDefinition the keys are stored in Dagster's metadata DB and added at runtime via the addDynamicPartition GraphQL mutation. In the default dagster-webserver deployment GraphQL is unauthenticated, so an attacker on the network supplies the partition key end-to-end.

I confirmed both ends of the chain: the GraphQL mutation accepts arbitrary key strings with no validation, and the key reaches _static_where_clause verbatim via context.asset_partition_keys.

Attack chain

1. Network access to the Dagster webserver (no auth by default)
2. addDynamicPartition(... partitionKey: "') UNION SELECT username, password_hash FROM secret_table; --")
3. launchRun(...) targeting that partition
4. The I/O manager builds SELECT/DELETE ... WHERE col in ('') UNION SELECT ... ; --')
5. SQL injection executes against the backing database

Affected code (identical pattern, 5 locations)

Package	File
dagster-duckdb	io_manager.py:340-342
dagster-snowflake	snowflake_io_manager.py:434-436
dagster-gcp (BigQuery)	bigquery/io_manager.py:472-474
dagster-deltalake	io_manager.py:265-267
dagster-snowflake-polars	snowflake_polars_type_handler.py:74

Both the load and cleanup paths consume it:

query = f"SELECT {col_str} FROM {schema}.{table} WHERE\n" + _partition_where_clause(...)  # read
query = f"DELETE FROM {schema}.{table} WHERE\n"          + _partition_where_clause(...)  # write

Root cause

Partition keys were treated as trusted developer constants, but DynamicPartitionsDefinition turns them into runtime, externally-settable input. The f-string interpolation that was "safe" for static keys becomes injection for dynamic ones. Fix: parameterized queries / proper identifier+literal quoting instead of f-strings.

Proof of Concept

poc/poc_partition_sqli.py — shows the vulnerable _static_where_clause output for benign vs. malicious keys, runs a live DuckDB UNION-based exfiltration + DROP TABLE against a seeded database, and prints the exact addDynamicPartition / launchRun GraphQL payloads an attacker sends.

pip install duckdb        # minimal; full chain: dagster dagster-duckdb pandas
python3 poc/poc_partition_sqli.py

Impact

Unauthenticated (default config) SQL injection against the data warehouse Dagster orchestrates — arbitrary read of other tables and destructive writes. Dagster sits at the center of data platforms, so this reaches the most sensitive store in the stack.

---

Disclosed responsibly via GitHub Security Advisory. PoC published after the fix.