CVE-2026-84706

Executive Summary

CVE-2026-84706 is an incomplete input-validation flaw (CWE-184) in the Ansible Automation Platform automation-controller custom Credential Type environment-variable injector. The injector validates variable names against an incomplete deny-list (an ANSIBLE_* prefix check plus a fixed ENV_BLOCKLIST) that fails to block process-hijacking loader variables such as BASH_ENV, ENV, LD_PRELOAD, LD_LIBRARY_PATH, PYTHONSTARTUP, and GIT_SSH_COMMAND. A privileged user who can define or attach a custom Credential Type can combine this weakness with the credential file injector to plant an attacker-controlled script in the execution environment and point BASH_ENV at it, achieving arbitrary code execution inside the execution-environment container for any job that attaches a credential of that type. The vulnerability is currently unpatched, has no public PoC, no Nuclei template, and has not been added to CISA KEV.

Technical Analysis

The vulnerability resides in the environment-variable injection subsystem of the automation-controller component of Ansible Automation Platform. Custom Credential Types allow administrators and privileged users to define structured credential fields that the controller injects into the execution environment as environment variables before a job runs.

The injector implements a deny-list based validation strategy rather than an allow-list. Per the NVD description, the deny-list consists of two components:

1. An ANSIBLE_* prefix check — intended to prevent users from overriding Ansible's own environment variables (e.g., ANSIBLE_CONFIG, ANSIBLE_LIBRARY).
2. A fixed ENV_BLOCKLIST — a static list of blocked variable names.

Both mechanisms are structurally insufficient. A deny-list can only block what it enumerates, and the ENV_BLOCKLIST omits well-known process-hijacking and loader variables whose names carry no ANSIBLE_ prefix. The omitted variables explicitly named in the advisory are:

• BASH_ENV — sourced by non-interactive bash shells at startup.
• ENV — the equivalent for POSIX sh and related shells.
• LD_PRELOAD — loads a shared object into every dynamically linked process.
• LD_LIBRARY_PATH — alters library resolution order.
• PYTHONSTARTUP — executes a Python script at interpreter startup.
• GIT_SSH_COMMAND — overrides the SSH command git uses.

Because these names pass validation, a privileged user with credential-type definition rights can set them as injected environment variables. The description states the attack is "combined with the credential file injector" — meaning the same subsystem can write a file into the execution environment. By injecting an attacker-controlled script via the file injector and then setting BASH_ENV (or ENV, PYTHONSTARTUP, etc.) to point at that file, the user causes shell or interpreter startup in the execution-environment container to source the attacker's code.

The result is arbitrary code execution inside the execution-environment container for every job that attaches a credential of that type. The CVSS vector S:C (Scope: Changed) reflects that execution crosses a trust boundary — code executes in the isolated execution container context rather than the controller context, but with the privileges and reach of that container. I:H (Integrity: High) reflects full control over the container's execution; C:L (Confidentiality: Low) reflects limited but non-zero data exposure; A:N reflects no direct availability impact.

It is important to note that exploitation requires high privileges (PR:H, authenticated network access AV:N). The attacker must already hold the ability to create or modify a custom Credential Type and attach it to jobs. This is not an unauthenticated remote code execution flaw — it is a privilege-escalation and container-escape-adjacent weakness in a trusted workflow component.

No specific function names, class names, or code paths beyond those quoted from the NVD description should be assumed. The advisory provides no source-level details of the injector implementation, and none are invented here.

Exploitation Scenarios

No public PoC exists (POC_STATUS: None). The attack chain below is inferred strictly from the vulnerability class (CWE-184, incomplete deny-list validation enabling environment-variable injection) and the explicit mechanics documented in the NVD description.

1) Reconnaissance / target identification. The attacker must possess an authenticated account on the Ansible Automation Platform controller with the privileges required to define custom Credential Types and to configure or trigger jobs that attach them. Reconnaissance focuses on confirming the controller version is an affected build and identifying credential types whose injected variables reach job execution environments.

2) Triggering the specific flaw class. The attacker defines (or modifies) a custom Credential Type whose environment-variable injector supplies a blocked-list-bypassing variable name. Because validation is an incomplete deny-list, variable names such as BASH_ENV, ENV, LD_PRELOAD, LD_LIBRARY_PATH, PYTHONSTARTUP, or GIT_SSH_COMMAND are accepted.

