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).