Controller registers LOGAGGREGATORHOST as a bare CharField with no character validation, and the logging settings validator only verifies that host/type are present. When any LOGAGGREGATOR setting is changed via PATCH /api/controller/v2/settings/logging/ (superuser-only), Controller regenerates /var/lib/awx/rsyslog/rsyslog.conf and restarts awx-rsyslogd. In the tcp/udp (omfwd) code path the host value is written raw as target="{host}", allowing an attacker to close the action() statement and append module(load="omprog") plus an omprog action() whose binary= runs an arbitrary shell command in the rsyslog control-plane component (uid=awx). That process can read SECRETKEY and the Postgres credentials, decrypt every stored Credential, and forge inter-service JWTs. Upstream: https://github.com/ansible/awx (devel) — UNFIXED (no PR) Affected file: awx/main/utils/externallogging.py (constructrsyslogconftemplate: :26 spoolDirectory, :100 errorfile, :128 target); awx/main/conf.py (:565-574, :958-979); awx/conf/views.py (:131-133)

A flaw was found in the Ansible Automation Platform automation-controller notification subsystem. CustomEmailBackend (awx/main/notifications/emailbackend.py:24) is a thin subclass of django.core.mail.backends.smtp.EmailBackend and does not override open()/sendmessages() to validate its connect target, so the user-controlled notificationconfiguration.host and .port reach smtplib.SMTP(host, port, timeout=...) with no allow-list and no private/loopback/ link-local/reserved rejection. An organization-scoped Notification Admin (awx.notificationadminrole, checked by NotificationTemplateAccess.canadd/canchange at awx/main/access.py:2578/2582 — a delegatable, non-superuser role) can create or PATCH an email notification template with host/port pointing at any internal address and POST the template's /test/ endpoint. The dispatcher runs the backend on the controller-task pod, which opens a raw TCP connection to the attacker-chosen host:port. The smtplib exception string is persisted verbatim into Notification.error (a plain TextField, awx/main/models/notifications.py:219) and is readable over the API, producing a three-state oracle: "[Errno 111] Connection refused" (closed), "timed out" (filtered), and "Connection unexpectedly closed: timed out" or an SMTPResponseException (open). Because the transport is a raw socket, the flaw reaches non-HTTP internal services (for example Redis, PostgreSQL, receptor) and the in-cluster Kubernetes API, and can send SMTP-protocol bytes into those listeners. In addition, the SMTP AUTH exchange transmits the template's stored, otherwise write-only password to the configured host, so a user who can change the host on a shared organization template can exfiltrate its stored SMTP password. The HTTP-based notification backends (webhook, grafana, mattermost, rocketchat) were hardened against this on the 2.7 branch via awx/main/notifications/urlvalidation.py::validateurl(); the email backend (and the IRC backend) were omitted from that hardening. That guard is present only on the 2.7 branch; on the 2.5, 2.6, and development branches it is absent and no notification backend validates its connect target.

Upstream: https://github.com/ansible/tower (awx) Affected file: awx/main/notifications/emailbackend.py:24 (CustomEmailBackend, no host validation); awx/main/models/notifications.py:219 (Notification.error oracle sink); awx/main/access.py:2559-2582 (notificationadminrole). Guard (2.7 only): awx/main/notifications/urlvalidation.py::validateurl (added by tower #7875).

A flaw was found in the Ansible Automation Platform automation-controller notification subsystem. CustomEmailBackend (awx/main/notifications/emailbackend.py:24) is a thin subclass of django.core.mail.backends.smtp.EmailBackend and does not override open()/sendmessages() to validate its connect target, so the user-controlled notificationconfiguration.host and .port reach smtplib.SMTP(host, port, timeout=...) with no allow-list and no private/loopback/ link-local/reserved rejection. An organization-scoped Notification Admin (awx.notificationadminrole, checked by NotificationTemplateAccess.canadd/canchange at awx/main/access.py:2578/2582 — a delegatable, non-superuser role) can create or PATCH an email notification template with host/port pointing at any internal address and POST the template's /test/ endpoint. The dispatcher runs the backend on the controller-task pod, which opens a raw TCP connection to the attacker-chosen host:port. The smtplib exception string is persisted verbatim into Notification.error (a plain TextField, awx/main/models/notifications.py:219) and is readable over the API, producing a three-state oracle: "[Errno 111] Connection refused" (closed), "timed out" (filtered), and "Connection unexpectedly closed: timed out" or an SMTPResponseException (open). Because the transport is a raw socket, the flaw reaches non-HTTP internal services (for example Redis, PostgreSQL, receptor) and the in-cluster Kubernetes API, and can send SMTP-protocol bytes into those listeners. In addition, the SMTP AUTH exchange transmits the template's stored, otherwise write-only password to the configured host, so a user who can change the host on a shared organization template can exfiltrate its stored SMTP password. The HTTP-based notification backends (webhook, grafana, mattermost, rocketchat) were hardened against this on the 2.7 branch via awx/main/notifications/urlvalidation.py::validateurl(); the email backend (and the IRC backend) were omitted from that hardening. That guard is present only on the 2.7 branch; on the 2.5, 2.6, and development branches it is absent and no notification backend validates its connect target.