3) Payload/execution method. As documented, the attacker uses the credential file injector to write an attacker-controlled script into the execution environment, then sets the injected BASH_ENV variable to point at that script. When a job with a credential of that type runs, the shell in the execution-environment container sources BASH_ENV at startup, executing the attacker's code. Equivalent effect can be reached through the other omitted loader variables named in the advisory (ENV, PYTHONSTARTUP, LD_PRELOAD, etc.) depending on the interpreter or process that consumes them.

4) Post-exploitation impact. The attacker obtains arbitrary code execution inside the execution-environment container for any job attaching the malicious credential type. From that position, the attacker can manipulate job execution, tamper with build/deployment artifacts, and abuse any credentials or network reachability exposed to that container. The S:C scope change indicates the attacker's code operates in a security context distinct from the controller.

Because no PoC, exploit code, or Nuclei template is available, defenders must reason about this at the vulnerability-class level rather than hunting for known payloads.

Impact Assessment

Confidentiality (C:L). Limited exposure — the advisory rates confidentiality impact low, suggesting the execution container's data access is constrained, but the attacker's code can still read whatever is reachable from within that container.

Integrity (I:H). High. Arbitrary code execution inside the execution environment lets an attacker alter job behavior, inject into pipelines, and tamper with anything the container processes or writes.

Availability (A:N). No direct availability impact is rated.

Scope (S:C). Changed — exploitation crosses from the credential-injection layer into arbitrary execution in a different container context, violating the intended isolation boundary.

Attack Vector (AV:N). Exploitable over the network by an authenticated privileged user.

Privileges Required (PR:H). The attacker must already hold elevated privileges on the controller sufficient to define custom Credential Types and attach them to jobs. This substantially limits the population of attackers but does not eliminate the risk: in multi-tenant or delegated-administration automation platforms, a privileged tenant or a compromised admin account can abuse this to pivot into execution-container context.

Blast radius. Every job that attaches a credential of the malicious type executes attacker code. If the credential type is reused across many projects or environments, a single poisoned definition can propagate execution across all of them.

Business impact. Automation controllers frequently hold credentials to cloud providers, source control, and production infrastructure. Code execution within the execution environment can disrupt supply-chain pipelines, mutate deployment artifacts, and misuse any secrets reachable from that container — a high-integrity, supply-chain-relevant risk for enterprises running Ansible Automation Platform at scale.

Detection Guidance

Detection should focus on credential-type definitions containing dangerous loader variable names, and on processes whose startup behavior is consistent with BASH_ENV/ENV/PYTHONSTARTUP abuse inside execution containers.

Sigma Rule

title: Ansible Automation Controller Credential Type Injection of Loader Variables (CVE-2026-84706)
id: 8f3c1a92-8470-4c6e-9b2a-1d5e7f0a9b31
status: experimental
description: Detects creation or modification of custom Credential Type definitions injecting process-hijacking loader environment variables (BASH_ENV, ENV, LD_PRELOAD, LD_LIBRARY_PATH, PYTHONSTARTUP, GIT_SSH_COMMAND) in Ansible Automation Platform automation-controller. Relates to CVE-2026-84706.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-84706
author: valtersit.com
date: 2026/01/01
tags:
  - attack.t1055
  - attack.persistence
logsource:
  product: ansible
  service: automation-controller
detection:
  selection_env_vars:
    - 'BASH_ENV'
    - 'ENV'
    - 'LD_PRELOAD'
    - 'LD_LIBRARY_PATH'
    - 'PYTHONSTARTUP'
    - 'GIT_SSH_COMMAND'
  selection_event:
    event.action:
      - 'credential_type.create'
      - 'credential_type.update'
      - 'credential_type.modify'
  condition: selection_event and selection_env_vars
falsepositives:
  - Legitimate administrative configuration of advanced credential types by trusted automation engineers
level: high

YARA Rule

rule CVE_2026_84706_Ansible_Loader_Var_Injection
{
    meta:
        description = "Detects Ansible automation-controller credential type definitions injecting process-hijacking loader variables (CVE-2026-84706)"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-84706"
        date = "2026-01-01"
        severity = "high"

    strings:
        $v1 = "BASH_ENV" ascii wide nocase
        $v2 = "LD_PRELOAD" ascii wide nocase
        $v3 = "PYTHONSTARTUP" ascii wide nocase
        $v4 = "GIT_SSH_COMMAND" ascii wide nocase
        $v5 = "LD_LIBRARY_PATH" ascii wide nocase
        $ctx1 = "credential_type" ascii wide nocase
        $ctx2 = "env" ascii wide nocase

    condition:
        ($v1 or $v2 or $v3 or $v4 or $v5) and ($ctx1 or $ctx2)
}

Suricata IDS Rule

