Cada gerenciador de I/O de banco de dados do Dagster constrói sua cláusula WHERE interpolando valores de chave de partição diretamente em SQL usando f-strings. Quando um ativo usa DynamicPartitionsDefinition, as chaves de partição podem ser definidas em tempo de execução através da API GraphQL (addDynamicPartition) — que não é autenticada na implantação padrão do servidor web. Uma chave de partição maliciosa flui sem escape para ambas as consultas SELECT (carregamento) e DELETE (limpeza), resultando em injeção SQL contra o warehouse subjacente (Snowflake, BigQuery, DuckDB, DeltaLake, …).

Como encontrei isso

O mesmo helper, _static_where_clause, é copiado e colado em cinco pacotes de gerenciadores de I/O. Cada um faz:

partition é envolvido em aspas simples sem escape. A questão era se partition é alguma vez controlado pelo atacante. Para partições estáticas, é definido pelo desenvolvedor — não interessante. Para DynamicPartitionsDefinition, as chaves são armazenadas no banco de dados de metadados do Dagster e adicionadas em tempo de execução através da mutação GraphQL addDynamicPartition. Na implantação padrão do dagster-webserver, o GraphQL não é autenticado, então um atacante na rede fornece a chave de partição de ponta a ponta.

Confirmei ambas as extremidades da cadeia: a mutação GraphQL aceita strings de chave arbitrárias sem validação, e a chave chega a _static_where_clause literalmente através de context.asset_partition_keys.

Cadeia de ataque

1. Acesso à rede ao servidor web do Dagster (sem autenticação por padrão)
2. addDynamicPartition(... partitionKey: "') UNION SELECT username, password_hash FROM secret_table; --")
3. launchRun(...) direcionando essa partição
4. O gerenciador de I/O constrói SELECT/DELETE ... WHERE col in ('') UNION SELECT ... ; --')
5. A injeção SQL é executada contra o banco de dados subjacente

Código afetado (padrão idêntico, 5 locais)

Tanto o caminho de carregamento quanto o de limpeza o consomem:

Causa raiz

As chaves de partição foram tratadas como constantes confiáveis do desenvolvedor, mas DynamicPartitionsDefinition as transforma em entrada configurável externamente em tempo de execução. A interpolação de f-strings que era "segura" para chaves estáticas torna-se injeção para chaves dinâmicas. Correção: consultas parametrizadas / citação adequada de identificadores e literais em vez de f-strings.

Prova de Conceito

poc/poc_partition_sqli.py — mostra a saída vulnerável de _static_where_clause para chaves benignas vs. maliciosas, executa uma exfiltração baseada em UNION no DuckDB ao vivo + DROP TABLE contra um banco de dados semeado, e imprime os payloads exatos de GraphQL addDynamicPartition / launchRun que um atacante envia.

Impacto

Injeção SQL não autenticada (configuração padrão) contra o data warehouse que o Dagster orquestra — leitura arbitrária de outras tabelas e escritas destrutivas. O Dagster está no centro das plataformas de dados, então isso atinge o armazenamento mais sensível da pilha.

Divulgado de forma responsável via GitHub Security Advisory. PoC publicado após a correção.