Technical write-up · Apache DolphinScheduler
Cross-project authorization bypass in workflow batch copy and move
Analysis of CVE-2026-71897, the project boundary governing workflow batch operations, and Apache DolphinScheduler's published remediation guidance.
When workflow authority crosses a project boundary
An authenticated DolphinScheduler user could copy or move workflows belonging to a project for which they lacked the required permission. Apache published this incorrect authorization as CVE-2026-71897 on September 29, 2026. The issue concerned the scope of an existing account’s workflow operations, not stolen sessions or unauthenticated access. Apache advisory.
My research question was whether a batch operation preserved the project boundary for every workflow it affected. Consider Alice’s protected project and Mallory, a non-administrator with legitimate workflow permissions in separate projects. Permission to perform an operation in Mallory’s projects should not grant authority over Alice’s workflows. The original assessment assumed that the target workflow could be identified; it did not establish an independent way to discover protected workflows.
The application observations came from a locally built DolphinScheduler 3.4.2 standalone Docker environment using in-memory H2. Earlier service-level checks used a development snapshot, not the released 3.4.2 package. For this article, I reviewed the preserved application records and public source; I did not run a new reproduction or test the patched release.
A project check must cover the actual workflow
The existing project authorization helper in 3.4.2 provides a defensive baseline. In dolphinscheduler-api/src/main/java/org/apache/dolphinscheduler/api/service/impl/ProjectServiceImpl.java, checkProjectAndAuthThrowException checks the user’s requested permission against the project it receives:
if (!canOperatorPermissions(loginUser, new Object[]{project.getId()}, AuthorizationType.PROJECTS, permission)) {
throw new ServiceException(Status.USER_NO_OPERATION_PROJECT_PERM, loginUser.getUserName(),
project.getCode());
}
This is existing 3.4.2 authorization code, not a corrective patch. The surrounding helper also rejects a missing project. It establishes a permission decision about that project; it does not, by itself, establish which project owns every workflow involved in a later operation.
That distinction is the defensive requirement behind the finding. A batch operation needs to connect permission over a project with the actual resources being copied or moved. Valid permissions for an authorized source and destination are not sufficient if an affected workflow falls outside that authorized source. We need both the permission decision and the resource’s project relationship to agree before a state change.
The excerpt explains the permission model, rather than presenting a complete vulnerable call chain. Apache’s public assessment identifies the resulting failure: batch copy and move could affect workflows in projects outside the caller’s authority.
Checking state rather than trusting a success message
A successful response alone would not establish an unauthorized copy or move. The original local assessment compared the application’s ordinary project-scoped behavior with the state visible after the batch operations.
| Historical comparison | Recorded observation | What it supports |
|---|---|---|
| Ordinary project-scoped workflow lookup | The other project’s workflow was not returned. | The workflow was not ordinarily available in the caller’s project context. |
| Batch copy and subsequent destination inspection | A copy appeared in the caller-controlled destination project. | The operation produced a cross-project result, not only a success message. |
| Batch move and subsequent project inspection | The workflow appeared in the destination and no longer resolved under its original project. | The workflow’s project association changed. |
These are summaries of preserved application responses, not reproduction instructions. The after-state came from HTTP observations, not independently collected database-row diffs. This distinction keeps the conclusion tied to what the application actually exposed.
An alternative explanation was that batch operations intentionally carried broader project authority. The contrasting lookup behavior was useful, but could not alone settle that policy question. Apache’s published CVE record classifies the operations on unauthorized projects as incorrect authorization, confirming the intended boundary.
The consequence and its limits
The supported result is unauthorized workflow copying or movement across a project boundary by an authenticated user. It does not establish administrator access, session theft, code execution, or behavior across production deployments. Nor does the local configuration establish how commonly suitable workflow permissions are assigned.
Apache rates the issue Moderate, without a numeric score. CISA-ADP assigns Medium 4.3 (CVSS 3.1). These are separate attributed assessments in the published CVE data, not a new severity estimate derived from this article.
Preserving ownership before changing state
Apache identifies versions before 3.4.3 as affected and recommends 3.4.3 as the fixed release. That is the vendor’s published remediation guidance. The release-specific local evidence here concerns 3.4.2; it does not independently establish the introducing change or first affected release. This article does not present a verified corrective diff or patched-release runtime result.
The defensive requirement is to check the actual workflow’s project and the caller’s applicable source and destination permissions before copying or moving it. Every affected workflow must satisfy that requirement; a valid item must not authorize an unrelated one.
The following are proposed regression checks, not executed results or claims about upstream test coverage.
| Proposed case | Required behavior |
|---|---|
| All workflows and both project permissions are authorized | Preserve legitimate batch copy and move. |
| A workflow falls outside the authorized source project | Reject the unauthorized operation without changing that workflow. |
| The caller lacks the required destination permission | Reject the operation before copying or moving protected state. |
| A batch combines authorized and unauthorized workflows | Apply authorization to every item; leave unauthorized workflows unchanged. |