A flaw was found in Ansible Lightspeed. This vulnerability, related to insufficient session expiration, allows a remote attacker to maintain persistent access to the Ansible Lightspeed instance. If an attacker exfiltrates a valid OAuth (Open Authorization) access token before a user logs out, they can continue to authenticate and access sensitive data. This is because the application fails to invalidate the token on the backend, leaving it valid until its natural expiration. This can lead to unauthorized read access to Ansible resources such as inventories, playbooks, and configuration data.

A flaw was found in ansible-core. The extractcollectionfromgit() function in ansible-core's concreteartifactmanager.py constructs git clone commands without a '--' (end-of-options) separator before user-supplied URLs when installing collections from git sources. An attacker who provides a crafted collection source URI containing git argument injection payloads can achieve arbitrary command execution when a user runs 'ansible-galaxy collection install' with the malicious source. This is an incomplete fix for CVE-2026-11332, which hardened the role install path but missed the equivalent collection install code path.

A flaw was found in the Ansible aap-gateway. Cross-site request forgery (CSRF) origin checking is not done on requests from the gateway to external components, such as the controller, hub, and eda.

Unsafe tagging can be bypassed by using the hostvars object to indirectly reference the content and successfully template it

Requirements to exploit (if any): Access to mangle the content returned to a play (via lookup or module) that uses hostvars to reference the unsafe content.

