Chris Meyers

A flaw exists where the `host config key` (provisioning-callback secret) is exposed to users with only the `view jobtemplate` read-level permission via the job template API and the activity stream. Additionally, when the controller is deployed behind the AAP gateway with an empty proxy allow-list, the provisioning callback endpoint trusts the client-supplied `X-Forwarded-For` header to identify the calling host. A minimally privileged or unauthenticated remote attacker can use the leaked secret and spoof the `X-Forwarded-For` header to match a host in the job template's inventory, allowing them to launch the job template against arbitrary managed hosts using the template's credentials. This leads to privilege escalation and remote code execution on the managed hosts.

An improper access control issue exists in the '/api/v2/config/' endpoint, which is protected only by the `IsAuthenticated` permission. This allows any authenticated user to access the `license info` object, which contains sensitive data such as `account number`, `subscription id`, `pool id`, `sku`, `support level`, and `instance counts`. While a superuser or auditor gate restricts access to `project base dir`, `project local paths`, and `custom virtualenvs`, it does not cover `license info`. This exposure can be used for estate sizing reconnaissance and social engineering attacks against Red Hat support.

The `HostList.list()` function catches generic exceptions and returns the error string verbatim. An authenticated user can exploit this via the `host filter` parameter to trigger a Django FieldError, which leaks the complete Host model relation graph and internal reverse accessors, or a PostgreSQL DataError, which leaks raw database error strings. This can be achieved using primitives such as `credential search=x` to dump the ORM schema or `name regex=[bad` to reflect PostgreSQL errors.

The `to internal value()` function in `StringListPathField` calls `os.path.exists()` using unbounded paths supplied by the user. This allows a tenant superuser to determine the existence of arbitrary absolute paths on the controller-web pod by observing the difference between 200 and 400 HTTP responses. This can be used to confirm the presence of sensitive files such as `/etc/tower/SECRET KEY`, Kubernetes service-account tokens, receptor sockets, and ConfigMap mount points. This issue is primarily impactful on managed Ansible Automation Platform (AAP) environments where the tenant administrator is not the host administrator.

The notification template Jinja AST whitelist only inspects static Getattr nodes. This allows dynamic subscripts, such as `job['job'+' env']`, and conditional gating, such as `{% if job.id > 100 %}`, to bypass both the AST check and the test-render process. At runtime, the gated branch executes and exceptions write full tracebacks into the notification body, which is then POSTed to an attacker-controlled webhook URL. This process leaks sensitive information, including install paths, Python version, and source line numbers.

A validation gap exists in the `LaunchConfigurationBaseSerializer.scm branch` where the `validate scm branch()` check for leading dashes is missing. This allows the `scm branch` variable to accept malicious input, such as `--upload-pack=/bin/id`. While a defense-in-depth check in `jobs.py:1502` currently prevents execution by raising a `ValueError`, the lack of API-level validation means the system relies solely on a task-layer guard. If this guard is removed or refactored, it could lead to Remote Code Execution (RCE), a situation where an attacker can execute arbitrary commands on the host machine.

The `build args()` function within `RunAdHocCommand` incorrectly appends the `limit` variable as a bare positional argument instead of using the `-l` flag. This allows a `limit` value starting with a hyphen to be interpreted as an ansible CLI option. Currently, this is limited to short-circuit flags such as `--version` and `--help` because the injected element displaces the required pattern positional argument.

The `URLModificationMiddleware` resolves named-URL lookups against unfiltered `Model.objects` before Role-Based Access Control (RBAC) is applied. Because the 403 to 404 response shim only rewrites 403 responses, the path for a `pk=0` miss returns a different 404 detail string. This difference between "Not found." and "No <Model> matches..." allows an attacker to determine if a named resource, such as an organization, credential, inventory, or host, exists anywhere on the platform, enabling cross-tenant internal hostname enumeration.

The `JobJobEventsChildrenSummary` view lacks a defined model or parent model, causing the `ModelAccessPermission.check get permissions()` function to return True for any authenticated user. Because the view utilizes `get object or 404(Job, pk)` without implementing Django Rest Framework (DRF) object-level permission checks, an authenticated user with zero privileges can access the event tree structure and the `event processing finished` status. Additionally, this allows for the enumeration of Job IDs across the platform using a 200/404 oracle, where the server response indicates whether a specific ID exists. This occurs while the sibling endpoint '/jobs/{id}/job events/' correctly enforces permissions.

A flaw exists in the HashiCorp Vault credential plugin of the AAP Controller. When a HashiCorp Vault Secret Lookup credential using `kubernetes role` authentication is tested, the `kubernetes auth()` function in `awx plugins/credentials/hashivault.py` reads the Kubernetes service account token of the controller pod and transmits it to an external URL controlled by an attacker. An authenticated attacker with privileges to create credentials can exfiltrate this token to obtain Kubernetes API access to control plane namespaces. This access allows full pod CRUD (Create, Read, Update, Delete) operations and the ability to read secrets, including database credentials and the `SECRET KEY` used by Django.

The Event-Driven Ansible (EDA) server contains a flaw in the `ExternalEventStreamViewSet` due to permissive access controls. The system relies exclusively on the `Subject` HTTP header for mTLS (mutual Transport Layer Security) authentication—a process where both client and server verify each other's certificates—without confirming that the header was sent by a trusted proxy. Furthermore, the 403 error response body leaks the expected certificate Distinguished Name. An attacker capable of reaching the API endpoint with a spoofed `Subject` header can inject arbitrary events into protected event streams to trigger downstream automation actions.

A flaw in the AAP Gateway Envoy proxy configuration allows an unauthenticated remote attacker to bypass mTLS authentication. The non-mTLS route to EDA event streams fails to remove the `Subject` HTTP header from client requests. By injecting a spoofed `Subject` header that matches a legitimate client certificate Distinguished Name (DN), an attacker can inject arbitrary events into protected EDA event streams.

A missing authorization issue exists in the websocket API. The '/api/eda/ws/ansible-rulebook' endpoint fails to verify user permissions when processing Worker messages. This allows any authenticated user to send a forged message containing an arbitrary `activation id` to obtain plaintext credentials associated with that activation, such as OAuth tokens, vault passwords, and SSH keys.

A command injection issue exists in the legacy role import API (v1) where the `do git checkout()` function interpolates unsanitized git ref names, such as branch or tag names, into shell commands executed via `subprocess.run()` with `shell=True`. An authenticated user with control over a git repository can use shell metacharacters in a branch or tag name to achieve remote code execution on the pulp worker. This endpoint is only accessible when the `GALAXY ENABLE LEGACY ROLES` variable is set to True.

A flaw was found in the Ansible aap-gateway, where concurrent requests handled by the gateway grpc service can result in concurrency issues due to race condition requests against the proxy. This issue potentially allows a less privileged user to obtain the JWT of a greater privileged user, enabling the server to be jeopardized. A user session or confidential data might be vulnerable.