CVE-2025-5988

An authorization bypass was found in the Ansible Automation Platform (AAP) gateway. An authenticated administrator can create a new service key for the Controller service cluster; because service-key creation is not restricted to the installer-provisioned path, the key is cryptographically indistinguishable from a legitimate one and can be used to forge a service-authentication token impersonating the Controller service. Combined with the gateway OIDC workload-identity endpoint (enabled via FEATURE_OIDC_WORKLOAD_IDENTITY_ENABLED), the attacker can drive the gateway to sign Workload Identity Tokens (WITs) for arbitrary Controller workloads, and a downstream resource server such as HashiCorp Vault that trusts the gateway OIDC key will accept the forged WIT and return the AAP credentials bound to that workload, disclosing secrets beyond the attacker's authorization boundary.

A flaw in the Ansible Automation Platform automation-controller: when copying a WorkflowJobTemplate, the deep-copy permission sanitizer validates only inventory, unified_job_template, and credentials of each cloned node and fails to check instance_groups (and execution_environment and labels) preserved from the original. A user with organization workflow-admin permission but no role on the referenced instance groups can copy a workflow, become its administrator, and launch jobs pinned to instance groups they are not authorized to use — including the control-plane instance group — bypassing the InstanceGroup use_role boundary and causing attacker-influenced automation to run in the control-plane execution context.

A flaw in Red Hat Ansible Automation Platform's automation-controller: the Project scm_url field is not validated against values that begin with a dash and is stored and passed verbatim to the git SCM module. Because the module runs git ls-remote with the URL as a positional argument and without a "--" separator, a git project URL such as "--upload-pack=<command>:x" is interpreted by git as the --upload-pack option and executed via a shell. A user with permission to create or modify a project in a single organization can thereby execute arbitrary commands on the control-plane task pod, with output reflected through the project update stdout endpoint, leading to cross-tenant compromise and in-cluster lateral movement.

A flaw in Red Hat Ansible Automation Platform's automation-controller: the provisioning-callback secret (host_config_key) is exposed to users holding only the read-level view_jobtemplate permission -- both in the job template API representation and in the activity stream -- and the provisioning callback endpoint trusts a client-supplied X-Forwarded-For header to determine the calling host when the controller is deployed behind the AAP gateway with an empty proxy allow-list. By reading the secret and spoofing X-Forwarded-For to match any host in the job template's inventory, a minimally privileged or unauthenticated remote attacker can launch the job template against arbitrary managed hosts using the job template's credentials, resulting in privilege escalation and remote code execution on managed hosts.

In the Ansible Automation Platform UI (Hub module, DocumentationParsers.tsx), documentation links are rendered without restricting the URL protocol/scheme. A collection with a link using a script-executing scheme can cause script execution in the browser of another authenticated user who clicks it — a stored XSS issue.

In Ansible Automation Platform (AWX), the Bulk Job Launch API (POST /api/v2/bulk/job_launch/) authorizes requested instance_groups with only a read-level permission check, whereas the standard single-job launch path requires use-level permission. A principal with read (but not use) permission on an instance group, such as the built-in read-only System Auditor role, combined 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 container privilege escalation flaw was found in Ansible Automation Platform images. The /etc/passwd file was created with group-writable permissions during build. An attacker with command execution in the container (even as non-root) can leverage root group membership to modify /etc/passwd and add a user with arbitrary UID, including 0, gaining full root privileges.