romain-deperne/cve-2026-41490Detailed CVE-2026-41490 disclosure with PoC demonstrating unauthenticated SQL injection in Dagster database I/O managers via dynamic partition keys, affecting DuckDB, Snowflake, BigQuery, and DeltaLake integrations.
Sévérité : Élevée (CVSS 8.x — AV:N/AC:L/PR:L/UI:N + C:H/I:H/A:H)
CWE : CWE-89 — Injection SQL
Affecté : intégrations du gestionnaire d'E/S de base de données dagster — dagster-duckdb, dagster-snowflake, dagster-gcp (BigQuery), dagster-deltalake, dagster-snowflake-polars (≤ 1.12.20)
Avis : GHSA-mjw2-v2hm-wj34
NVD : https://nvd.nist.gov/vuln/detail/CVE-2026-41490
Crédit : Romain Deperne
Chaque gestionnaire d'E/S de base de données Dagster construit sa clause WHERE en interpolant par f-string les valeurs des clés de partition directement dans le SQL. Lorsqu'un asset utilise DynamicPartitionsDefinition, les clés de partition peuvent être définies à l'exécution via l'API GraphQL (addDynamicPartition) — qui n'est pas authentifiée dans le déploiement par défaut du serveur Web. Une clé de partition malveillante transite sans échappement dans les requêtes SELECT (lecture) et DELETE (nettoyage), entraînant une injection SQL contre l'entrepôt sous-jacent (Snowflake, BigQuery, DuckDB, DeltaLake, …).
Le même helper, _static_where_clause, est copié-collé dans cinq packages de gestionnaires d'E/S. Chacun fait :
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 est entourée de guillemets simples sans échappement. La question était de savoir si partition est jamais contrôlée par l'attaquant. Pour les partitions statiques, elle est définie par le développeur — pas intéressant. Pour DynamicPartitionsDefinition, les clés sont stockées dans la base de données de métadonnées de Dagster et ajoutées à l'exécution via la mutation GraphQL addDynamicPartition. Dans le déploiement par défaut de dagster-webserver, GraphQL n'est pas authentifié, donc un attaquant sur le réseau fournit la clé de partition de bout en bout.
J'ai confirmé les deux extrémités de la chaîne : la mutation GraphQL accepte des chaînes de clés arbitraires sans validation, et la clé arrive textuellement dans _static_where_clause via context.asset_partition_keys.
addDynamicPartition(... partitionKey: "') UNION SELECT username, password_hash FROM secret_table; --")launchRun(...) ciblant cette partitionSELECT/DELETE ... WHERE col in ('') UNION SELECT ... ; --')| 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 |
Les chemins de lecture et de nettoyage l'utilisent tous deux :
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
Les clés de partition étaient traitées comme des constantes de développeur fiables, mais DynamicPartitionsDefinition les transforme en entrées définissables de l'extérieur à l'exécution. L'interpolation par f-string qui était « sûre » pour les clés statiques devient une injection pour les clés dynamiques. Correctif : requêtes paramétrées / citation appropriée des identifiants et littéraux au lieu des f-strings.
poc/poc_partition_sqli.py — montre la sortie vulnérable de _static_where_clause pour des clés bénignes vs. malveillantes, exécute une exfiltration basée sur UNION live DuckDB + DROP TABLE contre une base de données préremplie, et imprime les charges utiles exactes GraphQL addDynamicPartition / launchRun qu'un attaquant envoie.
pip install duckdb # minimal; full chain: dagster dagster-duckdb pandas
python3 poc/poc_partition_sqli.py
Injection SQL non authentifiée (configuration par défaut) contre l'entrepôt de données que Dagster orchestre — lecture arbitraire d'autres tables et écritures destructrices. Dagster se trouve au centre des plateformes de données, donc cela atteint le magasin le plus sensible de la pile.
Divulgué de manière responsable via GitHub Security Advisory. PoC publié après le correctif.