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.

An absolute path traversal attack exists in the Ansible automation platform. This flaw allows an attacker to craft a malicious Ansible role and make the victim execute the role. A symlink can be used to overwrite a file outside of the extraction path.

A path traversal vulnerability exists in Ansible when extracting tarballs. An attacker could craft a malicious tarball so that when using the galaxy importer of Ansible Automation Hub, a symlink could be dropped on the disk, resulting in files being overwritten.

An information disclosure flaw was found in ansible-core due to a failure to respect the ANSIBLENOLOG configuration in some scenarios. It was discovered that information is still included in the output in certain tasks, such as loop items. Depending on the task, this issue may include sensitive information, such as decrypted secret values.

The collection remote for pulpansible stores tokens in plaintext instead of using pulp's encrypted field (https://github.com/pulp/pulpansible/blob/main/pulpansible/app/models.py#L234) and exposes them in read/write mode via the API (https://github.com/pulp/pulpansible/blob/main/pulpansible/app/serializers.py#L170) instead of marking it as write only.

A logic flaw exists in Ansible Automation platform. Whenever a private project is created with incorrect credentials, they are logged in plaintext. This flaw allows an attacker to retrieve the credentials from the log, resulting in the loss of confidentiality, integrity, and availability.

A flaw was found in the Red Hat Ansible Automation Platform, Event-Driven Ansible (EDA) Event Stream API. This vulnerability allows exposure of sensitive client credentials and internal infrastructure headers via the testheaders field when an event stream is in test mode. The possible outcome includes leakage of internal infrastructure details, accidental disclosure of user or system credentials, privilege escalation if high-value tokens are exposed, and persistent sensitive data exposure to all users with read access on the event stream.

A flaw was found in the Red Hat Ansible Automation Platform, Event-Driven Ansible (EDA) Event Streams. This vulnerability allows an authenticated user to gain access to sensitive internal infrastructure headers (such as X-Trusted-Proxy and X-Envoy-) and event stream URLs via crafted requests and job templates. By exfiltrating these headers, an attacker could spoof trusted requests, escalate privileges, or perform malicious event injection.

A flaw was found in the Red Hat Ansible Automation Platform Gateway route creation component. This vulnerability allows credential theft via the creation of misleading routes using a double-slash (//) prefix in the gatewaypath. A malicious or socially engineered administrator can configure a honey-pot route to intercept and exfiltrate user credentials, potentially maintaining persistent access or creating a backdoor even after their permissions are revoked.

A flaw was found in Ansible Galaxy Collections. When collections are built manually, any files in the repository directory that are not explicitly excluded via the buildignore list in "galaxy.yml" include files in the .tar.gz file. This contains sensitive info, such as the user's Ansible Galaxy API key and any secrets in ansible or ansible-playbook verbose output without thenolog redaction. Currently, there is no way to deprecate a Collection Or delete a Collection Version. Once published, anyone who downloads or installs the collection can view the secrets.

A re-encrypt Route with destinationCACertificate explicitly set to the default serviceCA seems to skip internal Service TLS certificate validation, errorless serving content even if target Service certificate and certificate provided by target Pod(s) differ. Note that if we don't set destinationCACertificate in the Route yaml manifest (the Route will still implicitly use the same default serviceCA certificate, as described on the doc [1]) we will correctly get a error page.

References: https://bugzilla.redhat.com/showbug.cgi?id=2041857

An XSS exists in automation controller UI where the project name is susceptible to XSS injection.POC and INC ticket below

A privilege escalation flaw was found in the Ansible Automation Platform. This flaw allows a remote authenticated user with 'change user' permissions to modify the account settings of the superuser account and also remove the superuser privileges.