REDHAT-BUG-2527126: Medium severity Ansible AWX vulnerability

Published Sep 1, 2026

Updated

A flaw was found in automation-controller (AWX). OrganizationGalaxyCredentialsList (awx/api/views/organization.py) validates only that the attached credential's kind is galaxyapitoken, and OrganizationAccess.canattach (awx/main/access.py) has no branch for the galaxycredentials relationship, so it falls through to BaseAccess.canattach, which requires only canchange on the organization (org admin) and read access on the credential -- not userole. 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}/galaxycredentials/ to bind that foreign credential. RunProjectUpdate.buildenv (awx/main/tasks/jobs.py) then iterates organization.galaxycredentials, decrypts each token, and exports it as ANSIBLEGALAXYSERVERSERVERnTOKEN so ansible-galaxy authenticates to the credential owner's Hub URL. The token is masked in the API jobenv, 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. canattach / BaseAccess.canattach; awx/api/views/organization.py OrganizationGalaxyCredentialsList; awx/main/tasks/jobs.py RunProjectUpdate.buildenv)

Affected Software

1 affected component

Ansible AWX=4.8.1

Event History

Sep 1, 2026

Data Sourced

via Red Hat·10:27 PM

DescriptionSeverityAffected Software

Frequently Asked Questions

What permissions does an attacker need to misuse a credential from another organization?

The attacker needs administrator-level change permission on any organization and read access to a Galaxy/Hub credential owned by a different organization. They do not need the credential's use role.

When can this be exploited in practice?

Exploitation requires a Galaxy/Hub credential in another organization that the attacker can read, plus an organization the attacker can administer. The attacker can attach that credential through the organization's galaxy_credentials API endpoint.

What is the resulting impact after a foreign credential is attached?

When a project update runs, the controller decrypts the attached Galaxy/Hub token and supplies it to ansible-galaxy server-side. This lets the attacker cause access to the credential owner's Hub URL using that organization's secret, despite having only read access to the credential.

Will the secret be visible in the job environment API response?

The token is masked in the API job_env output. However, it is still decrypted and used server-side during the project update.

REDHAT-BUG-2527126: Medium severity Ansible AWX vulnerability

Affected Software

Event History

Frequently Asked Questions

What permissions does an attacker need to misuse a credential from another organization?

When can this be exploited in practice?

What is the resulting impact after a foreign credential is attached?

Will the secret be visible in the job environment API response?

Company

Resources

Contact

Frequently Asked Questions

What permissions does an attacker need to misuse a credential from another organization?

When can this be exploited in practice?

What is the resulting impact after a foreign credential is attached?

Will the secret be visible in the job environment API response?