CVE-2026-84680 automation-controller: automation-controller-container: automation-controller: organization galaxy credential attachment checks only read permission on the credential, allowing an organization admin with read-only visibility to bind and ...
A flaw was found in Red Hat Ansible Automation Platform's automation-
controller. When attaching a Galaxy or Automation Hub credential to an
organization through the galaxy_credentials relationship endpoint, the
controller verifies only that the requesting user can read the credential,
rather than that they hold use permission on it, unlike other credential
consumption in the product. An authenticated user who administers one
organization and has read-only visibility of a credential in another
organization -- for example a platform auditor -- can bind that foreign
credential to their own organization. On the next project synchronization the
controller decrypts the credential server-side and uses its token to
authenticate to the credential owner's Automation Hub, allowing cross-tenant use
of another organization's secret.
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)
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). 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)