Upstream: https://github.com/ansible/tower (awx) Affected file: awx/main/notifications/emailbackend.py:24 (CustomEmailBackend, no host validation); awx/main/models/notifications.py:219 (Notification.error oracle sink); awx/main/access.py:2559-2582 (notificationadminrole). Guard (2.7 only): awx/main/notifications/urlvalidation.py::validateurl (added by tower #7875).

A flaw was found in the Ansible Automation Platform automation-controller request handling. The shipped production settings define REMOTEHOSTHEADERS=['HTTPXFORWARDEDFOR'] and PROXYIPALLOWEDLIST=[] (empty). In APIView.initializerequest (awx/api/generics.py:199-201), client-supplied REMOTEHOSTHEADERS are stripped only when PROXYIPALLOWEDLIST is non-empty and the request did not arrive through a listed proxy; with the empty shipped allow-list this guard is skipped and the X-Forwarded-For header is never stripped. When the client IP is resolved via getremotehost()/getremotehosts() (django-ansible-base ansiblebase/lib/utils/requests.py), the function reads REMOTEHOSTHEADERS in order and returns the first (leftmost) X-Forwarded-For entry. Because the deployment fronts Controller with Envoy, which by default appends (rather than replaces) the real client IP to the incoming X-Forwarded-For header, an attacker-supplied leftmost value survives to the application and is chosen as the client IP. That spoofed value is written into the Controller's audit/access logging, including the login audit message ("User <username> logged in from <ip>") and the API 4xx error log's remoteaddr field (API400ERRORLOGFORMAT). An attacker can therefore forge the source IP attributed to API actions in Controller logs and any downstream SIEM keyed on client IP. Unauthenticated failed-login and error log entries can likewise be attributed to arbitrary IPs. A secure mechanism already exists but is not enabled by default: when a valid HTTPXTRUSTEDPROXY shared-secret header is present, getremotehosts prefers the trusted last/rightmost X-Forwarded-For entry (the value Envoy appends) and honors x-envoy-external-address. The flaw affects only audit/forensic integrity and does not grant additional access.

Upstream: https://github.com/ansible/tower (awx) and https://github.com/ansible/django-ansible-base (getremotehost[s]) Affected file: awx/api/generics.py:199-201 (guard), :119 and :246-265 (sinks); awx/settings/productiondefaults.py:23; awx/settings/defaults.py:166; ansiblebase/lib/utils/requests.py:14-16,38-42,65-66

A flaw was found in the Ansible Automation Platform automation-controller webhook receivers. The Bitbucket Data Center webhook receiver at POST /api/controller/v2/{jobtemplates,workflowjobtemplates}/<pk>/bitbucketdc/ is intentionally unauthenticated (permissionclasses=(AllowAny,), authenticationclasses=()) and authorizes requests by verifying an HMAC over the request body keyed by the per-template webhookkey. BitbucketDcWebhookReceiver.mustchecksignature() returns False when the X-Event-Key request header is 'diagnostics:ping', because Bitbucket does not sign ping requests. This carve-out is evaluated only after the receiver has already resolved the target template: getobject() filters templates to those with webhookservice='bitbucketdc' and a non-empty webhookkey and raises PermissionDenied (HTTP 403) when no template matches, whereas a matching template proceeds past the skipped signature check to the ping short-circuit and returns HTTP 200 with the body "Webhook ignored". As a result, an unauthenticated remote attacker who sends a diagnostics:ping request to each template ID observes a 200-vs-403 response discrepancy that reveals exactly which Job Template and Workflow Job Template IDs have Bitbucket DC webhooks configured, with no credentials and no knowledge of the webhookkey. This is unauthenticated reconnaissance: it confirms valid template IDs, reveals which automation is wired to Bitbucket Data Center, and lets an attacker focus subsequent webhookkey brute-force or SCM-side spoofing attempts on the small set of templates that would actually accept signed payloads. The ping path performs no action and no secret values are disclosed.

