A flaw was found in automation-controller (AWX). The AWX_TASK_ENV setting is
protected by a validator that rejects environment-variable keys which manipulate
dynamic linkers or interpreters (LD_*, DYLD_*, PYTHON*, PERL5OPT). The sibling
GALAXY_TASK_ENV setting (awx/main/conf.py) is registered as a bare KeyValueField
with no such validator. Its value is passed verbatim into project-update
extra_vars (awx/main/tasks/jobs.py RunProjectUpdate.build_extra_vars_file ->
'galaxy_task_env') and injected into the environment of the ansible-galaxy
command tasks in awx/playbooks/project_update.yml (environment: "{{
galaxy_task_env | combine(additional_galaxy_env) }}"). A system administrator
can set GALAXY_TASK_ENV to include LD_PRELOAD or PYTHONPATH referencing a file
in a project checkout under the shared /var/lib/awx/projects volume, achieving
arbitrary code execution inside the project-sync execution environment on the
control-plane task pod on the next sync of any project with a requirements file.
The container has read/write access to all organizations' checked-out project
source and to injected ANSIBLE_GALAXY_SERVER_*_TOKEN values, enabling cross-
tenant tampering and token theft, and constitutes a bypass of the linker/
interpreter blocklist AWX enforces on AWX_TASK_ENV. Note: in ansible/awx
upstream (devel) neither AWX_TASK_ENV nor GALAXY_TASK_ENV currently carries the
blocklist -- the AWX_TASK_ENV control is a downstream patch; both must be
present upstream to prevent regression. Discovered internally; verified live on
AAP 2.7 / automation-controller 4.8.1.
    Upstream: github.com/ansible/awx (awx/main/conf.py GALAXY_TASK_ENV;
              awx/main/tasks/jobs.py RunProjectUpdate.build_extra_vars_file;
              awx/playbooks/project_update.yml)