CVE-2026-41490 - Dagster dynamic partition SQL injection

Dagster database I/O manager integrations before the patched releases built SQL WHERE clauses by interpolating dynamic partition key values without proper escaping. A user with the Add Dynamic Partitions permission could create a partition key that injects SQL executed by the target I/O manager’s database credentials.

Only deployments that use dynamic partitions with the affected database I/O managers are exposed. Static and time-window partitions are not the vulnerable shape, but repositories should still review permission boundaries because agentic workflow systems often let automation create partitions, backfills, or asset materialization requests.

When to use it

  • A repository deploys Dagster assets, workers, Helm/K8s manifests, or images with Dagster database I/O manager integrations.
  • Dynamic partitions are used with DuckDB, Snowflake, BigQuery, DeltaLake, or Snowflake Polars I/O managers.
  • Users, services, webhooks, workflow YAML, tickets, or agents can create dynamic partition keys without equivalent database authority.
  • You need a bounded PR or triage note that upgrades Dagster and constrains dynamic partition creation as a data-access boundary.

Inputs

  • Python manifests, locks, constraints, Dockerfiles, worker images, Dagster workspace config, Helm/K8s/Terraform artifacts, SBOMs, generated reports, and runbooks.
  • Dynamic partition definitions, affected I/O manager usage, permission model, agent/webhook partition creation paths, database credentials, audit logs, and rollout owners.
  • Available dependency install, asset/job tests, permission tests, container build, deployment render, SBOM, and dependency/security scans.

Affected versions

  • Vulnerable: dagster <=1.13.0
  • Fixed: dagster 1.13.1+
  • Vulnerable integrations: dagster-deltalake <=0.29.0, dagster-duckdb <=0.29.0, dagster-gcp <=0.29.0, dagster-snowflake <=0.29.0, dagster-snowflake-polars <=0.29.0
  • Fixed integrations: 0.29.1+ for each affected integration package

Indicator-of-exposure

  • The repository depends on Dagster or one of the affected integration packages at or below the vulnerable versions.
  • Assets, jobs, sensors, schedules, or APIs use dynamic partitions.
  • Affected I/O managers are used with DuckDB, Snowflake, BigQuery, DeltaLake, or Snowflake Polars storage.
  • Users, tenants, workflow definitions, automation agents, webhooks, tickets, or API clients can create dynamic partition keys.
  • The Add Dynamic Partitions permission is granted more broadly than direct database write authority.
  • I/O manager database credentials can read or modify sensitive datasets beyond what the partition-creating user should access.

Quick checks:

rg -n "dagster|DynamicPartitionsDefinition|dynamic partition|add_dynamic_partitions|DagsterInstance|dagster-duckdb|dagster-gcp|dagster-snowflake|dagster-deltalake|dagster-snowflake-polars" .
python -m pip show dagster dagster-duckdb dagster-gcp dagster-snowflake dagster-deltalake dagster-snowflake-polars
pip freeze | rg '^(dagster|dagster-(duckdb|gcp|snowflake|deltalake|snowflake-polars))=='
rg -n "Add Dynamic Partitions|dynamic_partitions|create.*partition|partition.*permission|Editor|RBAC|workspace.yaml|dagster.yaml" .

Remediation strategy

  • Upgrade dagster to 1.13.1+.
  • Upgrade every affected database I/O manager integration to 0.29.1+.
  • Regenerate lockfiles, container images, SBOMs, deployment manifests, and dependency reports.
  • Identify every dynamic-partitioned asset that uses affected I/O managers.
  • Review who can create dynamic partition keys. Remove the permission from users, service accounts, and agents that do not already have equivalent database authority.
  • If the upgrade is blocked, apply vendor-documented manual workarounds and temporarily disable or restrict dynamic partition creation for affected assets.
  • Review database audit logs for unusual partition-key-like SQL fragments if untrusted users or automation could create dynamic partitions during the exposure window.

The prompt

You are remediating CVE-2026-41490 / GHSA-mjw2-v2hm-wj34 in Dagster dynamic
partition handling for database I/O managers. Produce exactly one output:

- A reviewer-ready PR/change request that upgrades affected Dagster packages,
  constrains dynamic partition authority, adds safe regression coverage, and
  documents operator cleanup, or
- TRIAGE.md if this repository does not own an affected Dagster deployment or
  does not use exposed dynamic partitions.

## Rules

- Scope only CVE-2026-41490 / GHSA-mjw2-v2hm-wj34.
- Treat database credentials, connection strings, warehouse names, tenant data,
  partition keys, SQL logs, asset data, and workflow secrets as sensitive.
- Do not execute injection payloads against production, staging, shared
  warehouses, or customer datasets.
- Do not print database credentials, query results, or sensitive partition
  keys.
- Do not silently expand Dagster permissions to make tests pass.
- Do not auto-merge.

