CVE-2026-84719 in Ansible Automation Platform
Summary
by MITRE • 09/23/2026
A flaw was found in the Ansible Automation Platform automation-controller. When a WorkflowJobTemplate is copied, the deep-copy permission sanitizer validates only the inventory, unified_job_template, and credentials of each cloned node and fails to check the instance_groups (and execution_environment and labels) that were preserved from the original. A user with organization workflow-admin permission but no role on the referenced instance groups can copy a workflow, become its administrator, and launch jobs pinned to instance groups they are not authorized to use — including the control-plane instance group — bypassing the InstanceGroup use_role boundary and causing attacker-influenced automation to run in the control-plane execution context.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/23/2026
The vulnerability identified within Ansible Automation Platform's automation-controller component represents a critical authorization bypass rooted in incomplete validation logic during object duplication operations. Specifically, when an administrator or user with workflow-admin permissions copies a WorkflowJobTemplate, the system performs a deep-copy operation to create a new instance of that template and its associated nodes. The security mechanism designed to enforce access control boundaries relies on a permission sanitizer that iterates through each node in the cloned workflow. However, this sanitizer is flawed because it only validates permissions for specific attributes: inventory sources, unified job templates, and credentials. It fails to perform equivalent validation checks for other critical configuration parameters associated with these nodes, most notably instance groups, execution environments, and labels. This oversight creates a significant gap in the enforcement of role-based access control policies within the automation platform's hierarchical permission model.
The operational impact of this flaw is severe because it allows an attacker-influenced workflow to execute commands outside its intended scope, potentially compromising the integrity and availability of the entire infrastructure managed by Ansible Automation Platform. A user who holds organization-level workflow-admin permissions but lacks explicit role assignments on specific instance groups can exploit this logic error. By copying a WorkflowJobTemplate that references restricted resources, such as the control-plane instance group or other sensitive execution environments, the new cloned template inherits these configurations without triggering any permission checks for those particular fields. Consequently, the user effectively becomes the administrator of the copied workflow and gains the ability to launch jobs pinned to instance groups they are not authorized to access. This bypasses the InstanceGroup use_role boundary, which is designed to restrict execution capabilities based on organizational roles and group memberships.
From a technical perspective, this vulnerability aligns with CWE-284, Improper Access Control, as well as CWE-732, Incorrect Permission Assignment for Critical Resource. The root cause lies in the application's failure to apply consistent security checks across all configurable attributes of an object during state transitions like copying or cloning. In secure software design, every attribute that influences system behavior and resource allocation must be subject to authorization verification when its value is inherited from a source controlled by another user. By neglecting to validate instance groups, execution environments, and labels, the automation-controller allows privilege escalation through configuration inheritance rather than direct permission grants. This type of flaw is particularly dangerous in enterprise environments where automated workflows often run with elevated privileges or interact directly with critical infrastructure components.
The ATT&CK framework categorizes this behavior under T1078, Valid Accounts, specifically relating to persistence and lateral movement via legitimate credentials abused for unauthorized access. Although the attacker uses valid organizational permissions, the exploitation of a logic flaw allows them to achieve outcomes equivalent to having higher-level privileges on specific infrastructure segments. This can lead to denial-of-service conditions if jobs are launched against high-priority instance groups, consuming resources intended for critical operations. Furthermore, it poses a risk of data exfiltration or system compromise if the execution environment contains sensitive tools or scripts that should not be accessible to lower-privileged users. The ability to run automation in the control-plane context is especially alarming as it may allow manipulation of core platform settings or access to internal APIs and databases associated with the controller node itself.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. Administrators should immediately apply vendor-provided patches that update the deep-copy permission sanitizer to include validation checks for instance groups, execution environments, and labels alongside existing validations. Until patching is possible, organizations can implement compensating controls by auditing workflow templates for references to restricted resources and restricting who has copy permissions on such templates. Additionally, enforcing strict separation of duties between workflow administrators and infrastructure managers can limit the blast radius if a similar flaw exists in other components. Regular security audits focusing on permission inheritance logic across all object types are recommended to ensure that no attributes bypass authorization checks during creation or duplication processes. Continuous monitoring for unusual job launches from unexpected workflows can also help detect exploitation attempts early, allowing for rapid incident response before significant damage occurs.