CVE-2026-84718: Ansible Automation Platform IP Spoofing Flaw

CVE-2026-84718 Overview

CVE-2026-84718 is a source IP spoofing flaw in the Red Hat Ansible Automation Platform automation-controller. The shipped production configuration trusts the client-supplied X-Forwarded-For header without verifying that requests originated from a trusted reverse proxy. The controller selects the leftmost (attacker-controlled) value as the client IP. As a result, an authenticated attacker can forge the source IP recorded in the controller's audit and access logs. The flaw does not grant additional access or elevated privileges. Its impact is limited to degrading the integrity of forensic evidence and Security Information and Event Management (SIEM) attribution [CWE-348: Use of Less Trusted Source].

Critical Impact
Attackers can forge the client IP recorded in Ansible Automation Platform audit logs, undermining incident response attribution and SIEM correlation.

Affected Products

Red Hat Ansible Automation Platform automation-controller (production configuration)
Red Hat Ansible Automation Platform 2.x (per Red Hat Security Advisories RHSA-2026:71113 and RHSA-2026:71114)
Red Hat Ansible Automation Platform components covered by RHSA-2026:71177 and RHSA-2026:71179

Discovery Timeline

2026-09-23 - CVE-2026-84718 published to the National Vulnerability Database (NVD)
2026-09-24 - Last updated in NVD database

Technical Details for CVE-2026-84718

Vulnerability Analysis

The automation-controller consumes the HTTP X-Forwarded-For header to determine the originating client IP address for audit logging. In a correct deployment, only a trusted reverse proxy should set this header, and downstream applications must validate that the immediate peer is that proxy. The controller performs no such validation in its shipped production configuration.

The controller also selects the leftmost value in the header chain. RFC 7239 and common proxy conventions treat the leftmost entry as the original client, but that value is trivially forgeable when clients can reach the controller without passing through a validating proxy. An authenticated attacker sending a crafted request can therefore substitute any IP address into audit and access log entries associated with their session.

The vulnerability is a log integrity issue, not an authentication or authorization bypass. Confidentiality and availability are unaffected. The practical impact is on forensic accuracy: log-based attribution, geolocation-based alerting, and SIEM correlation rules that key off source IP become unreliable.

Root Cause

The root cause is improper trust of an unauthenticated request header [CWE-348]. The controller neither restricts X-Forwarded-For processing to requests received from an allowlisted proxy address nor uses the rightmost-trusted algorithm to skip attacker-controlled entries appended by the client.

Attack Vector

Exploitation requires network access to the controller and low-privilege authenticated credentials. The attacker adds an X-Forwarded-For header containing an arbitrary IPv4 or IPv6 address to any authenticated HTTP request. The controller records that forged address in audit and access logs instead of the true socket peer address. No special tooling is required beyond a standard HTTP client. See the Red Hat CVE analysis for CVE-2026-84718 for technical details and the affected code paths.

Detection Methods for CVE-2026-84718

Indicators of Compromise

Audit log entries showing source IP addresses that do not correspond to any known user, VPN pool, or corporate egress range.
Multiple authenticated sessions from a single user account originating from geographically implausible IP addresses within short time windows.
X-Forwarded-For headers containing private (RFC 1918) or loopback addresses on requests reaching an internet-facing controller.
Discrepancies between the client IP recorded by the upstream load balancer or web application firewall and the IP logged by the automation-controller.

Detection Strategies

Cross-correlate controller audit logs with reverse proxy, load balancer, and firewall flow logs to identify requests where the recorded client IP does not match the true socket peer.
Alert on any X-Forwarded-For header containing multiple entries, malformed values, or reserved address ranges reaching the controller.
Baseline expected source IP ranges per user account and flag deviations from that baseline.

Monitoring Recommendations

Ingest automation-controller access and audit logs into a centralized SIEM alongside proxy logs to enable authoritative attribution.
Enable verbose logging on the upstream proxy so the true TCP source IP is preserved independently of application-layer headers.
Monitor for authenticated API activity from accounts that normally interact only via the web UI, as spoofing is most useful for hiding programmatic abuse.

How to Mitigate CVE-2026-84718

Immediate Actions Required

Apply the fixes described in Red Hat Security Advisories RHSA-2026:71113, RHSA-2026:71114, RHSA-2026:71177, and RHSA-2026:71179.
Restrict network access to the automation-controller so only the intended reverse proxy or load balancer can reach it directly.
Review recent audit logs for suspicious X-Forwarded-For values and re-attribute events using upstream proxy logs where possible.
Rotate credentials for any account whose recent activity cannot be independently attributed to a known source.

Patch Information

Red Hat has published fixes for affected Ansible Automation Platform versions. Consult the Red Hat CVE Analysis CVE-2026-84718 page and the following advisories for the exact package versions: RHSA-2026:71113, RHSA-2026:71114, RHSA-2026:71177, and RHSA-2026:71179. Additional context is available in Red Hat Bug Report #2527211.

Workarounds

Terminate all client connections at a trusted reverse proxy (for example, NGINX or HAProxy) and configure the proxy to strip inbound X-Forwarded-For headers before appending its own trusted value.
Configure firewall rules so the automation-controller only accepts HTTP/HTTPS traffic from the proxy's IP address, blocking direct client connections.
If the deployment permits, disable use of X-Forwarded-For for audit attribution and rely on the direct socket peer address until the patch is applied.

bash

# Example NGINX configuration: strip client-supplied X-Forwarded-For
# and set a trusted value before proxying to automation-controller
location / {
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Real-IP       $remote_addr;
    proxy_pass http://automation_controller_upstream;
}

# Firewall: only allow the proxy to reach the controller
iptables -A INPUT -p tcp --dport 443 -s <proxy_ip> -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROP