CVE-2026-84718: Automation-controller: automation-controller: client ip spoofing in audit/access logs via unrestricted x-forwarded-for trust
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
Other sources
A flaw was found in the Ansible Automation Platform automation-controller. In the shipped production configuration, the Controller trusts the client-supplied X-Forwarded-For header as the request's client IP without verifying that it originated from a trusted proxy, and selects the leftmost (attacker-controlled) header value. As a result, an attacker can forge the source IP address recorded for their requests in the Controller's audit and access logs, degrading the integrity of forensic and SIEM attribution. The flaw does not grant additional access.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Populate PROXY_IP_ALLOWED_LIST with the trusted proxy IP addresses instead of leaving it empty, so client-supplied REMOTE_HOST_HEADERS such as HTTP_X_FORWARDED_FOR are stripped unless the request arrives through a listed proxy.
Ansible Automation Platform automation-controller PROXY_IP_ALLOWED_LIST = IP addresses of trusted proxies
Event History
Frequently Asked Questions
Which deployments are exposed to spoofed client IP addresses?
Deployments using the shipped production settings are exposed because they trust HTTP_X_FORWARDED_FOR while leaving PROXY_IP_ALLOWED_LIST empty. The described exposure applies when Controller is fronted by Envoy configured with its default behavior of appending the real client IP to, rather than replacing, an incoming X-Forwarded-For header.
What does an attacker need to exploit this issue?
The CVSS vector indicates network access, low privileges, and no user interaction are required. The attacker must be able to send a request with an attacker-controlled X-Forwarded-For header value that survives to the Controller application.
What is the practical impact of successful exploitation?
The attacker can cause Controller to record a spoofed client IP in audit and access logs. This includes login audit messages and API 4xx error logs, reducing the integrity and reliability of records used for investigation and attribution.
How can an administrator verify whether logs are affected?
Inspect the production settings for REMOTE_HOST_HEADERS containing HTTP_X_FORWARDED_FOR and an empty PROXY_IP_ALLOWED_LIST, then verify whether the Envoy proxy appends incoming X-Forwarded-For values. A controlled request carrying a chosen leftmost X-Forwarded-For value can confirm the condition if that value is recorded as the client IP in Controller logs.