Critical Unauthorized Data Source Exposure in Apache DolphinScheduler - CVE-2026-71183

Authenticated users of Apache DolphinScheduler can stop or create savepoints for task instances belonging to projects they are not authorized to access, because the project-scoped task-instance API fails to enforce per-project authorization. The issue affects all releases before 3.4.3 and is reachable over the network via the /dolphinscheduler/projects/{projectCode}/task-instances/{taskInstanceId}/stop and /savepoint endpoints. The independent assessment rates this CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L (the vendor-published score is 8.1), meaning a valid authenticated account plus knowledge or enumeration of a target task instance ID is required - anonymous exploitation is not possible - and the practical impact is an integrity and limited availability concern in multi-tenant or multi-project deployments where project isolation is a security boundary; no public exploit code has been identified at time of analysis, EPSS is a low 0.16% (5th percentile), and the CVE is not in CISA KEV. This is a genuine but moderate-priority issue rather than a top-tier emergency.

Authorization bypass in Apache DolphinScheduler before 3.4.3 allows an authenticated user to alter task definitions, together with their upstream dependencies, in projects they are not authorized to access. The attacker pairs a projectCode they legitimately belong to with a task-definition code belonging to a different project when calling the /dolphinscheduler/projects/{projectCode}/task-definition/{code}/with-upstream endpoint, because the handler never confirms that the task code actually belongs to the supplied project. Impact is confined to integrity and availability of workflow definitions (assessed vector I:H/A:L, C:N), so unauthorized projects may have their pipelines silently rewritten or disrupted; no public exploit code has been identified at time of analysis and EPSS is only 0.18% (7th percentile), making this a genuine but moderate-priority issue rather than an urgent emergency.

Authenticated non-admin users of Apache DolphinScheduler 3.2.0 up to (but not including) 3.4.3 can retrieve the Kubernetes kubeconfig that administrators stored for cluster integration, because the API that serves that data performs no authorization check (CWE-862). With the disclosed kubeconfig an attacker can authenticate directly to the Kubernetes API from outside DolphinScheduler, and the real-world severity is bounded by whatever privileges the embedded service account holds - cluster-admin-grade credentials expose Kubernetes Secrets and allow pod creation and persistence, while narrowly scoped credentials sharply limit what is achievable. No public exploit code or confirmed active exploitation (CISA KEV) was identified at time of analysis, and the issue is unreachable on deployments that never configured Kubernetes cluster integration or where the requester cannot obtain even a low-privileged account.

Missing authorization checks in Apache DolphinScheduler before 3.4.3 let any authenticated user pull other accounts' details from the /dolphinscheduler/users/list-all REST endpoint, enabling account enumeration and unauthorized disclosure of user information. The assessed CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) reflects that exploitation requires a valid DolphinScheduler session and results in low confidentiality impact, even though the vendor labels the issue critical; risk rises sharply in deployments permitting self-registration, shared low-privilege accounts, or broad internal network access. No public exploit code or CISA KEV entry was identified at time of analysis, and no EPSS score was present in the supplied data, so prioritization currently rests on the vendor severity label and internal exposure rather than observed exploitation.

Cross-project authorization bypass in Apache DolphinScheduler before 3.4.3 lets an authenticated user who holds legitimate schedule or workflow permissions in one project reach into a different project and manipulate its resources, because the affected API endpoints validate the caller's rights against the projectCode in the URL but never confirm that the schedule id, workflow definition code, or task instance actually belongs to that project. In practice an attacker can take workflow schedules online or offline and flip workflow definitions between ONLINE and OFFLINE, disrupting scheduled execution and task processing in tenants they were never granted access to. Impact is bounded to integrity and availability of workflow state (CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L), authentication is required, exploitation is only meaningful where multi-project isolation is treated as a security boundary, and no public exploit identified at time of analysis; vendor-released patch 3.4.3 resolves the flaw.