Steps to reproduce : - have unsafe content from lookup or module, or defined: untrusted: !unsafe this{{varshould}}notbetemplated - reference it via the hostvars object debug: msg={{ hostvars['hostname']['untrusted']

A flaw was found in the AWX GitHub webhook integration. When a GitHub pullrequest webhook is received, GithubWebhookReceiver.geteventstatusapi() in awx/api/views/webhooks.py returns pullrequest.statusesurl from the request body without validation. The value is stored in job extra variables as awxwebhookstatusapi and later used by WebhookMixin.updatewebhookstatus() in awx/main/models/mixins.py as the callback URL when posting job status updates. If a job template is configured with webhookservice=github and a GitHub Personal Access Token credential as webhookcredential, the controller sends that token in the Authorization header when POSTing to the stored callback URL on job completion. Although the controller is designed to post commit status updates back to GitHub, it does not restrict the callback URL to trusted GitHub API endpoints. An attacker who can submit a forged webhook request with a valid HMAC-SHA1 signature for the target job template's webhookkey can supply an attacker-controlled statusesurl and cause exfiltration of the configured GitHub PAT when the triggered job completes. Normal GitHub webhook deliveries do not allow arbitrary contributors to control statusesurl; exploitation requires knowledge of the per-template webhook shared secret or privileged access to retrieve it from the controller. Upstream: https://github.com/ansible/awx Affected files: - awx/api/views/webhooks.py (GithubWebhookReceiver.geteventstatusapi) - awx/main/models/mixins.py (WebhookMixin.updatewebhookstatus)

A flaw was found in the AWX GitHub webhook integration. When a GitHub pullrequest webhook is received, GithubWebhookReceiver.geteventstatusapi() in awx/api/views/webhooks.py returns pullrequest.statusesurl from the request body without validation. The value is stored in job extra variables as awxwebhookstatusapi and later used by WebhookMixin.updatewebhookstatus() in awx/main/models/mixins.py as the callback URL when posting job status updates. If a job template is configured with webhookservice=github and a GitHub Personal Access Token credential as webhookcredential, the controller sends that token in the Authorization header when POSTing to the stored callback URL on job completion. Although the controller is designed to post commit status updates back to GitHub, it does not restrict the callback URL to trusted GitHub API endpoints. An attacker who can submit a forged webhook request with a valid HMAC-SHA1 signature for the target job template's webhookkey can supply an attacker-controlled statusesurl and cause exfiltration of the configured GitHub PAT when the triggered job completes. Normal GitHub webhook deliveries do not allow arbitrary contributors to control statusesurl; exploitation requires knowledge of the per-template webhook shared secret or privileged access to retrieve it from the controller. Upstream: https://github.com/ansible/awx Affected files: - awx/api/views/webhooks.py (GithubWebhookReceiver.geteventstatusapi) - awx/main/models/mixins.py (WebhookMixin.updatewebhookstatus)

A flaw was found in Ansible Lightspeed. This vulnerability, related to insufficient session expiration, allows a remote attacker to maintain persistent access to the Ansible Lightspeed instance. If an attacker exfiltrates a valid OAuth (Open Authorization) access token before a user logs out, they can continue to authenticate and access sensitive data. This is because the application fails to invalidate the token on the backend, leaving it valid until its natural expiration. This can lead to unauthorized read access to Ansible resources such as inventories, playbooks, and configuration data.

A flaw was found in the ansible automation platform. An insecure WebSocket connection was being used in installation from the Ansible rulebook EDA server. An attacker that has access to any machine in the CIDR block could download all rulebook data from the WebSocket, resulting in loss of confidentiality and integrity of the system.

A flaw was found in Ansible, where a user's controller is vulnerable to template injection when internal templating operations may errantly remove the unsafe designation from template data.

A flaw was found in ansible-collection-community-general. This vulnerability allows for information exposure (IE) of sensitive credentials, specifically plaintext passwords, via verbose output when running Ansible with debug modes. Attackers with access to logs could retrieve these secrets and potentially compromise Keycloak accounts or administrative access.

A flaw was found in Ansible. Sensitive cookies without security flags over non-encrypted channels can lead to Man-in-the-Middle (MitM) and Cross-site scripting (XSS) attacks allowing attackers to read transmitted data.

A flaw was found in Ansible. Sensitive Cookies without Security Flags over non-encrypted channels may lead to Man-in-the-Middle (MitM) and Cross-site Scripting (XSS).

Flags such as "Set-Cookie: EXAMPLE=AAAABBBBCCCCDDDDAAAABBBCCC; path=/; HttpOnly; Secure; SameSite=[Strict or Lax];" are required to mitigate this issue.

A flaw was found in ansible-runner. The default temporary files configuration in ansible-2.0.0 is written to world rw location. An attacker can pre-create that directory, which may allow them to either read potentially private information or force ansible-runner to write files as the legitimate user in a place they did not expect.

Upstream issue:

https://github.com/ansible/ansible-runner/issues/738

Upstream patch:

https://github.com/ansible/ansible-runner/pull/742/commits/60b059f00409224acae1e417153a241c8591ad89

An improper authorization flaw exists in the Ansible Automation Controller. This flaw allows an attacker using the k8S API server to send an HTTP request with a service account token mounted via automountServiceAccountToken: true, resulting in privilege escalation to a service account.

A flaw was found in aap-gateway. Concurrent requests handled by the gateway grpc service can result in "swapping" a request. Effectively, a lesser privileged user (even unauthenticated) can get the JWT of a greater privileged user

"When creating a new keypair the ec2key module prints out the private key directly to the standard output. I wasn't able to find any way to disable this behavior in the module's documentation. This makes it unusable in any kind of public CI workflow such as GHA."

Confirmed impacting all collection releases, and back to ansible-core 2.8 (did not test further back).

Ansible before versions 2.1.4, 2.2.1 is vulnerable to an improper input validation in Ansible's handling of data sent from client systems. An attacker with control over a client system being managed by Ansible and the ability to send facts back to the Ansible server could use this flaw to execute arbitrary code on the Ansible server using the Ansible server privileges.

Ansible Tower (aka Ansible UI) before 2.0.5 allows remote attackers to bypass authentication and obtain sensitive information via a websocket connection to socket.io/1/.

Ansible Tower (aka Ansible UI) before 2.0.5 allows remote organization administrators to gain privileges by creating a superuser account.

Multiple cross-site scripting (XSS) vulnerabilities in Ansible Tower (aka Ansible UI) before 2.0.5 allow remote attackers to inject arbitrary web script or HTML via the (1) orderby parameter to credentials/, (2) inventories/, (3) projects/, or (4) users/3/permissions/ in api/v1/ or the (5) nextrun parameter to api/v1/schedules/.

by default, ansible try to create a ControlMaster file in a predictible location in /tmp. This is vulnerable to a ssh socket injection attack like this :

~ $ sudo ln -s /tmp/ansible-ssh-elspeth.example.org-22-misc /tmp/ansible-ssh-sisay.example.org-22-misc

~ $ ansible -i 'elspeth.example.org,sisay.example.org' all -m shell -u misc -a hostname elspeth.example.org | success | rc=0 >> elspeth.example.org

sisay.example.org | success | rc=0 >> elspeth.example.org

I also did a test without using root, that's the same. Based on this attack, someone could divert the ssh connexion to another server, make it connect to a server under the control of attacker, and steal configuration file ( with passwords ), or steal password with a fake sudo ( since ansible can also use sudo )

Please note that you need to : - disable selinux setenforce 0

- disable latest protection from the kernel

sysctl -w fs.protectedsymlinks=0 sysctl -w fs.protectedhardlinks=0

to make sure this work. I didn't found how/where ssh control the socket file for suitability, maybe it should

I am not sure what could be a good fix. I do have a patch that put the socket in $XDGRUNTIMEDIR but it is a very weak mitigation technique that do not work on older platform such as RHEL 6.

Another solution would be to make sure the socket is created in specific temporary directory, but this could make the software much slower.

And checking if the socket exist first is prone to race condition.

Upstream was not contacted yet, and plan to release 1.3 around 2 weeks. Issue is not public ( but quite easy to spot )

Since version 1.2 of ansible, failed run ( due to connexion errors, or config error ) are listed into /var/tmp/ansible/$scriptname.yml , with $scriptname being the script name used ( or rather the playbook, in ansible linguo )

There is no verification on the file or directory here, and /var/tmp is world writable.

Worst, due to it using a subdirectory under /var/tmp, some symlink protection may not apply ( not tested ). For example, if i create a directory /var/tmp/ansible with owner misc:users and a symlink to a file of joe, the kernel would permit to follow since the symlink and owner of the directory match. This permit to erase file content among others. I am not sure what kind of specific attack could be made by injecting ip and hostname in a specific file, but I am sure this exist.

Code is on https://github.com/ansible/ansible/blob/devel/lib/ansible/playbook/init.py#L480

Upstream was not notified yet AFAIK.

I do have a patch almost ready that do : - verify the permission/owner of directory - create a unique directory derived from username ( so predictable ) with proper permission if doesn't exist

I just need to review and test.

The current code do cope with lack of permission on the directory so even if someone create a directory in advance, this will be handled "gracefully" ( I think a message would be better )

A race condition was found in ansible-runner where an attacker could watch for a rapid creation and deletion of a temporary directory, substitute their own directory at that name, and then have access to ansible-runner's privatedatadir the next time ansible-runner made use of the privatedatadir.

Upstream patch:

https://github.com/ansible/ansible-runner/pull/742/commits/0e9aa8a97e7832ef9a1553ef2908632a32d2b8c4

Running inventories of ~60k hosts no longer takes a very long time for events to show up Removed artifactdata from data sent to analytics as part of playbookonstats, since artifactdata can contain PII or sensitive data Regular users are no longer experiencing longer load times than a superuser when clicking to edit a job template Updated password validation support to allow modifying password complexity requirements using some Django configurations Fixed AWS inventory tags filtering to support the OR condition Updated Ansible version to 2.9.25 Updated Django version to 2.2.20 Fixed Tower's NGINX Instance vulnerability (CVE-2021-23017)

It is reported that in Ansible, under some circumstances the mysqluser module may fail to correctly change a password. Thus an old password may still be active when it should have been changed.

External References: https://github.com/ansible/ansible-modules-core/pull/5388

A security flaw was found in the way Ansible, a SSH-based configuration management, deployment, and task execution system, performed remote server's SSH host key management (previously ability to store known SSH server's host keys to local cache was not supported). A remote attacker could use this flaw to conduct man-in-the-middle (MiTM) attacks against the Ansible task execution system user.

References: [1] http://www.openwall.com/lists/oss-security/2013/07/01/2 [2] http://www.openwall.com/lists/oss-security/2013/07/02/6

Upstream bug (no upstream patch as of 2013-07-03): [3] https://github.com/ansible/ansible/issues/857