CVE-2026-23902 — Apache DolphinScheduler authorization bypass

Apache DolphinScheduler before 3.4.1 allows authenticated users with platform login permissions to use tenants not defined on the platform during workflow execution. This is an authorization flaw with multi-tenant isolation impact.

When to use it

Use this recipe when a repository deploys Apache DolphinScheduler or owns workflow orchestration manifests where authenticated users submit workflow runs under tenant identities. It is designed for source-code/deployment remediation, tenant-boundary review, workflow execution audit, and evidence that users cannot run workflows with undefined or unauthorized tenants.

Inputs

  • DolphinScheduler version, Maven coordinates, container tags, Helm values, Kubernetes manifests, worker/API image inventory, and generated dependency or SBOM reports.
  • Source/config paths that define tenants, workflow submission permissions, execution users, worker groups, API authorization, deployment values, or audit log queries.
  • Regression or post-deploy checks for fixed versions, non-admin denial on undefined tenants, valid tenant workflow success, worker/API image alignment, and audit-log review.
  • Boundary evidence: tenant model, user roles, workflow owners, execution logs, sensitive workflow definitions, deployment owner, and rollout owner.

Affected versions

  • Vulnerable: DolphinScheduler < 3.4.1
  • Fixed: DolphinScheduler >= 3.4.1

Indicator-of-exposure

  • DolphinScheduler version is below 3.4.1.
  • Instance is multi-tenant and users can submit workflow runs.
  • Tenant scoping is relied on for separation of duties or billing/security boundaries.

Remediation strategy

  • Upgrade to 3.4.1 or newer.
  • Revalidate tenant authorization controls after upgrade.
  • Review workflow execution logs for suspicious cross-tenant usage before fix.

The prompt

You are remediating CVE-2026-23902 in an Apache DolphinScheduler deployment.
Produce either:

1. A PR/change request upgrading DolphinScheduler to 3.4.1+ and adding
   verification steps, or
2. TRIAGE.md if upgrade is blocked.

## Required workflow

1. Identify current DolphinScheduler version from deployment manifests,
   container tags, Helm values, or Maven coordinates.
2. If version is `<3.4.1`, apply minimal upgrade to `3.4.1+`.
3. Add a post-deploy verification checklist:
   - authenticated non-admin user cannot execute workflow with undefined tenant;
   - expected tenant-scoped workflows still function.
4. Include audit task to inspect execution logs in exposure window.
5. Keep changes scoped; do not bundle unrelated upgrades.

## Stop conditions

- Version already fixed.
- Deployment source does not pin DolphinScheduler version.
- Upgrade would require unsupported platform leap.

Verification — what the reviewer looks for

Output contract

  • A reviewer-ready PR or change request that upgrades DolphinScheduler to 3.4.1+, aligns all API/worker/deployment artifacts, adds tenant-boundary verification, and documents audit/operator review.

  • Or a TRIAGE.md file that lists inspected manifests/images/Maven coordinates, owner, observed version, tenant-execution boundary, required fix, and residual risk.

  • The output must include exact validation commands and must not run production workflows, dump tenant workflow data, or expose execution secrets while validating.

  • Deployment now references 3.4.1+.

  • Verification checklist is concrete and executable.

  • PR body documents any observed tenant-boundary anomalies and next actions.

Watch for

  • Upgrading only the API container while worker images or Helm values still run an affected DolphinScheduler version.
  • Treating a version bump as enough without rechecking tenant creation and workflow-run authorization paths.
  • Suppressing the finding because all users are authenticated; the issue is cross-tenant authorization, not anonymous access.
  • Audit queries that dump full workflow definitions or tenant data into the PR.

References