Technical write-up · Apache DolphinScheduler
Missing project authorization in Task Group APIs
A technical explanation of CVE-2026-57590, Apache DolphinScheduler's Task Group project authorization boundary, and the published remediation guidance.
Where Task Group authority should apply
An authenticated DolphinScheduler user could perform Task Group operations without the affected APIs properly checking permission for the associated project. Apache published this authorization failure as CVE-2026-57590 on September 24, 2026. The starting point is an account able to use the relevant Task Group functions; the missing decision concerns access to the project those operations affect. Apache advisory.
My research question concerned the scope of that authority: did permission to use a Task Group function also establish permission over the particular project involved? Consider Alice, who operates one project, and Mallory, who has a valid account but lacks access to Alice’s project. Authentication establishes Mallory’s identity. It does not establish that Alice’s project falls within her authority.
My original assessment combined source review and service-level checks with local application validation on 3.4.2. The service checks used an earlier development snapshot and should not be treated as tests of the released 3.4.2 package. The application observations came from a local 3.4.2 environment. Preparing this article involved reviewing those records and public source; no new vulnerability reproduction or patched-release runtime test was performed.
Following the project relationship
The DolphinScheduler 3.4.2 source associates Task Groups with projects and includes project-aware authorization. Project access was therefore meaningful within the component, rather than a restriction inferred solely from the interface.
The existing requireProjectPerm helper provides a useful defensive baseline. In dolphinscheduler-api/src/main/java/org/apache/dolphinscheduler/api/service/impl/TaskGroupServiceImpl.java, it looks up the relationship between a project and the signed-in user. After handling the administrator and project-owner cases, its missing-relationship branch rejects access:
ProjectUser projectUser = projectUserDao.queryProjectRelation(project.getId(), loginUser.getId());
if (projectUser == null) {
log.warn("User {} does not have operation permission for project {}", loginUser.getUserName(),
project.getCode());
throw new ServiceException(Status.USER_NO_OPERATION_PROJECT_PERM, loginUser.getUserName(),
project.getCode());
}
This is existing code from 3.4.2, not an excerpt from the published fix. The complete helper also distinguishes project access from write permission. That distinction matters: a project relationship alone need not authorize every operation on its resources.
We can now separate the decisions. Function authorization asks whether Mallory may use a kind of operation. Project authorization asks whether she may apply it to the project associated with the actual Task Group. The helper answers the second question only when the operation invokes it with the correct project and required permission. Its presence elsewhere in the service does not establish that every Task Group operation enforces that boundary.
The historical source and local observations supported the concern that this project boundary was not consistently preserved. The excerpt explains the existing permission model; Apache’s advisory supplies the public finding that affected Task Group APIs omitted the necessary project verification. It does not provide an operation-by-operation account of every affected path.
Could the broader authority be intentional?
A meaningful alternative was that Task Group permission deliberately granted authority across projects. Under such a policy, differences between authorization checks would need explanation before supporting a vulnerability claim. The project association and helper alone would not settle the intended policy: an intentionally global administrator could legitimately operate across projects.
The relevant distinction is Mallory’s lack of authority over Alice’s project, not simply the fact that two accounts differ. The original local validation supported that boundary concern, but local behavior could not by itself resolve vendor intent. Apache’s CVE record identifies the missing project permission verification as incorrect authorization, CWE-863. That published assessment establishes that the affected operations were expected to respect the project boundary.
What the finding establishes
The supported consequence is unauthorized Task Group operations across a project boundary by an authenticated user. The original local assessment does not measure how commonly relevant permissions are assigned in deployed installations or establish behavior across production topologies. The evidence does not support extending this finding to unauthenticated access, remote code execution, or complete system compromise.
The severity assessments also remain separate: Apache rates the issue Low, without a numeric score; CISA-ADP assigns High, 8.1 (CVSS 3.1). Both are recorded in the published CVE data. The numeric score is CISA-ADP’s assessment and does not expand what the original local observations establish.
Restoring the project check
Apache lists versions before 3.4.3 as affected and recommends upgrading to 3.4.3, which it states fixes the issue. This is the vendor’s published remediation guidance. This article does not present an independently verified corrective diff or runtime verification of the fixed release.
The defensive requirement is to resolve the project associated with the actual target and enforce the caller’s applicable project permission before completing the operation. Both function permission and project permission must hold. A rejected operation must also leave protected state unchanged; an error response after a state change would not restore the boundary.
I would use the following regression cases to check that requirement. These are proposed tests, not executed results or a description of upstream test coverage.
| Proposed case | Required behavior |
|---|---|
| Function and project permissions both allow the action | Preserve legitimate Task Group operation. |
| Function permission allows the action, project permission does not | Reject access and leave the target project’s state unchanged. |
| Project access exists but the action requires a stronger permission | Reject the action unless that permission is present. |
| Target project cannot be resolved | Reject the operation before changing protected state. |
The release-specific research basis here is 3.4.2; it does not identify the introducing change or independently establish the first affected release. The wider affected range and remediation version remain attributed to Apache. Running the proposed checks against the recommended release remains separate verification work.