Upstream: https://github.com/ansible/tower (awx) Affected file: awx/api/views/webhooks.py:306-308 (BitbucketDcWebhookReceiver.mustchecksignature), with webhooks.py:69-78 (getobject) and :144-146 (post ping short-circuit)

A flaw was found in the Ansible Automation Platform automation-controller webhook receivers. The Bitbucket Data Center webhook receiver at POST /api/controller/v2/{jobtemplates,workflowjobtemplates}/<pk>/bitbucketdc/ is intentionally unauthenticated (permissionclasses=(AllowAny,), authenticationclasses=()) and authorizes requests by verifying an HMAC over the request body keyed by the per-template webhookkey. BitbucketDcWebhookReceiver.mustchecksignature() returns False when the X-Event-Key request header is 'diagnostics:ping', because Bitbucket does not sign ping requests. This carve-out is evaluated only after the receiver has already resolved the target template: getobject() filters templates to those with webhookservice='bitbucketdc' and a non-empty webhookkey and raises PermissionDenied (HTTP 403) when no template matches, whereas a matching template proceeds past the skipped signature check to the ping short-circuit and returns HTTP 200 with the body "Webhook ignored". As a result, an unauthenticated remote attacker who sends a diagnostics:ping request to each template ID observes a 200-vs-403 response discrepancy that reveals exactly which Job Template and Workflow Job Template IDs have Bitbucket DC webhooks configured, with no credentials and no knowledge of the webhookkey. This is unauthenticated reconnaissance: it confirms valid template IDs, reveals which automation is wired to Bitbucket Data Center, and lets an attacker focus subsequent webhookkey brute-force or SCM-side spoofing attempts on the small set of templates that would actually accept signed payloads. The ping path performs no action and no secret values are disclosed.

Upstream: https://github.com/ansible/tower (awx) Affected file: awx/api/views/webhooks.py:306-308 (BitbucketDcWebhookReceiver.mustchecksignature), with webhooks.py:69-78 (getobject) and :144-146 (post ping short-circuit)

A flaw was found in Ansible Automation Platform's automation-controller. Custom Credential Types let an author define injectors.env (environment variables set in the execution environment when a credential of that type is attached to a job) and injectors.file (files rendered into the execution environment whose path is exposed to other injectors as {{ tower.filename }}). The env-variable names are validated only by a deny-list: CredentialTypeInjectorField.validateenvvarallowed (awx/main/fields.py:689-701) rejects names beginning with "ANSIBLE" and names present in the ENVBLOCKLIST frozenset (awx/main/constants.py:48-70). The stated purpose of this control is to stop injectors from hijacking the runner process (it blocks PATH, PYTHONPATH, VIRTUALENV and all ANSIBLE configuration variables). The deny-list is incomplete: it does not include BASHENV, ENV, LDPRELOAD, LDLIBRARYPATH, LDAUDIT, PYTHONSTARTUP, PYTHONWARNINGS, GITSSHCOMMAND, PERL5OPT, or similar loader/ process-hijacking variables, so those names pass validation. An attacker can therefore define a credential type whose file injector writes a shell script and whose env injector sets BASHENV to {{ tower.filename }}. Every non-interactive bash process spawned during a job (Ansible modules shell out constantly) then sources and executes the attacker's script, yielding arbitrary code execution inside the execution-environment container — independent of the playbook content — for any job that attaches a credential of the malicious type, with access to the secrets of all co-attached credentials in the same job environment and to any inventory host the job can reach. The same weak check is repeated at the runtime injection sink (awxplugins.interfaces temporaryprivateinjectapi.py, which re-checks only ENVBLOCKLIST), so the fix must be applied in both places. Creating a custom credential type requires Controller superuser (CredentialTypeAccess inherits BaseAccess), so this is primarily a defense-in-depth bypass of a control whose explicit purpose is to constrain exactly this behavior; however, an organization-level Credential Admin (not a superuser) can weaponize an already-existing malicious custom type, and in Gateway-managed AAP 2.5+ the platform-admin role is explicitly not host/EE root, so code execution in the execution environment via a configuration API crosses a real trust boundary.

