Technical write-up · Apache DolphinScheduler
Cross-project authorization bypass in workflow release and schedules
Analysis of CVE-2026-66082, the project boundary for workflow and schedule state changes, and the authorization correction released in Apache DolphinScheduler 3.4.3.
Which project’s state may a user change?
An authenticated DolphinScheduler user with the relevant permissions in one project could change workflow and schedule states in another project without authority over it. Apache published this authorization failure as CVE-2026-66082 on October 8, 2026. The public explanation identifies a missing connection between the project used for authorization and the resource actually changed. Apache advisory.
My research question was whether changing a workflow’s release state or activating its schedule preserved that connection. Consider Alice’s protected project and Mallory, a non-administrator with legitimate permissions in a separate project. Mallory uses her own account; authority over her project should not extend to Alice’s workflows or schedules. The original assessment assumed knowledge of the target workflow code or schedule identifier. It did not establish a separate way to discover those identifiers.
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 preserved application records and the 3.4.2 and 3.4.3 source. I did not run a new reproduction or a patched-release runtime test.
A valid project did not establish resource ownership
A workflow definition and its schedule are related but distinct objects. The workflow’s release state governs its availability, while the schedule controls scheduled operation. Both state changes need authorization for the project that owns the affected workflow.
In 3.4.2, onlineScheduler in dolphinscheduler-api/src/main/java/org/apache/dolphinscheduler/api/service/impl/SchedulerServiceImpl.java checked the supplied project, then retrieved a schedule independently:
public void onlineScheduler(User loginUser, Long projectCode, Integer schedulerId) {
projectService.checkProjectAndAuthThrowException(loginUser, projectCode, WORKFLOW_ONLINE_OFFLINE);
Schedule schedule = scheduleDao.queryById(schedulerId);
doOnlineScheduler(schedule);
}
The 3.4.2 implementation never connects the retrieved schedule’s workflow to the authorized project before changing state. Its offline counterpart follows the same pattern. Checking Mallory’s permission in her project therefore does not answer whether the selected schedule belongs there.
Other guards still apply. Bringing a schedule online requires its workflow to be online, and an already-matching state returns without a change. These checks concern operational state, not Mallory’s authority over Alice’s project. The helper updates the schedule and invokes the scheduler using the project associated with its actual workflow.
The workflow release methods in 3.4.2 have the same separation: authorize the supplied project, retrieve the workflow by code, then change its release state. Workflow validation and sub-workflow readiness checks do not establish the missing project relationship.
Reading back the protected state
The original local assessment compared these mutations with operations that rejected a project mismatch. An HTTP success status alone was insufficient: the application also returned HTTP 200 for the rejected controls.
| Historical comparison | Recorded observation | What it establishes |
|---|---|---|
| Project-scoped workflow lookup | The mismatched workflow was rejected. | Ordinary lookup did not make it available in the caller’s project. |
| Schedule update | The mismatched schedule was rejected. | Another mutation path enforced the project relationship. |
| Workflow release changes | Application success, followed by administrator reads showing ONLINE and OFFLINE. | The protected workflow’s state actually changed. |
| Schedule state changes | Application success, followed by administrator reads showing ONLINE and OFFLINE. | The protected schedule’s state actually changed. |
These are summaries of preserved observations, not reproduction steps. The after-state was read through the application with a separate administrator account; it was not inferred from the mutation response or a direct database comparison.
Could the state-changing operations intentionally grant wider authority? The controls make that explanation less convincing, but do not independently settle policy. Apache’s published CVE record identifies this project mismatch as incorrect authorization, confirming the expected boundary.
Connecting ownership and permission in 3.4.3
Apache lists versions before 3.4.3 as affected and recommends 3.4.3. In the released source, both schedule state-changing methods now require project write permission and call checkScheduleBelongsToProject before mutation. For an existing schedule, that helper follows its workflow and checks the project:
WorkflowDefinition workflowDefinition =
workflowDefinitionDao.queryByCode(schedule.getWorkflowDefinitionCode()).orElse(null);
if (workflowDefinition == null || workflowDefinition.getProjectCode() != projectCode) {
throw new ServiceException(Status.SCHEDULE_NOT_EXISTS, schedule.getId());
}
This 3.4.3 ownership check binds the resource to the authorized project. The 3.4.3 workflow release methods likewise require project write permission and reject a workflow whose project differs before changing its state.
These changes appear in the public authorization correction and are present in 3.4.3. That is source verification of the released correction, separate from Apache’s remediation claim and from runtime verification. The inspected release pair does not establish the introducing change or first affected version; the wider affected range remains attributed to Apache.
Confirmed state control and remaining limits
The supported result is unauthorized ONLINE/OFFLINE changes across a project boundary. The source connects schedule changes to scheduler operations, but the preserved after-state does not establish that a job actually executed. The observations do not establish code execution, administrator access, or prevalence across production deployments.
Apache rates the issue Moderate, without a numeric score; CISA-ADP assigns Medium 6.5 (CVSS 3.1). Both assessments appear in the published CVE data.
Useful regression checks would preserve authorized same-project changes while rejecting mismatched workflows and schedules, including both directions of each state transition and callers lacking write permission. Rejected operations should leave protected state unchanged. These are proposed checks, not new execution results or a claim about upstream test coverage.