## Steps

1. Inventory every Dagster asset controlled by this repository: Python
   manifests, lockfiles, constraints, Dockerfiles, worker images, Dagster
   workspace config, Helm charts, Kubernetes manifests, Terraform, CI,
   runbooks, SBOMs, and dependency reports.
2. Determine every resolved version for `dagster`, `dagster-duckdb`,
   `dagster-gcp`, `dagster-snowflake`, `dagster-deltalake`, and
   `dagster-snowflake-polars`.
3. Mark a target vulnerable if `dagster <=1.13.0` or any affected integration
   package resolves to `<=0.29.0`.
4. Determine exposure:
   - find `DynamicPartitionsDefinition` and dynamic partition API calls;
   - find database I/O managers for DuckDB, Snowflake, BigQuery, DeltaLake, or
     Snowflake Polars;
   - identify who can create dynamic partitions through UI, API, sensors,
     schedules, automation agents, or workflow inputs;
   - compare `Add Dynamic Partitions` permission to direct database authority;
   - identify database credentials used by affected I/O managers.
5. If Dagster is absent, affected packages are not deployed, or only static and
   time-window partitions are used, stop with `TRIAGE.md` naming files checked
   and the reason the repository is not exposed.
6. Upgrade Dagster to `1.13.1+` and affected integration packages to
   `0.29.1+`. Regenerate lockfiles, constraints, images, SBOMs, deployment
   renders, and dependency reports.
7. If an immediate upgrade is blocked, apply the vendor-documented manual
   workaround, disable dynamic partition creation for affected assets where
   possible, and record the upgrade blocker in `TRIAGE.md` or the PR body.
8. Tighten permissions:
   - restrict `Add Dynamic Partitions` to users/service accounts with matching
     database authority;
   - prevent LLM agents, webhooks, ticket automation, or workflow YAML from
     creating arbitrary partition keys unless explicitly approved;
   - keep database credentials least-privilege for each I/O manager.
9. Add safe tests with local fixtures or mocks:
   - dynamic partition keys containing quotes, comments, semicolons, and SQL
     keywords are escaped or treated as inert values;
   - affected I/O manager query builders use parameterization or fixed
     escaping from the patched packages;
   - unauthorized users/agents cannot create dynamic partitions;
   - static and time-window partition behavior remains unchanged.
10. Add a PR body section named `CVE-2026-41490 operator actions` that states:
    - Dagster and integration versions before and after the change;
    - which assets use dynamic partitions and affected I/O managers;
    - who had `Add Dynamic Partitions` permission;
    - whether any automation agent could create partition keys;
    - which database audit logs should be reviewed for suspicious dynamic
      partition values;
    - whether database credentials, warehouse roles, or service tokens require
      rotation or scoping changes.
11. Run relevant validation: dependency install, lockfile integrity, unit tests,
    Dagster asset/job tests, permission tests, container build, deployment
    render, SBOM refresh, and dependency/security scans available here.
12. Use PR title:
    `fix(sec): remediate CVE-2026-41490 in Dagster partitions`.

## Stop conditions

- No affected Dagster deployment, package, I/O manager, or dynamic partition
  use is controlled by this repository.
- The repository consumes a platform-managed Dagster deployment and cannot
  safely upgrade packages or permissions.
- Verification would require running SQL injection payloads against real
  databases or exposing data.
- Product behavior intentionally grants dynamic partition creation to users or
  agents without matching database authority; require a product/security
  decision.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Verification - what the reviewer looks for

  • No controlled lockfile, image, SBOM, or deployment target resolves vulnerable Dagster or affected integration package versions.
  • Exposure analysis distinguishes dynamic partitions from static and time-window partitions.
  • Tests prove dangerous partition-key strings are inert and unauthorized users/agents cannot create dynamic partitions.
  • Database credentials are least-privilege for the assets they materialize.
  • Operator actions identify affected assets, permission holders, audit logs, and any needed credential scoping or rotation.

Output contract

  • Reviewer-ready PR upgrading Dagster to 1.13.1+ and affected integrations to 0.29.1+, with refreshed locks, images, manifests, SBOMs, and reports.
  • Exposure analysis distinguishing dynamic partitions from static/time-window partitions and naming affected assets/I/O managers.
  • Tests or policy checks proving dangerous partition-key strings are inert and unauthorized users or agents cannot create dynamic partitions.
  • TRIAGE.md when Dagster runtime, I/O manager ownership, database audit, or permission changes are outside this repository.

Watch for

  • Upgrading dagster while integration packages remain pinned at 0.29.0 or older.
  • Updating application dependencies while worker images still use old lockfiles.
  • Assuming all Dagster users already have equivalent database authority.
  • Letting agents create dynamic partitions from tickets, prompts, or workflow YAML without approval.
  • Testing with real warehouses instead of isolated fixtures or mocks.

References