Upstream: https://github.com/ansible/tower (private) / awxplugins.interfaces Affected files: awx/main/fields.py:689-701; awx/main/constants.py:48-70; awxplugins/interfaces/temporaryprivateinjectapi.py:263-288

A flaw was found in Ansible Automation Platform's automation-controller. Custom Credential Types let an author define injectors.env (environment variables set in the execution environment when a credential of that type is attached to a job) and injectors.file (files rendered into the execution environment whose path is exposed to other injectors as {{ tower.filename }}). The env-variable names are validated only by a deny-list: CredentialTypeInjectorField.validateenvvarallowed (awx/main/fields.py:689-701) rejects names beginning with "ANSIBLE" and names present in the ENVBLOCKLIST frozenset (awx/main/constants.py:48-70). The stated purpose of this control is to stop injectors from hijacking the runner process (it blocks PATH, PYTHONPATH, VIRTUALENV and all ANSIBLE configuration variables). The deny-list is incomplete: it does not include BASHENV, ENV, LDPRELOAD, LDLIBRARYPATH, LDAUDIT, PYTHONSTARTUP, PYTHONWARNINGS, GITSSHCOMMAND, PERL5OPT, or similar loader/ process-hijacking variables, so those names pass validation. An attacker can therefore define a credential type whose file injector writes a shell script and whose env injector sets BASHENV to {{ tower.filename }}. Every non-interactive bash process spawned during a job (Ansible modules shell out constantly) then sources and executes the attacker's script, yielding arbitrary code execution inside the execution-environment container — independent of the playbook content — for any job that attaches a credential of the malicious type, with access to the secrets of all co-attached credentials in the same job environment and to any inventory host the job can reach. The same weak check is repeated at the runtime injection sink (awxplugins.interfaces temporaryprivateinjectapi.py, which re-checks only ENVBLOCKLIST), so the fix must be applied in both places. Creating a custom credential type requires Controller superuser (CredentialTypeAccess inherits BaseAccess), so this is primarily a defense-in-depth bypass of a control whose explicit purpose is to constrain exactly this behavior; however, an organization-level Credential Admin (not a superuser) can weaponize an already-existing malicious custom type, and in Gateway-managed AAP 2.5+ the platform-admin role is explicitly not host/EE root, so code execution in the execution environment via a configuration API crosses a real trust boundary.

Upstream: https://github.com/ansible/tower (private) / awxplugins.interfaces Affected files: awx/main/fields.py:689-701; awx/main/constants.py:48-70; awxplugins/interfaces/temporaryprivateinjectapi.py:263-288

A flaw was found in automation-controller (AWX). Write-only survey password values stored on Schedules and WorkflowJobTemplateNodes are encrypted at rest and masked as $encrypted$ on read. LaunchConfigurationBaseSerializer.validate (awx/api/serializers.py) replaces an incoming $encrypted$ with the stored DB ciphertext and revalidates prompts against the job template's current surveyspec; SurveyJobTemplateMixin.acceptorignorevariables (awx/main/models/mixins.py) decrypts the stored password before validation, and surveyelementvalidation interpolates the decrypted plaintext into the "value ... is too small/too large" min/max error for text/textarea/password questions. The error dict is returned verbatim as the HTTP 400 body. A user holding only the delegated JobTemplate Admin role can POST a tightened surveyspec (e.g. "max":1) and then PATCH a schedule of that job template -- either echoing $encrypted$ for the variable, or simply re-stating unifiedjobtemplate to force full-prompt revalidation without knowing the variable name (serializers.py forces full revalidation when unifiedjobtemplate is present) -- and read the stored plaintext password of a schedule created by a different, higher-privileged user (ScheduleAccess.canchange grants a JT admin write on all schedules of the template regardless of creator). The same base serializer backs WorkflowJobTemplateNodeSerializer, so workflow nodes are equally affected. Discovered internally; verified live on AAP 2.7 / automation-controller 4.8.1; still present on devel. Upstream: github.com/ansible/awx (api/serializers.py LaunchConfigurationBaseSerializer; main/models/mixins.py surveyelementvalidation / acceptorignorevariables; main/access.py ScheduleAccess.canchange)

