A flaw was found in automation-controller (AWX). OrganizationGalaxyCredentialsList
(awx/api/views/organization.py) validates only that the attached credential's
kind is galaxy_api_token, and OrganizationAccess.can_attach (awx/main/access.py)
has no branch for the galaxy_credentials relationship, so it falls through to
BaseAccess.can_attach, which requires only can_change on the organization
(org admin) and read access on the credential -- not use_role. Consequently a
user who administers any one organization and holds only read on a Galaxy/Hub
credential in another organization (for example a system/platform auditor) can
POST to /api/controller/v2/organizations/{id}/galaxy_credentials/ to bind that
foreign credential. RunProjectUpdate.build_env (awx/main/tasks/jobs.py) then
iterates organization.galaxy_credentials, decrypts each token, and exports it as
ANSIBLE_GALAXY_SERVER_SERVERn_TOKEN so ansible-galaxy authenticates to the
credential owner's Hub URL. The token is masked in the API job_env, but it is
used server-side on the attacker's behalf against the victim's Hub -- a read-only
role gains cross-tenant use of another org's secret. Discovered internally;
verified live on AAP 2.7 / automation-controller 4.8.1 (a platform auditor
attached a foreign org's credential (204) and a subsequent project sync exported
the victim Hub URL + masked token); still present on devel.
    Upstream: github.com/ansible/awx (awx/main/access.py OrganizationAccess.
              can_attach / BaseAccess.can_attach; awx/api/views/organization.py
              OrganizationGalaxyCredentialsList; awx/main/tasks/jobs.py
              RunProjectUpdate.build_env)