Detects credential-type API submissions containing loader variable names in outbound controller traffic (HTTP/HTTPS payload inspection).

alert http any any -> any any (msg:"CVE-2026-84706 Ansible Credential Type Loader Variable Injection Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"credential_type"; nocase; http.request_body; content:"BASH_ENV"; nocase; http.request_body; content:"LD_PRELOAD"; nocase; threshold:type limit, track by_src, count 5, seconds 60; classtype:attempted-admin; sid:202684706; rev:1;)

Elastic Detection

sequence by user.name
  [process where event.type == "start" and process.parent.name in ("awx", "ansible-runner", "podman", "docker")]
  [process where process.name in ("bash", "sh", "python", "python3") and
   process.env_vars : ("BASH_ENV*", "ENV*", "PYTHONSTARTUP*", "LD_PRELOAD*")]

Splunk SPL Query

index=ansible sourcetype=automation_controller
(event_action IN ("credential_type.create","credential_type.update","credential_type.modify"))
| eval injected=if(match(_raw,"(?i)(BASH_ENV|LD_PRELOAD|LD_LIBRARY_PATH|PYTHONSTARTUP|GIT_SSH_COMMAND|(^|[^A-Z_])ENV[^A-Z_])"),"suspicious","normal")
| where injected="suspicious"
| stats count min(_time) as first_seen max(_time) as last_seen by user, src_ip, credential_type_name
| where count >= 1
| sort - last_seen

Wazuh OSSEC Rule

<group name="ansible,automation_controller,">
  <rule id="2026847" level="12">
    <decoded_as>json</decoded_as>
    <field name="event.action">credential_type\.(create|update|modify)</field>
    <field name="credential_type.injectors">(BASH_ENV|LD_PRELOAD|LD_LIBRARY_PATH|PYTHONSTARTUP|GIT_SSH_COMMAND)</field>
    <description>CVE-2026-84706: Ansible credential type injects process-hijacking loader variable.</description>
    <mitre>
      <id>T1055</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch status: 0/4 (UNPATCHED). No patch evidence exists from any tracked source. No vendor fix, affected version range, or workaround is documented. Do not assume a fixed version is available.

1) Immediate mitigations.

• Restrict the ability to create or modify custom Credential Types to the smallest possible set of trusted administrators. Since exploitation requires elevated privileges (PR:H), reducing the number of accounts that can define credential types directly narrows the attack surface.
• Audit all existing custom Credential Types for injected environment variables matching BASH_ENV, ENV, LD_PRELOAD, LD_LIBRARY_PATH, PYTHONSTARTUP, and GIT_SSH_COMMAND. Remove any that are not strictly required.
• Review audit logs for recent credential_type.create, credential_type.update, and credential_type.modify events performed by accounts that should not hold that capability.
• Consider stronger isolation (dedicated execution nodes, restricted container networking) for jobs that attach custom Credential Types, to limit post-exploitation reach, given the S:C scope change.
• Because the flaw is a deny-list omission, there is no complete workaround that relies on the controller's own validation — treat custom Credential Types as a high-trust feature.

2) Patch/upgrade steps.

• Monitor the Red Hat / Ansible Automation Platform security advisories and the NVD entry for CVE-2026-84706 for a fixed release. No fixed version is currently available.
• When a patch is released, prioritize upgrade of the automation-controller component and verify that the deny-list has been replaced or extended to cover the omitted loader variables described in the advisory.

3) Long-term hardening.

• Where feasible, move custom Credential Type environment-variable validation from a deny-list to a strict allow-list (CWE-184 remediation) so that unknown or loader-related names are rejected by default.
• Implement change-control and peer review for any credential type that injects arbitrary environment variables.
• Enforce least-privilege role design in automation platforms so that credential-type administration is separated from job execution roles.
• Deploy the detection rules above to catch both credential-type poisoning and loader-variable abuse inside execution containers.

References

1. NVD — CVE-2026-84706: https://nvd.nist.gov/vuln/detail/CVE-2026-84706
2. Red Hat Product Security / Ansible Automation Platform advisories: https://access.redhat.com/security/
3. Ansible Automation Platform documentation — Credential Types and execution environments: https://docs.ansible.com/
4. CWE-184: Incomplete List of Disallowed Inputs: https://cwe.mitre.org/data/definitions/184.html
5. CISA Known Exploited Vulnerabilities catalog (CVE-2026-84706 not listed as of this report): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Campaign / exploitation evidence: None. No public PoC, exploit code, Nuclei template, or in-the-wild exploitation is known. CISA KEV status: NO. Exploitation requires a privileged authenticated user with credential-type administration rights.