A flaw was found in automation-controller (AWX). In
WorkflowJobTemplateNodeAccess (awx/main/access.py), can_change() delegates the
execute-permission check on a node's unified_job_template to ujt_execute(), which
returns True unconditionally when the node's current obj.unified_job_template is
None, without ever validating the incoming data['unified_job_template'] against
execute_role. can_add() does not mark unified_job_template as mandatory, so a node
can be created with unified_job_template=null (HTTP 201). PATCHing that empty node
to any UnifiedJobTemplate id then succeeds (HTTP 200) with no execute_role check
on the new value. The direct-create path (POST a node with unified_job_template
set) is correctly denied (403) via can_add -> check_related(role_field=
'execute_role'); the create-empty-then-PATCH sequence bypasses that guard.
Consequently a user with admin_role on any single WorkflowJobTemplate (an
organization admin, an Organization Workflow Admin, or an object-level WFJT
admin) can bind and execute any Job Template, Project update, Inventory Source
sync, System Job Template, or nested Workflow Job Template belonging to any other
organization/tenant -- even ones for which direct GET/launch returns 403 --
running the victim template with the victim's attached credentials, inventory and
project. The PATCH response summary_fields additionally leaks the victim
template's name and description. Discovered internally (pentest-aap); verified
live on AAP 2.7 / automation-controller 4.8.x (victim WFJT executed end-to-end,
launched_by attacker); still present on devel.
    Upstream: github.com/ansible/awx (awx/main/access.py:
              WorkflowJobTemplateNodeAccess.ujt_execute / can_add / can_change;
              check_related both-None handling).