A template-injection flaw was found in the automation-controller. The
  controller relies on a single helper, sanitize_jinja(), 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.