Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as privileged controller user
-
DeliveryDefine custom Credential Type with malicious env/file injectors
-
ExploitDeny-list fails to block BASH_ENV/LD_PRELOAD
-
ExecutionWrite attacker script into execution environment
-
PersistJob attaches credential and loader var fires
-
ImpactArbitrary code execution in EE container
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V2 - Validation and Business Logic Input validation completeness
|
| Exploitation Conditions | Requires an authenticated privileged user (PR:H) who can create or edit a custom Credential Type in automation-controller, using both its environment-variable injector and its file injector. The specific weakness is that name validation (ANSIBLE_* prefix check plus a fixed ENV_BLOCKLIST) omits process-hijacking loader variables - BASH_ENV, ENV, LD_PRELOAD, LD_LIBRARY_PATH, PYTHONSTARTUP, GIT_SSH_COMMAND - so those pass the deny-list. Exploitation is further gated on a subsequent job actually attaching a credential of that malicious type, at which point the injected loader variable executes the planted script inside the execution-environment container. Limiting factors: high privilege needed to define credential types, and the code runs only when a job consumes the credential. |
| Impact | This is a genuine remote-code-execution flaw whose real-world priority is bounded by a high privilege requirement, not by the code path. The CVSS 3.1 vector (AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:H/A:N, 7.6) is internally consistent with the description: PR:H reflects that creating or modifying a custom Credential Type in AWX/automation-controller is a superuser/platform-admin operation, and S:C reflects the escape from the control-plane authorization boundary into the execution-environment container. The I:H (arbitrary code execution) is well justified; the vendor's choice of C:L/A:N is defensible but conservative, since code execution in the EE container plausibly exposes any credential attached to affected jobs. No EPSS score, no CISA KEV entry, and no public proof-of-concept were supplied, so this is not evidence of widespread or active exploitation - the signals point to a real-but-gated privilege-to-RCE escalation rather than a mass-exploitable internet-facing bug. The dominant limiting factor is PR:H: the attacker must already hold high privileges to define the credential type, which for many operators reduces this to an insider/lateral-movement and containment-boundary concern rather than an external attack surface. No conflicting signals between the vector and the description were found; the only notable data gaps are the absent fix version, EPSS, and POC status. |
| Exploit ScenarioDerived | A privileged automation-controller user who can define a custom Credential Type crafts an env-var injector that sets BASH_ENV (or ENV/LD_PRELOAD/PYTHONSTARTUP/GIT_SSH_COMMAND) - names the deny-list fails to block - and uses the credential file injector to drop an attacker-controlled script into the execution environment. When any job attaches a credential of that type, the loader variable causes the script to run, yielding arbitrary code execution inside the execution-environment container. No public exploit identified at time of analysis; exploitation requires authenticated high-privilege access per the CVSS PR:H metric. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 23, 2026
Remote code execution in Red Hat Ansible Automation Platform 2's automation-controller is possible when a privileged, authenticated user (CVSS PR:H) defines a custom Credential Type and abuses its environment-variable injector to set a process-hijacking loader variable such as BASH_ENV, ENV, LD_PRELOAD, LD_LIBRARY_PATH, PYTHONSTARTUP, or GIT_SSH_COMMAND, which the existing ANSIBLE_* prefix check and fixed ENV_BLOCKLIST fail to catch. Paired with the credential file injector, the attacker plants a script in the execution environment and points the loader variable at it, so arbitrary code executes inside the execution-environment container for any job that later attaches a credential of that type; this requires both the high privilege to author the credential type and a subsequent job consuming it. Red Hat's published CVSS of 7.6 (C:L/I:H/A:N) is lower than our independent assessment of the full vector (C:H/I:H/A:H), and because the vulnerable controller and the impacted execution-environment container are different security scopes, S:C applies. There is no CISA KEV listing and no public exploit identified at time of analysis.
RemediationAI
No vendor-released patch is identified in the available data; the appropriate fix is a server-side extension of the injector validation to reject loader variables (BASH_ENV, ENV, LD_PRELOAD, LD_LIBRARY_PATH, PYTHONSTARTUP, GIT_SSH_COMMAND) or, preferably, adoption of an allow-list of permitted environment-variable names, so remediation is largely vendor-dependent. Until a patched automation-controller release is confirmed via https://access.redhat.com/security/cve/CVE-2026-84706 and https://bugzilla.redhat.com/show_bug.cgi?id=2527187, apply compensating controls: tighten RBAC so that the ability to create or edit Credential Types is limited to a small, trusted administrator group (trade-off: custom credential workflows must be funneled through those administrators), and audit all existing custom Credential Types for environment variables matching loader-variable names or otherwise referencing the file injector, removing or rewriting any that are found. Where custom credential types are not essential, remove that permission entirely or restrict custom types to predefined ones (trade-off: breaks legitimate integrations relying on bespoke credential injection). Harden the execution-environment containers by mounting the root filesystem read-only, disallowing arbitrary file writes outside declared volumes, applying strict seccomp/SELinux confinement, and disabling unnecessary interpreters or git/SSH helpers so that an injected loader variable has nothing useful to load (trade-off: some collection or module functionality may fail, and additional testing is required per execution environment). Also monitor job templates for newly attached custom credentials and alert on credential-type creation or modification events, since that activity is the exploitation prerequisite.
Affected VersionsENISA
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause is CWE-184 (Incomplete List of Disallowed Inputs) in automation-controller's custom Credential Type injectors. The environment-variable injector sanitizes variable names with a partial deny-list - a check that rejects names beginning with ANSIBLE_ plus a fixed ENV_BLOCKLIST - rather than an allow-list or a complete set of dangerous loader variables. As a result, interpreter and dynamic-linker hijack variables (BASH_ENV, ENV, LD_PRELOAD, LD_LIBRARY_PATH, PYTHONSTARTUP, GIT_SSH_COMMAND) pass validation. In combination with the file injector, which can place attacker-controlled content into the execution environment, a privileged user can point one of these variables at the planted file so that it is sourced or loaded when a job runs, yielding code execution within the execution-environment container. The scope change (S:C) reflects that compromise of the controller-side credential definition crosses into the separate containerized execution environment where jobs run. Because the flaw is a validation gap in a configuration-driven injector, exploitation does not require a memory-safety primitive; it requires the ability to create or edit a custom Credential Type and a job that attaches that credential type. CPE data identifies Red Hat Ansible Automation Platform 2 as the affected product family.
Know when Django gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:H/A:N
PR:H because defining a custom Credential Type is superuser-gated; S:C for control-plane to EE-container escape; C/I/A:H because arbitrary code execution in the EE compromises attached credentials and job integrity/availability.
Primary rating from Vendor (redhat).
CVSS VectorVendor: redhat
DescriptionCVE.org
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.
Executive ViewAI
A remote code execution flaw in the automation-controller component of Red Hat Ansible Automation Platform 2 lets a user who already holds elevated platform privileges author a custom Credential Type that plants code executing inside execution-environment containers whenever another job consumes that credential. With no vendor patch currently available, the practical exposure is an insider or a compromised administrator account converting the automation platform - which typically holds credentials and network reach into production systems - into an internal code-execution and lateral-movement foothold. The vulnerability is confirmed by the vendor at CVSS 7.6, though independent assessment of the full vector scores higher, so security leadership should treat this as an unpatched privileged-abuse risk to the automation control plane rather than a routine bug fix.
No vendor-released patch identified at time of analysis; interim mitigations are to restrict custom Credential Type authoring to a minimal set of highly trusted administrators with mandatory review, audit and remove any existing credential type injecting loader variables such as BASH_ENV, ENV, LD_PRELOAD, LD_LIBRARY_PATH, PYTHONSTARTUP, or GIT_SSH_COMMAND, enforce an environment-variable allowlist within execution-environment images so those variables cannot be set by credential definitions, rebuild execution environments with read-only or immutable script paths, segment execution-environment containers from production networks to limit lateral movement, and monitor credential-type creation and the job runs that consume them. Apply vendor patch when released.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Remote Code Execution represents the critical moment when an attacker successfully runs arbitrary code on a target system without physical access.
The package python/cpython from 0 and before 3.6.13, from 3.7.0 and before 3.7.10, from 3.8.0 and before 3.8.8, from 3.9
In Django 1.10.x before 1.10.8 and 1.11.x before 1.11.5, HTML autoescaping was disabled in a portion of the template for
An issue was discovered in Django 3.2 before 3.2.14 and 4.0 before 4.0.6. Rated critical severity (CVSS 9.8), this vulne
Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input
Django before 1.11.27, 2.x before 2.2.9, and 3.x before 3.0.1 allows account takeover. Rated critical severity (CVSS 9.8
An authentication/authorization bypass in the djust Python live-view framework (versions prior to 1.0.7) lets unauthenti
Unauthenticated arbitrary Python module import in djust before 1.0.7 lets any client that can reach the WebSocket or SSE
Django 1.11 before 1.11.29, 2.2 before 2.2.11, and 3.0 before 3.0.4 allows SQL Injection if untrusted data is used as a
Cross-site scripting (XSS) vulnerability in the dismissChangeRelatedObjectPopup function in contrib/admin/static/admin/j
Forged content modification in django-page-cms through 2.0.13 lets unauthenticated remote attackers exploit five CSRF-ex
Cross-site request forgery in djust's Server-Sent-Events transport affects all versions prior to 1.0.7 and allows a cros
Unauthenticated remote attackers can read live Django view and session state and invoke server-side handlers through dju
EUVD-2026-85638
GHSA-5vrq-6q93-m3rf
NVD
CVE.org
EPSS
Exploit-DB