CVE-2026-84724: Automation-controller: automation-controller: systemjob extra_vars.days argument injection into uncontainerized control-plane awx-manage process
A flaw was found in the Ansible Automation Platform automation-controller system-job dispatcher. SystemJobTemplateLaunch.post (awx/api/views/init.py:3802-3805) calls createunifiedjob with the request's extravars directly and never invokes acceptorignorejobkwargs, so the "days" integer validator in SystemJobTemplate.acceptorignorevariables (awx/main/models/jobs.py: 1234-1245) is not applied on the launch path; createunifiedjob (awx/main/models/unifiedjobs.py: 369-400) copies the extravars dict onto the SystemJob verbatim after checking only key names. RunSystemJob.buildargs (awx/main/tasks/jobs.py:2113-2134) then appends str(days) to the awx-manage argument list without integer coercion, and RunSystemJob.writeargsfile (jobs.py: 2136-2137) writes ' '.join(args) to the ansible-runner args file, which ansible-runner re-tokenizes with shlex.split. A "days" value such as "5 --pythonpath /path" therefore splits into extra awx-manage arguments. RunSystemJob.buildexecutionenvironmentparams returns {} (jobs.py:2110-2111) and the dispatcher runs ansiblerunner.interface.run() in-process for SystemJob instances (jobs.py:773-781) — system jobs are the only unified-job class executed without receptor/podman isolation — so the injected arguments reach an uncontainerized control-plane awx-manage process running as the awx user with access to SECRETKEY, database credentials, and the receptor control socket. Django's handledefaultoptions parses global options such as --pythonpath from the argument vector and inserts the attacker-supplied directory at the front of sys.path. Only a superuser can trigger this (SystemJobTemplateAccess.canstart is decorated @checksuperuser, awx/main/access.py:1770-1773). Full code execution additionally requires a top-level module imported for the first time after handledefaultoptions; no such import exists in the current cleanupjobs / cleanupactivitystream import graph, so the issue is confirmed as argument injection with control of the process argument vector and sys.path[0], with code execution unproven.
Upstream: https://github.com/ansible/tower (awx) Affected file: awx/main/tasks/jobs.py:2136-2137 (RunSystemJob.writeargsfile — ' '.join(args), root cause); jobs.py:2113-2134 (buildargs, no int() coercion); jobs.py: 2110-2111 + 773-781 (uncontainerized in-process execution);
Other sources
An argument-injection flaw was found in the Ansible Automation Platform automation-controller system-job subsystem. The system-job template launch endpoint stores a user-supplied "days" variable without running the integer validation defined elsewhere for that field, and the dispatcher flattens the management-command argument list into a single string with spaces before the job runner re-splits it, so spaces in the value become additional command-line arguments. Because system jobs are executed in-process on the control node without the container isolation applied to all other job types, an authenticated user with superuser privileges can inject arbitrary arguments — including Python's path option — into the control-plane awx-manage process, controlling its argument vector and the first entry of its module search path. Full remote code execution requires an additional import gadget that is not present in the current management commands, so the demonstrated impact is argument injection with control of the process search path rather than confirmed code execution.
— MITRE
Affected Software
Event History
Frequently Asked Questions
Who can exploit this issue?
An attacker needs high privileges (PR:H) and network access (AV:N) to launch a system job with crafted extra_vars. No user interaction is required.
Are containerized execution environments affected?
The described path affects system jobs that invoke the control-plane awx-manage process without a containerized execution environment. The dispatcher runs these SystemJob instances in-process and the execution-environment parameters are empty.
What input triggers the argument injection?
A non-integer value supplied for the days extra_vars field can reach the job unchanged. For example, a value containing a space and additional awx-manage options is re-tokenized from the generated args file into separate command-line arguments.
How can administrators identify potentially affected job launches?
Review system-job launches for extra_vars containing a days value that is not an integer, especially values containing whitespace or command-line-style options. The vulnerable launch path accepts the request data without applying the SystemJobTemplate days integer validator.