REDHAT-BUG-2527156: Medium severity Ansible automation-controller vulnerability

Published Sep 1, 2026

Updated

A flaw was found in automation-controller (AWX). Binding a Credential to a resource is a use-level action because the credential's secrets are decrypted and consumed at run time; the product enforces userole on credential foreign keys throughout (ProjectAccess, CredentialInputSourceAccess, InstanceGroupAccess, job- launch and workflow-node paths). However ExecutionEnvironmentAccess.canadd and canchange (awx/main/access.py:1316-1338) validate only the organization FK (via executionenvironmentadminrole) and never call checkrelated on the credential FK, and ExecutionEnvironmentSerializer.validatecredential (serializers.py: 1327-1330) only enforces kind == 'registry' with no RBAC. Consequently a non- superuser holding Organization ExecutionEnvironment Admin (plus Member) in one organization can POST or PATCH /api/controller/v2/executionenvironments/ with a credential id referencing any Container-Registry credential in any other organization, including one for which direct GET returns 403. When a job runs with that execution environment, awx/main/tasks/jobs.py:320-327 calls cred.getinput('password'), decrypting the foreign credential's plaintext registry password into containerauthdata (podman authfile); for container-group tasks awx/main/tasks/receptor.py builds a Kubernetes imagePullSecret from the same plaintext. This crosses the tenant boundary and discloses another organization's registry credentials. A related instance affects Project.signaturevalidation credential, a second credential foreign key ProjectAccess does not use-check. Discovered internally (vanilla-harness); verified live on AAP 2.7 / automation- controller 4.8.1; still present on devel. Upstream: github.com/ansible/awx (awx/main/access.py: ExecutionEnvironmentAccess.canadd / canchange; contrast ProjectAccess; sink awx/main/tasks/jobs.py containerauthdata).

Affected Software

1 affected component

Ansible automation-controller=4.8.1

Event History

Sep 1, 2026

Data Sourced

via Red Hat·11:35 PM

DescriptionSeverityAffected Software

Frequently Asked Questions

What access does an attacker need to exploit this issue?

The attacker must be a non-superuser who has both Organization ExecutionEnvironment Admin and Member roles in an organization. They can then create or modify an execution environment and supply the ID of a Container-Registry credential from another organization.

Are credentials in other organizations exposed even when the attacker cannot view them?

Yes. The affected validation does not perform an RBAC check on the referenced credential, so an attacker can reference a Container-Registry credential even if direct access to that credential returns 403. When a job uses the execution environment, the credential's registry password is decrypted for use.

Which credential types are implicated?

The described serializer validation restricts this path to credentials whose kind is registry. The exposed secret described is the plaintext registry password consumed when a job runs with the affected execution environment.

Where can administrators find the vendor advisories for this issue?

Red Hat published RHSA-2026:71113 and RHSA-2026:71114 for this issue. The associated Bugzilla record is 2527156.

REDHAT-BUG-2527156: Medium severity Ansible automation-controller vulnerability

Affected Software

Event History

Frequently Asked Questions

What access does an attacker need to exploit this issue?

Are credentials in other organizations exposed even when the attacker cannot view them?

Which credential types are implicated?

Where can administrators find the vendor advisories for this issue?

Company

Resources

Contact

Frequently Asked Questions

What access does an attacker need to exploit this issue?

Are credentials in other organizations exposed even when the attacker cannot view them?

Which credential types are implicated?

Where can administrators find the vendor advisories for this issue?