REDHAT-BUG-2527046: Medium severity Ansible automation-controller (AWX) vulnerability
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
Affected Software
Event History
Frequently Asked Questions
Who can exploit this authorization gap?
An authenticated user needs execute permission on a job template and read visibility to an instance group, but does not need use permission on that group. System Auditors are particularly exposed because their instance-group queryset includes all instance groups.
Which operation bypasses instance-group use permission?
The bulk job launch endpoint, /api/v2/bulk/job_launch/, accepts instance_groups based on a read-level permission check. This can cause jobs to be placed on instance groups that the caller is not authorized to use.
Does the normal single-job launch flow have the same permission behavior?
No. The equivalent single-job launch path checks instance-group access at the use level and returns HTTP 403 when that permission is absent.