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 use_role on credential foreign keys
throughout (ProjectAccess, CredentialInputSourceAccess, InstanceGroupAccess, job-
launch and workflow-node paths). However ExecutionEnvironmentAccess.can_add and
can_change (awx/main/access.py:1316-1338) validate only the organization FK (via
execution_environment_admin_role) and never call check_related on the credential
FK, and ExecutionEnvironmentSerializer.validate_credential (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/execution_environments/ 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.get_input('password'), decrypting the foreign credential's plaintext
registry password into container_auth_data (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.signature_validation_
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.can_add / can_change; contrast
              ProjectAccess; sink awx/main/tasks/jobs.py container_auth_data).