A flaw was found in Ansible Automation Platform's automation-controller (AWX). The Bulk Job Launch API (POST /api/v2/bulk/joblaunch/) authorizes the requested instancegroups 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.

A flaw was found in automation-controller (AWX). In awx/api/serializers.py, BulkJobLaunchSerializer.validate() authorizes the instancegroups many-to-many field via checklistpermission(InstanceGroup, ...) with no action argument, which the helper interprets as a read-level check (user.getqueryset(model)). The equivalent single-job launch path (awx/main/access.py, JobLaunchConfigAccess.canadd) checks the same field at use level (useinstancegroup / userole) and raises HTTP 403 on failure. The bulk view enforces only IsAuthenticated, so the under-scoped serializer check is the sole authorization for instance-group placement. Because user.getqueryset(InstanceGroup) returns all instance groups for a System Auditor (and any read-visible group for other users), a caller with execute on a job template and read (not use) on an instance group can POST to /api/v2/bulk/joblaunch/ and have the job actually placed on that group, bypassing execution-placement isolation. The maintainers' own inline comments ("# TODO: change to userole for conflict" and "duplicated with BulkJobLaunchSerializer, check when changing permission levels") mark the gap. Inventory and Credential fields on the same bulk path are correctly checked at use level; instancegroups is the outlier. Upstream: github.com/ansible/awx (serializers.py BulkJobLaunchSerializer) Present at: tag 24.6.1 (commit 94e5795) and devel HEAD

For GitHub pullrequest webhooks, geteventstatusapi() in awx/api/views/webhooks.py returns pullrequest.statusesurl from the request body verbatim without any host validation:

def geteventstatusapi(self): if self.geteventtype() != 'pullrequest': return return self.request.data.get('pullrequest', {}).get('statusesurl')

The value is persisted into job extravars and later used by updatewebhookstatus() in awx/main/models/mixins.py:

statusapi = self.extravarsdict.get('awxwebhookstatusapi') headers = {k: v.format(self.webhookcredential.getinput('token')), 'Content-Type': 'application/json'} response = requests.post(statusapi, data=json.dumps(data), headers=headers, timeout=30)

There is no host allowlist for the expected Git provider endpoint and no private-network egress filtering before the request is sent. The webhook receiver relies on an HMAC secret (webhookkey), which is readable by users with the admin role on the job template via /api/v2/jobtemplates/{id}/webhookkey/. This allows a template admin to forge a signed webhook payload with statusesurl pointing to an attacker-controlled endpoint, and AWX will POST status updates including the Git PAT in the Authorization header to that endpoint.

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 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 the AAP Controller's HashiCorp Vault credential integration. When a HashiCorp Vault Secret Lookup credential is configured with kubernetesrole authentication, the credential test endpoint (POST /api/controller/v2/credentials/{id}/test/) triggers the kubernetesauth() function which reads the controller pod's Kubernetes service account token from /var/run/secrets/kubernetes.io/serviceaccount/token and POSTs it as {"jwt": "<satoken>", "role": "<role>"} to the user-supplied vault URL. There is no validation or restriction on the vault URL target. An authenticated attacker with credential-creation privileges can set the vault URL to an attacker-controlled server and capture the SA token. The exfiltrated token (system:serviceaccount:ansible-automation-platform:automation-controller) has broad Kubernetes RBAC permissions including: full pod CRUD (get,list,watch,create,update,patch,delete) in both ansible-automation-job and ansible-automation-platform namespaces, and individual secret access (get,create,delete) in both namespaces. This allows the attacker to read database credentials, the Django SECRETKEY, and access all 31+ pods in the AAP platform namespace. In AAP Cloud (managed service) environments, this constitutes a tenant-to-infrastructure escape as the control plane is managed by Red Hat. The token has an approximately 1-year lifetime.

Upstream: https://github.com/ansible/awx (awxplugins/credentials/hashivault.py) Affected function: kubernetesauth() at hashivault.py:462-468 Reporter: Chris Meyers (internal — cmeyers) Tested against: platform.cus-0616.aws.ansiblecloud.com (AAP Cloud, ROSA)

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 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-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 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.

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

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']

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 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.

"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).

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)

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