| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| LaunchConfigurationBaseSerializer.scm_branch has no
validate_scm_branch() leading-dash check, unlike
Project/JobTemplate/JobLaunch serializers. Schedule and
WFJT Node accept --upload-pack=/bin/id as scm_branch.
Currently blocked at runtime by jobs.py:1502 ValueError
check (defense-in-depth), but the API validation gap
means sole reliance on a task-layer guard. Refactoring
that guard away would promote this to RCE. |
| RunAdHocCommand.build_args() appends limit as bare
positional (args.append(limit)) instead of using
args.extend(['-l', limit]) like RunJob. A limit beginning
with - is parsed as an ansible CLI option. Currently
limited to short-circuit flags (--version, --help) since
injected element displaces required pattern positional.
Would escalate if ansible-core ever defaults pattern. |
| A server-side request forgery flaw was found in the Ansible Automation Platform
automation-controller email notification backend. The email backend passes the user-supplied SMTP
host and port from a notification template directly to the SMTP client without validating that
the target is not an internal, loopback, link-local, or reserved address. An authenticated user
with organization notification-admin permission can create or modify an email notification
template pointing at an arbitrary internal address, trigger a test, and have the controller task
process open a raw TCP connection to that address. The resulting connection error is reflected
back through the notification record, providing a three-state internal port-scan oracle (open,
closed, filtered) over the control-plane's cluster network, including the in-cluster Kubernetes
API. When a shared organization template holds a stored SMTP password, redirecting the host can
also cause that credential to be transmitted to an attacker-controlled server. |
| A flaw was found in Ansible Automation Platform's automation-controller (AWX).
The Bulk Job Launch API (POST /api/v2/bulk/job_launch/) authorizes the
requested instance_groups 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. |
| StringListPathField.to_internal_value() calls
os.path.exists() on unbounded user-supplied paths.
200 vs 400 response reveals existence of arbitrary
absolute paths on the controller-web pod. Tenant
superuser can confirm /etc/tower/SECRET_KEY, k8s
service-account token, receptor sockets, ConfigMap
mount points. Mainly impactful on managed AAP
(ansiblecloud.com) where tenant admin != host admin. |
| /api/v2/config/ is protected only by IsAuthenticated.
license_info (account_number, subscription_id, pool_id,
sku, support_level, instance counts) returned to any
authenticated user. The superuser/auditor gate only covers
project_base_dir/project_local_paths/custom_virtualenvs,
not license_info. Enables social engineering against
Red Hat support and estate sizing reconnaissance. |
| URLModificationMiddleware resolves named-URL lookups
against unfiltered Model.objects before RBAC. The 403→404
shim only rewrites 403 responses, leaving the pk=0 miss
path with a different 404 detail string. Differential
"Not found." vs "No <Model> matches..." reveals whether
a named resource (org, credential, inventory, host) exists
anywhere on the platform. Enables cross-tenant internal
hostname enumeration. |
| A container privilege escalation flaw was found in certain Ansible Automation Platform images. This issue arises from the /etc/passwd file being created with group-writable permissions during the build process. In certain conditions, an attacker who can execute commands within an affected container, even as a non-root user, can leverage their membership in the root group to modify the /etc/passwd file. This vulnerability allows an attacker to add a new user with any arbitrary UID, including UID 0, gaining full root privileges within the container. |
| A flaw was found in the AAP Controller's HashiCorp Vault credential plugin. The kubernetes_auth() function in awx_plugins/credentials/hashivault.py reads the controller pod's Kubernetes service account token and sends it to an attacker-controlled URL when a HashiCorp Vault Secret Lookup credential with kubernetes_role authentication is tested. An authenticated attacker with credential-creation privileges can exfiltrate the service account token, gaining Kubernetes API access to the control plane namespaces with full pod CRUD and secret read permissions, including database credentials and the Django SECRET_KEY. |
| A flaw was found in Red Hat Ansible Automation Platform's automation-
controller. The setting that formats the log message emitted for API 4XX errors
is an administrator-controlled Python format-string template that is rendered
with a live user object as an argument. Because Python string formatting permits
attribute and item traversal on its arguments, an administrator can craft a
template that walks from the user object into the application settings and reads
the Django secret key and the database password. The formatted message is written
to a logger that can be forwarded to an external log aggregator, whose destination
is also administrator-controlled, allowing the secrets to be sent off the host. An
authenticated administrator can thereby obtain the master encryption key used to
protect all stored credentials and the database service password, enabling offline
decryption of every stored credential, forgery of user sessions, and direct
access to the controller database. |
| A flaw was found 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 was found in Red Hat Ansible Automation Platform's automation-
controller. Four debug views that trigger the internal task, dependency, and
workflow schedulers are configured to allow any user (including unauthenticated
clients) and are routed in production builds because their URL include is not
gated on the debug setting. An unauthenticated remote attacker can repeatedly
invoke these endpoints to acquire the cluster-wide scheduler advisory lock;
because the legitimate scheduler acquires the same lock without waiting, the
attacker causes real scheduler runs to be skipped, stalling job dispatch for
all tenants, while also consuming controller web workers. The debug root view
additionally discloses the list of debug endpoints to unauthenticated callers. |
| A flaw was found 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. |
| A flaw was found in Red Hat Ansible Automation Platform's automation-
controller. The AWX_TASK_ENV setting accepts arbitrary environment variable
keys with no restriction, and its values are applied directly to the running
automation controller web and task processes rather than only to sandboxed
execution environments. A user with the system administrator role can set
variables such as REQUESTS_CA_BUNDLE, HTTPS_PROXY, SSLKEYLOGFILE, OPENSSL_CONF,
or LD_PRELOAD that reconfigure the control-plane process TLS trust store,
key-logging, OpenSSL engine, or dynamic linker. This enables silent interception
of the outbound TLS the control plane uses to fetch external secret-store
credentials and Red Hat subscription and Insights secrets, arbitrary file write
of TLS session keys, and potential native code execution in the control-plane
process, escalating an application administrator to compromise of the control
plane and all tenant secrets. |
| A flaw was found in Red Hat Ansible Automation Platform's automation-
controller. A project has a signature validation credential foreign key used to
validate signed project content. Unlike the project's SCM credential, the
authorization logic does not verify that the requesting user has use permission
on the referenced credential, and the API field has no validator or type
restriction. An authenticated user holding only the organization project
administrator role can therefore bind an arbitrary credential belonging to
another organization, by its identifier, when creating or updating a project.
The controller discloses that credential's name and type in the project's
summary information and, during project synchronization, decrypts the bound
credential and uses it in the attacker-controlled project's update, allowing a
cross-tenant authorization boundary violation and information disclosure. |
| A flaw was found in Red Hat Ansible Automation Platform's automation-controller. When a
custom credential type is created or updated, the injector configuration is validated by
rendering each attacker-supplied Jinja2 template synchronously inside the web request
worker, with no limit on iteration count, output size, or execution time. An
authenticated superuser can submit a credential type whose injector contains deeply
nested loops or large string operations, consuming CPU and wall-clock time in the web
worker until it is killed by the request timeout; issuing enough concurrent requests
places all web workers into a kill-and-respawn loop, making the Controller API and UI
unavailable for the duration of the attack. Additionally, certain template constructs
raise exception types that the validator does not handle, resulting in an unhandled
server error (HTTP 500) instead of a clean validation error. The rendering sandbox
prevents code execution, so there is no confidentiality or integrity impact. |
| A flaw was found in Red Hat Ansible Automation Platform's automation-
controller. When attaching an instance group to a schedule or a workflow job
template node through the dedicated API relationship endpoint, the controller
verifies only that the requesting user can read (view) the instance group,
rather than that they hold use permission on it, unlike every other instance
group assignment in the product. An authenticated user with read-only
visibility of an instance group -- for example a system auditor -- can attach a
use-restricted instance group, including the control plane group or another
tenant's container group, to a schedule or workflow node they control. Their
playbook then executes on the control plane node or within another tenant's
execution environment, leading to privilege escalation and, in the control
plane case, full compromise of the platform. |
| A flaw was found in Red Hat Ansible Automation Platform's automation-
controller. When attaching a Galaxy or Automation Hub credential to an
organization through the galaxy_credentials relationship endpoint, the
controller verifies only that the requesting user can read the credential,
rather than that they hold use permission on it, unlike other credential
consumption in the product. An authenticated user who administers one
organization and has read-only visibility of a credential in another
organization -- for example a platform auditor -- can bind that foreign
credential to their own organization. On the next project synchronization the
controller decrypts the credential server-side and uses its token to
authenticate to the credential owner's Automation Hub, allowing cross-tenant use
of another organization's secret. |
| A flaw was found in Red Hat Ansible Automation Platform's automation-controller.
When creating or editing an execution environment, the controller does not verify
that the requesting user has use permission on the container registry credential
referenced by the execution environment; it validates only the organization and
the credential kind. An authenticated user who is an execution-environment admin
of one organization can associate a container registry credential belonging to a
different organization -- one they cannot otherwise read, list, or use -- to an
execution environment they control. When a job runs with that execution
environment, the controller decrypts the foreign credential's registry password
and supplies it to the container runtime, disclosing another organization's
registry credentials across the tenant boundary. |
| A flaw was found in Red Hat Ansible Automation Platform's automation-controller. The
Project SCM branch and SCM refspec fields are accepted without rejecting values that begin
with a dash and are passed to the git module during project synchronization, where they
reach a `git checkout`/`git fetch` command line as bare arguments with no end-of-options
separator. An authenticated user permitted to create or edit a project can set the SCM
branch to a git option such as `--pathspec-from-file=<path>`, causing git to read an
arbitrary file on the synchronization host and reflect its contents back through the
project-update output. Because project synchronization runs on the control-plane host on
default OpenShift Operator deployments, an attacker can read the control-plane Kubernetes
ServiceAccount token, the Controller SECRET_KEY, and the database credentials, leading to
full compromise of the Automation Platform and its Kubernetes namespace. System
administrator privileges are not required and the impact crosses tenants. |
