CVE-2026-84706 in Ansible Automation Platform
Summary
by MITRE • 09/23/2026
A flaw was found in Ansible Automation Platform's automation-controller. The custom Credential Type environment-variable injector validates variable names against a deny-list (an ANSIBLE_* prefix check plus a fixed ENV_BLOCKLIST) that omits process-hijacking loader variables such as BASH_ENV, ENV, LD_PRELOAD, LD_LIBRARY_PATH, PYTHONSTARTUP and GIT_SSH_COMMAND. Combined with the credential file injector, a privileged user can write an attacker-controlled script into the execution environment and point BASH_ENV at it, obtaining arbitrary code execution inside the execution-environment container for any job that attaches a credential of that type.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/23/2026
The vulnerability in Ansible Automation Platform's automation-controller represents a critical security flaw rooted in insufficient input validation within the custom Credential Type environment-variable injector mechanism. This component is designed to manage how credentials are injected into execution environments, specifically by validating variable names against a predefined deny-list intended to prevent attackers from manipulating sensitive system variables. However, this implementation relies on an incomplete filtering strategy that checks for the ANSIBLE_* prefix and a fixed list of blocked environmental variables but fails to account for other process-hijacking loader variables such as BASH_ENV, ENV, LD_PRELOAD, LD_LIBRARY_PATH, PYTHONSTARTUP, and GIT_SSH_COMMAND. This oversight creates a significant gap in defense-in-depth strategies, allowing malicious actors to bypass the intended security controls by utilizing these unblocked environment variables to execute arbitrary code within the containerized execution environments used for job processing.
From a technical perspective, the flaw exploits the interaction between the credential file injector and the incomplete variable validation logic. When a privileged user configures a custom Credential Type that utilizes this flawed injector, they can specify an environment variable name that is not present in the deny-list but is recognized by underlying system interpreters or libraries as a configuration hook for loading external scripts or shared objects. For instance, setting BASH_ENV to point to a file containing malicious shell commands causes bash to execute those commands upon initialization of any new shell session within the container. Similarly, LD_PRELOAD allows an attacker to inject dynamic library code that runs before main(), effectively hijacking process execution flow. The combination of these unblocked variables with the ability to write arbitrary content into files accessible by the job runner enables a direct path to remote code execution without requiring additional privilege escalation steps beyond those already granted to the user managing credentials.
The operational impact of this vulnerability is severe, as it allows for arbitrary code execution inside the execution-environment container for any job that attaches a credential of the affected type. Since Ansible Automation Platform often runs jobs with elevated privileges or within isolated containers intended to be secure boundaries between different tenants or projects, gaining control over these environments can lead to broader compromise of the automation infrastructure. An attacker could exfiltrate sensitive data processed by automated workflows, pivot into other systems accessible from the execution environment, or disrupt service availability by corrupting job states. This undermines the fundamental trust model of the platform where users are expected to manage credentials safely without compromising the integrity of the underlying runtime containers.
This vulnerability aligns with CWE-78 Improper Neutralization of Special Elements used in an OS Command and CWE-94 Improper Control of Generation of Code, reflecting a failure to properly sanitize inputs that influence system behavior. In terms of threat modeling, it maps to MITRE ATT&CK techniques such as T1059 Command and Scripting Interpreter for executing arbitrary commands via environment variables like BASH_ENV or PYTHONSTARTUP, and potentially T1648 Elevated Execution with Forced User Interaction if the attack requires specific job configurations that trigger the vulnerable code paths. The exploitation vector is primarily local to the automation controller's configuration but results in remote execution capabilities within the target containers, highlighting a critical misalignment between intended security boundaries and actual implementation constraints.
Mitigation strategies must focus on hardening the environment variable validation logic within the custom Credential Type injector. Administrators should update their Ansible Automation Platform instances to versions where this flaw has been addressed by expanding the deny-list to include all known process-hijacking variables such as BASH_ENV, ENV, LD_PRELOAD, and others that can influence interpreter or loader behavior. Additionally, organizations should review existing custom Credential Types for any usage of these variable names and reconfigure them to use safe alternatives if possible. Implementing strict least-privilege principles for users who create or modify credential types is also essential, ensuring that only trusted administrators have the ability to define such configurations. Regular auditing of job execution environments and monitoring for unusual process launches originating from environment variables can help detect potential exploitation attempts in real-time while patching efforts are underway.