CVE-2026-75109 in Determined
Summary
by MITRE • 08/18/2026
Determined fails to authorize requests on the generic task kill, pause, and unpause endpoints in the API handlers. Authenticated attackers can disrupt other users' workloads by terminating, pausing, or unpausing tasks they do not own.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified involves a critical authorization failure within the application programming interface (API) of Determined, specifically affecting generic task management endpoints such as kill, pause, and unpause operations. This flaw stems from an insufficient verification mechanism where the system fails to validate whether the authenticated user initiating the request holds ownership or appropriate administrative privileges over the specific target workload. In a properly secured environment, API handlers must enforce strict access control policies that map the identity of the requester against the resource being modified. However, in this instance, the backend logic accepts any valid authentication token and proceeds with the requested action regardless of whether the user has permission to interact with the specified task ID. This represents a classic case of broken object level authorization, where the application trusts client-supplied identifiers without performing adequate server-side checks on resource ownership.
From a technical perspective, this deficiency allows authenticated attackers to manipulate the state and lifecycle of computational tasks belonging to other users or system processes. By crafting malicious API requests that target arbitrary task identifiers, an adversary can execute destructive actions such as terminating active training jobs or suspending critical data processing pipelines. The impact is not limited to simple denial of service; it extends to potential data integrity issues if interrupted workflows involve partial writes or inconsistent states in downstream systems. Furthermore, the ability to unpause tasks owned by others could lead to unauthorized resource consumption, causing financial overheads and performance degradation for legitimate users who rely on consistent access to shared computing clusters. This type of vulnerability undermines the multi-tenancy model often present in machine learning platforms, where isolation between different teams or projects is essential for operational stability and security.
The operational impact of this flaw is significant within collaborative environments that utilize Determined for distributed deep learning training. Users expect a level of reliability and exclusivity over their submitted jobs, particularly when these tasks consume substantial computational resources like GPUs or TPUs. An attacker exploiting this vulnerability can effectively disrupt ongoing research efforts, cause loss of trained model checkpoints due to abrupt termination, and create confusion regarding resource allocation metrics. In enterprise settings, such disruptions may lead to missed deadlines, increased operational costs due to retraining requirements, and a general erosion of trust in the platform's security posture. Additionally, if these task management endpoints are exposed through public-facing interfaces or accessible by less privileged service accounts, the blast radius expands significantly, potentially affecting core infrastructure components that depend on stable job scheduling.
To mitigate this vulnerability, developers must implement rigorous authorization checks at every API endpoint responsible for modifying resource states. This involves verifying that the authenticated principal matches the owner of the target task ID before executing any kill, pause, or unpause commands. The system should also enforce role-based access control to ensure that only users with elevated privileges can manage tasks outside their own scope. Regular security audits and penetration testing focused on horizontal privilege escalation scenarios are recommended to identify similar gaps in other parts of the application logic. Furthermore, implementing audit logging for all task modification events will aid in detecting suspicious activity patterns post-exploitation. Aligning these fixes with industry standards such as CWE-639 for authorization bypass via indirect reference and ATT&CK technique T1078 regarding valid accounts can help ensure comprehensive coverage of this attack vector.