Automation-controller: automation-controller: incomplete sanitize_jinja() regex allows jinja template injection into ad-hoc module_args, machine-credential fields, and host names, reaching ansible-core templating in the execution environment
Published Sep 23, 2026 · Updated Nov 3, 2026
Original summary
Normalized public record · Updated Nov 3, 2026
Automation-controller: automation-controller: incomplete sanitize_jinja() regex allows jinja template injection into ad-hoc module_args, machine-credential fields, and host names, reaching ansible-core templating in the execution environment
Publisher and source text is retained separately from QFinch interpretation.
QFinch assessment
A flaw was found in the automation-controller input-validation guard sanitize_jinja(). The function uses two regular expressions to reject user-supplied Jinja, but the patterns stop at the first interior '}' or '%' character, so a Jinja expression containing an inner brace (for example an empty dict) is accepted while remaining valid Jinja. Because sanitize_jinja() is the sole guard on several launch-time fields — ad-hoc command module_args, Machine-credential username / become_method / become_user, and inventory host names — a low-privileged user can inject Jinja that ansible-core evaluates in the execution environment. This enables execution of arbitrary commands in the execution environment (bypassing an administrator's AD_HOC_COMMANDS module allowlist) and disclosure of secrets belonging to credentials the attacker cannot read (by templating a co-attached credential's injected environment variables), across the credential access-control boundary.
Evidence: public source recordsAffected products
| Affected package, product or range | Fix status |
|---|---|
| Consult the referenced vendor advisory for affected versions. | Consult source advisory |
Matching a version is only one part of assessing exposure. QFinch has not assessed your environment on this public page.
Remediation
Apply the vendor-supported fixed release or mitigation, then verify the affected component is no longer reachable.
- Confirm the affected product and reachable code path exist in your environment.
- Apply the vendor-supported patch or mitigation from the primary advisory.
- Rescan the exact deployed revision and retain verification evidence.
Evidence coverage
- SSVC priority
- MEDIUM
- Confidence
- Not available
- Aliases
- None reported
Scores appear only when corresponding evidence exists. Missing data is never interpreted as zero risk.
Sources and record history
- RHSA-2026:71113 ↗
- RHSA-2026:71114 ↗
- RHSA-2026:71177 ↗
- RHSA-2026:71179 ↗
- access.redhat.com ↗
- RHBZ#2527198 ↗
Record history
Published Sep 23, 2026 · Last refreshed Nov 3, 2026