REDHAT-BUG-2527198: High severity Red Hat Ansible Automation Controller vulnerability
A template-injection flaw was found in the automation-controller. The controller relies on a single helper, sanitizejinja(), to reject user-supplied Jinja in several fields that are later handed to ansible-core for templating: the module arguments of ad-hoc commands, the username and privilege-escalation fields of Machine credentials, and inventory host names. That helper detects Jinja with two regular expressions whose negated character classes stop at the first interior '}' or '%' character. As a result, a Jinja expression that contains an inner brace — for example "{{ {} or lookup('pipe','id') }}" — is not matched and is accepted, even though it is fully valid Jinja that ansible-core will evaluate at task time. A low-privileged user can therefore inject Jinja that runs inside the execution environment. Two consequences are significant. First, the bypass defeats an administrator who has restricted the allowed ad-hoc modules to non-executing ones (such as ping) to provide "safe" ad-hoc access: a lookup('pipe', ...) embedded in the ping module's arguments executes an arbitrary shell command in the execution environment and returns its output in the job results. Second, the bypass lets a user who administers Machine credentials, but who cannot read another credential (such as a cloud or vault credential), place a lookup('env', ...) expression in a credential field; when both credentials are used together on a job template, the co-attached credential's secret is injected into the execution environment's process environment, templated into the attacker-controlled field, and surfaced in the job output — disclosing the secret across the credential access-control boundary. The underlying weakness is that the guard is an incomplete pattern-based blocklist rather than a real Jinja lexer or an unambiguous rejection of any '{{' or '{%' sequence.
Affected Software
Event History
Frequently Asked Questions
Who can exploit this issue?
A low-privileged user who can supply values in affected controller fields can exploit it. The injected Jinja is evaluated by ansible-core at task time inside the execution environment.
Which controller inputs are affected?
The affected inputs are ad-hoc command module arguments, the username and privilege-escalation fields of Machine credentials, and inventory host names. These fields are passed through sanitize_jinja() before later templating by ansible-core.
Does limiting ad-hoc access to non-executing modules prevent exploitation?
No. An attacker can embed a lookup('pipe', ...) expression in the arguments of a module such as ping, causing an arbitrary shell command to run in the execution environment and returning its output in the job results.
What input pattern bypasses the Jinja filter?
Valid Jinja containing an inner brace or percent character can evade the regular-expression checks because their negated character classes stop at the first interior '}' or '%' character. The example provided is {{ {} or lookup('pipe','id') }}.