CVE-2026-84470 in Ansible Automation Platform
Summary
by MITRE • 09/01/2026
A flaw was found in Ansible Automation Platform's automation-controller (AWX). The Bulk Job Launch API (POST /api/v2/bulk/job_launch/) authorizes the requested instance_groups with only a read-level permission check, whereas the standard single-job launch path requires use-level permission on the same field. A principal that holds read (but not use) permission on an instance group -- for example the built-in read-only System Auditor role -- together with execute permission on a job template can launch bulk jobs onto instance groups they are not authorized to use, bypassing execution-placement isolation.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/02/2026
The vulnerability identified in Ansible Automation Platform's automation-controller component represents a critical authorization flaw within the Bulk Job Launch API endpoint located at POST /api/v2/bulk/job_launch/. This security issue stems from an inconsistency in how permission checks are applied to instance groups depending on the method used to initiate job execution. Specifically, when utilizing the bulk launch interface, the system performs only a read-level permission check for the specified instance_groups field. In contrast, the standard single-job launch path correctly enforces use-level permissions on this same attribute. This discrepancy creates an authorization bypass that allows principals with insufficient privileges to execute jobs on infrastructure segments they are not authorized to access.
The technical root cause lies in the divergent logic paths between bulk and singular job execution mechanisms within the automation-controller codebase. The single-job launch workflow correctly validates that a user possesses use permissions for each targeted instance group before allowing the job to be scheduled there, thereby enforcing proper isolation boundaries. However, the bulk API endpoint fails to replicate this rigorous check, accepting requests from users who hold only read access to the target groups. This oversight effectively neutralizes the intended separation of duties and operational security controls designed to restrict which systems specific roles or users can interact with at an execution level.
The operational impact of this vulnerability is significant for organizations relying on strict role-based access control within their Ansible Automation Platform deployments. An attacker possessing a read-only role, such as the built-in System Auditor role, combined with execute permissions on one or more job templates, could leverage this flaw to launch automation jobs against instance groups designated for other teams or higher-privileged roles. This bypasses execution-placement isolation, potentially leading to unauthorized configuration changes, data exfiltration from restricted environments, or disruption of services running on those targeted instances. The ability to execute code in unintended contexts undermines the principle of least privilege and compromises the integrity of the automation infrastructure.
This vulnerability aligns with CWE-862, which describes Missing Authorization, as the application fails to enforce required access controls for a specific action. Furthermore, it relates to CWE-209, an Information Exposure Through an Error Message if error handling reveals details about permission structures, though the primary concern is the unauthorized execution capability. From a threat modeling perspective using MITRE ATT&CK techniques, this flaw facilitates lateral movement and privilege escalation by allowing low-privileged accounts to execute commands in restricted zones, potentially leading to Credential Access or Execution of malicious payloads within sensitive network segments.
To mitigate this risk, administrators should immediately apply vendor-provided patches that correct the permission logic in the bulk job launch API endpoint to enforce use-level checks consistent with the single-job path. Until patching is feasible, organizations can implement compensating controls such as restricting access to the /api/v2/bulk/job_launch/ endpoint via network segmentation or reverse proxy rules for users who do not require bulk execution capabilities. Additionally, auditing logs for unusual patterns of job launches from read-only accounts against unexpected instance groups can help detect potential exploitation attempts in real-time. Regular review and tightening of role definitions ensure that execute permissions are granted only to those roles explicitly required for operational tasks, reducing the attack surface available to adversaries seeking to exploit authorization inconsistencies.