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)