Ansible Automation Platform EUVD-2026-85605

Exploitation requires an authenticated low-privileged account on the automation-controller (PR:L) with permission to set at least one of the vulnerable launch-time fields: ad-hoc command module_args, a Machine credential's username/become_method/become_user, or inventory host names. The payload must be a valid Jinja expression that contains an inner brace or percent (e.g. an empty dict) so that the two sanitize_jinja() regexes terminate at the first interior '}' or '%' and accept it. Secret disclosure across the credential boundary additionally requires a target credential to be co-attached to the same job so its injected environment variables can be templated. Limiting factors: the attacker must already have a controller account, and command execution occurs in the execution environment rather than on the control node; no user interaction and no non-default configuration is needed.

This is a genuine, exploitable input-validation flaw rather than a paper high-CVSS issue, but its priority is bounded by the required privilege level and the niche deployment footprint. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N, 7.1) is internally consistent with the description: a low-privileged but authenticated automation-controller user can remotely and reliably (AC:L, no user interaction) inject Jinja that ansible-core evaluates in the execution environment. The C:H rating is well justified because the flaw crosses the credential access-control boundary - an attacker can template a co-attached credential's injected environment variables to disclose secrets they cannot legitimately read. I would argue I:H is defensible rather than the vendor's I:L, since arbitrary command execution in the execution environment (bypassing the AD_HOC_COMMANDS allowlist) can modify managed systems; the vendor likely scoped I:L to the controller integrity specifically. No EPSS score, no CISA KEV listing, and no public POC are present in the provided data, so exploitation status is: no public exploit identified at time of analysis. The absence of KEV/EPSS combined with the PR:L requirement (attacker must already hold a low-privileged account on the controller) points to this being an insider/post-authentication escalation and lateral-secret-disclosure risk, not a mass-exploitable internet-facing bug. Note the input Tag 'Authentication Bypass' is misleading - this is an input-validation/authorization-boundary bypass (CWE-184), not an authentication bypass.

A low-privileged automation-controller user submits a launch-time field (e.g. ad-hoc command module_args, a Machine credential username/become_method/become_user, or an inventory host name) containing a Jinja expression with an inner brace such as an empty dict, which slips past sanitize_jinja()'s two regexes because they stop at the first interior '}' or '%'. ansible-core then evaluates the Jinja in the execution environment, letting the attacker run arbitrary commands (bypassing the administrator's AD_HOC_COMMANDS allowlist) and template a co-attached credential's injected environment variables to exfiltrate secrets they cannot otherwise read. No public POC is referenced in the provided data.