CVE-2026-84709 automation-controller: automation-controller: CredentialType injector validation renders attacker-supplied Jinja2 templates synchronously in the web worker, allowing uncontrolled resource consumption (denial of service) and an unhandled ...
A flaw was found in Red Hat Ansible Automation Platform's automation-controller. When a
custom credential type is created or updated, the injector configuration is validated by
rendering each attacker-supplied Jinja2 template synchronously inside the web request
worker, with no limit on iteration count, output size, or execution time. An
authenticated superuser can submit a credential type whose injector contains deeply
nested loops or large string operations, consuming CPU and wall-clock time in the web
worker until it is killed by the request timeout; issuing enough concurrent requests
places all web workers into a kill-and-respawn loop, making the Controller API and UI
unavailable for the duration of the attack. Additionally, certain template constructs
raise exception types that the validator does not handle, resulting in an unhandled
server error (HTTP 500) instead of a clean validation error. The rendering sandbox
prevents code execution, so there is no confidentiality or integrity impact.
A flaw was found in automation-controller (AWX). POST/PATCH
/api/controller/v2/credential_types/ validates the injectors JSON by RENDERING every
string under injectors.{env,file,extra_vars} through a Jinja2 sandbox synchronously in
the uWSGI web request worker (awx/main/fields.py:748-785,
CredentialTypeInjectorField.validate -> validate_template_string:
sandbox.ImmutableSandboxedEnvironment(undefined=StrictUndefined).from_string(tmpl).render(...)
at line 750). The sandbox blocks server-side-template-injection code-execution gadgets
(__class__, __globals__, |attr('__...'), str.format dunder walk — all verified rejected
live and consistent with ImmutableSandboxedEnvironment), so this is not remote code
execution and has no confidentiality or integrity impact. However, nothing bounds total
iteration count, output size, or wall-clock time: nested {% for %} loops multiply
freely and string multiplication is unrestricted, so a single request can render
billions of iterations in-process. Live timing on the target scaled linearly (90,000
iterations 0.62s; 18,000,000 iterations 1.22s; 72,000,000 iterations 3.71s), proving
the render runs synchronously in automation-controller-web; a nested-loop request of
roughly 8.1e9 iterations exceeds the uWSGI harakiri timeout and kills the worker, and a
number of concurrent requests at or above the worker count drives every web worker into
a kill/respawn loop, taking the Controller API and UI (job launch, callbacks, inventory
sync, RBAC, UI) offline for as long as the attack is sustained. Separately, the
validation try/except catches only UndefinedError, SecurityError, and
TemplateSyntaxError (fields.py:751/757/759); a loader-less {% extends %} or {% include %}
raises TypeError('no loader for this environment specified'), and large string
operations raise OverflowError — neither is caught, so the exception propagates as a raw
Django 500 error page (verified live), a robustness defect and a second confirmation
that attacker templates execute in the web process. The endpoint is restricted to
superusers (awx/main/access.py:1078-1098 CredentialTypeAccess with no can_add override
-> BaseAccess.can_add returns user.is_superuser), so this is a defense-in-depth /
availability hardening issue rather than a privilege boundary break. There is no
wall-clock, iteration, or output bound anywhere around the render on the devel branch
(no MAX_RANGE or timeout present). This is the automation-controller sibling of the
already-reported EDA credential-types injector-validation denial of service and the
Controller notification_templates message-validation denial of service, in a distinct
code path (awx.main.fields.CredentialTypeInjectorField) reached from a distinct
endpoint. Discovered internally (pentest-aap); verified live on AAP 2.7 /
automation-controller 4.8.1; still present on devel (fix prepared, not merged).
Upstream: github.com/ansible/awx (awx/main/fields.py
CredentialTypeInjectorField.validate / validate_template_string).
This issue has been addressed in the following products:
Red Hat Ansible Automation Platform 2.6 for RHEL 10
Red Hat Ansible Automation Platform 2.6 for RHEL 9
Via RHSA-2026:71113 https://access.redhat.com/errata/RHSA-2026:71113
This issue has been addressed in the following products:
Red Hat Ansible Automation Platform 2.5 for RHEL 9
Red Hat Ansible Automation Platform 2.5 for RHEL 8
Via RHSA-2026:71114 https://access.redhat.com/errata/RHSA-2026:71114
A flaw was found in automation-controller (AWX). POST/PATCH /api/controller/v2/credential_types/ validates the injectors JSON by RENDERING every string under injectors.{env,file,extra_vars} through a Jinja2 sandbox synchronously in the uWSGI web request worker (awx/main/fields.py:748-785, CredentialTypeInjectorField.validate -> validate_template_string: sandbox.ImmutableSandboxedEnvironment(undefined=StrictUndefined).from_string(tmpl).render(...) at line 750). The sandbox blocks server-side-template-injection code-execution gadgets (__class__, __globals__, |attr('__...'), str.format dunder walk — all verified rejected live and consistent with ImmutableSandboxedEnvironment), so this is not remote code execution and has no confidentiality or integrity impact. However, nothing bounds total iteration count, output size, or wall-clock time: nested {% for %} loops multiply freely and string multiplication is unrestricted, so a single request can render billions of iterations in-process. Live timing on the target scaled linearly (90,000 iterations 0.62s; 18,000,000 iterations 1.22s; 72,000,000 iterations 3.71s), proving the render runs synchronously in automation-controller-web; a nested-loop request of roughly 8.1e9 iterations exceeds the uWSGI harakiri timeout and kills the worker, and a number of concurrent requests at or above the worker count drives every web worker into a kill/respawn loop, taking the Controller API and UI (job launch, callbacks, inventory sync, RBAC, UI) offline for as long as the attack is sustained. Separately, the validation try/except catches only UndefinedError, SecurityError, and TemplateSyntaxError (fields.py:751/757/759); a loader-less {% extends %} or {% include %} raises TypeError('no loader for this environment specified'), and large string operations raise OverflowError — neither is caught, so the exception propagates as a raw Django 500 error page (verified live), a robustness defect and a second confirmation that attacker templates execute in the web process. The endpoint is restricted to superusers (awx/main/access.py:1078-1098 CredentialTypeAccess with no can_add override -> BaseAccess.can_add returns user.is_superuser), so this is a defense-in-depth / availability hardening issue rather than a privilege boundary break. There is no wall-clock, iteration, or output bound anywhere around the render on the devel branch (no MAX_RANGE or timeout present). This is the automation-controller sibling of the already-reported EDA credential-types injector-validation denial of service and the Controller notification_templates message-validation denial of service, in a distinct code path (awx.main.fields.CredentialTypeInjectorField) reached from a distinct endpoint. Discovered internally (pentest-aap); verified live on AAP 2.7 / automation-controller 4.8.1; still present on devel (fix prepared, not merged). Upstream: github.com/ansible/awx (awx/main/fields.py CredentialTypeInjectorField.validate / validate_template_string).