A flaw was found in Ansible Automation Platform's automation-controller (AWX). The Bulk Job Launch API (POST /api/v2/bulk/joblaunch/) authorizes the requested instancegroups with only a read-level permission check, whereas the standard single-job launch path requires use-level permission on the same field. A principal that holds read (but not use) permission on an instance group -- for example the built-in read-only System Auditor role -- together with execute permission on a job template can launch bulk jobs onto instance groups they are not authorized to use, bypassing execution-placement isolation.

A flaw was found in automation-controller (AWX). In awx/api/serializers.py, BulkJobLaunchSerializer.validate() authorizes the instancegroups many-to-many field via checklistpermission(InstanceGroup, ...) with no action argument, which the helper interprets as a read-level check (user.getqueryset(model)). The equivalent single-job launch path (awx/main/access.py, JobLaunchConfigAccess.canadd) checks the same field at use level (useinstancegroup / userole) and raises HTTP 403 on failure. The bulk view enforces only IsAuthenticated, so the under-scoped serializer check is the sole authorization for instance-group placement. Because user.getqueryset(InstanceGroup) returns all instance groups for a System Auditor (and any read-visible group for other users), a caller with execute on a job template and read (not use) on an instance group can POST to /api/v2/bulk/joblaunch/ and have the job actually placed on that group, bypassing execution-placement isolation. The maintainers' own inline comments ("# TODO: change to userole for conflict" and "duplicated with BulkJobLaunchSerializer, check when changing permission levels") mark the gap. Inventory and Credential fields on the same bulk path are correctly checked at use level; instancegroups is the outlier. Upstream: github.com/ansible/awx (serializers.py BulkJobLaunchSerializer) Present at: tag 24.6.1 (commit 94e5795) and devel HEAD