CVE-2026-84474 in Ansible Automation Platform
Summary
by MITRE • 09/23/2026
A flaw was found in Red Hat Ansible Automation Platform's automation- controller. The provisioning-callback secret (host_config_key) is exposed to users holding only the read-level view_jobtemplate permission -- both in the job template API representation and in the activity stream -- and the provisioning callback endpoint trusts a client-supplied X-Forwarded-For header to determine the calling host when the controller is deployed behind the AAP gateway with an empty proxy allow-list. By reading the secret and spoofing X-Forwarded-For to match any host in the job template's inventory, a minimally privileged or unauthenticated remote attacker can launch the job template against arbitrary managed hosts using the job template's credentials, resulting in privilege escalation and remote code execution on managed hosts.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The vulnerability identified within Red Hat Ansible Automation Platform’s automation-controller component represents a critical intersection of information disclosure and header injection flaws that collectively enable severe security breaches. The core issue stems from an improper access control mechanism where the provisioning-callback secret, technically known as host_config_key, is inadvertently exposed to users possessing only read-level permissions on job templates. This exposure occurs in two distinct vectors: first through the direct API representation of the job template and second via entries within the activity stream logs. In a properly secured system, such sensitive authentication tokens should be restricted to administrative roles or strictly internal service accounts, as they serve as the primary credential for nodes to check-in with the controller. By leaking this secret to lower-privileged users, the platform violates fundamental principles of least privilege and secure data handling, effectively handing attackers the keys required to authenticate against the provisioning callback endpoint without needing valid user credentials for that specific action.
The second critical flaw involves the validation logic applied to the X-Forwarded-For header when the controller is deployed behind an Ansible Automation Platform gateway with an empty proxy allow-list. In standard reverse-proxy architectures, the X-Forwarded-For header is used to identify the originating IP address of a client connecting through HTTP proxies or load balancers. However, in this specific configuration, the automation-controller blindly trusts the value provided by the client in this header without sufficient validation against known trusted sources. This lack of strict source verification allows an attacker to spoof their apparent origin IP address. When combined with the leaked host_config_key, this capability transforms a simple information leak into a powerful attack vector. The system fails to distinguish between legitimate internal traffic and maliciously crafted requests that mimic internal infrastructure addresses, thereby bypassing intended network-level security boundaries.
The operational impact of these compounded vulnerabilities is severe, leading directly to privilege escalation and remote code execution on managed hosts. An attacker with minimal privileges or even unauthenticated access can exploit the exposed host_config_key to authenticate against the provisioning callback endpoint. Simultaneously, by spoofing the X-Forwarded-For header to match an IP address associated with a target host in the job template’s inventory, the attacker tricks the controller into believing that the request originates from that specific managed node. Consequently, the system executes the job template using its stored credentials against arbitrary targets defined within that inventory. This results in the execution of Ansible playbooks on systems that were not intended to be accessed by the attacker, leading to a complete compromise of those hosts. The ability to run jobs with elevated privileges means attackers can install malware, exfiltrate data, pivot further into the network, or disrupt critical business operations depending on the permissions granted to the job template’s service account.
From a classification perspective, this vulnerability aligns with CWE-200, which covers Exposure of Sensitive Information to an Unauthorized Actor, due to the leakage of the host_config_key in API responses and logs. Furthermore, it relates closely to CWE-749, where a system exposes a dangerous method or functionality to unauthorized users. The exploitation technique involving the manipulation of proxy headers corresponds to CWE-15, External Control of System or Configuration Setting, as well as aspects of CWE-287, Improper Authentication, because the attacker bypasses expected authentication controls by spoofing identity attributes. In terms of offensive security frameworks like MITRE ATT&CK, this scenario maps to T1078, Valid Accounts, specifically through the misuse of existing system or service accounts via credential theft and impersonation. It also touches upon T1534, Internal Spearphishing, in a broader sense by leveraging internal trust relationships within the automation infrastructure to move laterally across managed hosts.
Mitigation strategies must address both the information disclosure and the header validation flaws immediately. Administrators should ensure that their Red Hat Ansible Automation Platform is updated to the latest patched version provided by Red Hat, which resolves these specific access control and input validation issues. For environments where immediate patching is not feasible, a temporary workaround involves restricting API permissions so that no user with read-only access to job templates can view detailed configurations containing sensitive keys. Additionally, reviewing activity stream logs for exposure of secrets and implementing strict logging sanitization protocols can reduce the attack surface. Network-level mitigations include configuring the Ansible Automation Platform gateway proxy allow-list correctly to ensure only trusted internal IPs are recognized as valid sources for X-Forwarded-For headers. This prevents attackers from spoofing internal IP addresses even if they possess other credentials. Regular audits of job template permissions and inventory configurations should also be conducted to enforce strict least privilege principles, ensuring that sensitive automation secrets are never exposed in contexts where lower-level users might access them.