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.