CVE-2026-84684 automation-controller: automation-controller-container: automation-controller: constructed inventory input inventory attachment checks only read permission on the source inventory, allowing a read-only user to clone another tenant's hos ...
A flaw was found in Red Hat Ansible Automation Platform's automation-
controller. When attaching a source inventory to a constructed inventory through
the input_inventories relationship endpoint, the controller verifies only that
the requesting user can read the source inventory, rather than that they hold use
permission on it, unlike instance group attachment on the same access class. An
authenticated user who can administer a constructed inventory and has read-only
visibility of an inventory in another organization -- for example an
organization or system auditor -- can attach that foreign inventory as an input.
On synchronization the controller clones every host and host variable, including
secrets, into the attacker's inventory, and because the attacker administers the
constructed inventory they can run ad hoc commands against the cloned hosts,
resulting in cross-tenant disclosure of inventory data and secrets and code
execution against another tenant's managed hosts.
A flaw was found in automation-controller (AWX). InventoryInputInventoriesList
(awx/api/views/inventory.py) validates only that the attached inventory is not
itself constructed, and InventoryAccess.can_attach (awx/main/access.py) special-
cases only the instance_groups relationship (requiring use_role); the
input_inventories relationship falls through to BaseAccess.can_attach, which
requires only can_change on the constructed inventory and read access on the
source inventory -- not use_role. Consequently a user who administers a
constructed inventory in one organization and holds only Inventory Read on an
inventory in another organization (for example an organization auditor, or a
system auditor with any inventory-admin org) can POST to
/api/controller/v2/inventories/{constructed_id}/input_inventories/ to attach the
foreign inventory; the constructed inventory sync then clones every host and host
variable (including secrets) into the attacker's inventory, and the attacker --
as admin of the constructed inventory -- can launch ad hoc shell commands against
those hosts or bind the inventory to a job template. Discovered internally;
verified live on AAP 2.7 / automation-controller 4.8.1 (a read-only user attached
a foreign inventory (204), cloned a secret host variable, and had an ad hoc shell
command accepted and dispatched against the foreign host); still present on devel.
Upstream: github.com/ansible/awx (awx/main/access.py InventoryAccess.
can_attach / BaseAccess.can_attach; awx/api/views/inventory.py
InventoryInputInventoriesList)
This issue has been addressed in the following products:
Red Hat Ansible Automation Platform 2.4 for RHEL 8
Red Hat Ansible Automation Platform 2.4 for RHEL 9
Via RHSA-2026:71115 https://access.redhat.com/errata/RHSA-2026:71115
This issue has been addressed in the following products:
Red Hat Ansible Automation Platform 2.6 for RHEL 10
Red Hat Ansible Automation Platform 2.6 for RHEL 9
Via RHSA-2026:71113 https://access.redhat.com/errata/RHSA-2026:71113
This issue has been addressed in the following products:
Red Hat Ansible Automation Platform 2.5 for RHEL 9
Red Hat Ansible Automation Platform 2.5 for RHEL 8
Via RHSA-2026:71114 https://access.redhat.com/errata/RHSA-2026:71114
A flaw was found in automation-controller (AWX). InventoryInputInventoriesList (awx/api/views/inventory.py) validates only that the attached inventory is not itself constructed, and InventoryAccess.can_attach (awx/main/access.py) special- cases only the instance_groups relationship (requiring use_role); the input_inventories relationship falls through to BaseAccess.can_attach, which requires only can_change on the constructed inventory and read access on the source inventory -- not use_role. Consequently a user who administers a constructed inventory in one organization and holds only Inventory Read on an inventory in another organization (for example an organization auditor, or a system auditor with any inventory-admin org) can POST to /api/controller/v2/inventories/{constructed_id}/input_inventories/ to attach the foreign inventory; the constructed inventory sync then clones every host and host variable (including secrets) into the attacker's inventory, and the attacker -- as admin of the constructed inventory -- can launch ad hoc shell commands against those hosts or bind the inventory to a job template. Discovered internally; verified live on AAP 2.7 / automation-controller 4.8.1 (a read-only user attached a foreign inventory (204), cloned a secret host variable, and had an ad hoc shell command accepted and dispatched against the foreign host); still present on devel. Upstream: github.com/ansible/awx (awx/main/access.py InventoryAccess. can_attach / BaseAccess.can_attach; awx/api/views/inventory.py InventoryInputInventoriesList)