A flaw was found in Red Hat Ansible Automation Platform's automation-
controller. Survey questions of type password are write-only and stored
encrypted, displayed only as a placeholder on read. When a schedule or
workflow job template node is revalidated against a tightened survey
specification, the controller decrypts the stored password and includes its
plaintext value in the minimum/maximum length validation error message
returned in the HTTP response. A user with the delegated JobTemplate Admin
role can tighten the survey length constraint and trigger revalidation of a
schedule or node created by another, higher-privileged user, thereby
recovering that user's stored password in plaintext.
A flaw was found in automation-controller (AWX). Write-only survey password
values stored on Schedules and WorkflowJobTemplateNodes are encrypted at rest
and masked as `$encrypted$` on read. LaunchConfigurationBaseSerializer.validate
(awx/api/serializers.py) replaces an incoming `$encrypted$` with the stored DB
ciphertext and revalidates prompts against the job template's current
survey_spec; SurveyJobTemplateMixin._accept_or_ignore_variables
(awx/main/models/mixins.py) decrypts the stored password before validation, and
_survey_element_validation interpolates the decrypted plaintext into the
"value ... is too small/too large" min/max error for text/textarea/password
questions. The error dict is returned verbatim as the HTTP 400 body. A user
holding only the delegated JobTemplate Admin role can POST a tightened
survey_spec (e.g. "max":1) and then PATCH a schedule of that job template --
either echoing `$encrypted$` for the variable, or simply re-stating
unified_job_template to force full-prompt revalidation without knowing the
variable name (serializers.py forces full revalidation when unified_job_template
is present) -- and read the stored plaintext password of a schedule created by
a different, higher-privileged user (ScheduleAccess.can_change grants a JT
admin write on all schedules of the template regardless of creator). The same
base serializer backs WorkflowJobTemplateNodeSerializer, so workflow nodes are
equally affected. Discovered internally; verified live on AAP 2.7 /
automation-controller 4.8.1; still present on devel.
Upstream: github.com/ansible/awx (api/serializers.py
LaunchConfigurationBaseSerializer; main/models/mixins.py
_survey_element_validation / _accept_or_ignore_variables;
main/access.py ScheduleAccess.can_change)
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). Write-only survey password values stored on Schedules and WorkflowJobTemplateNodes are encrypted at rest and masked as `$encrypted$` on read. LaunchConfigurationBaseSerializer.validate (awx/api/serializers.py) replaces an incoming `$encrypted$` with the stored DB ciphertext and revalidates prompts against the job template's current survey_spec; SurveyJobTemplateMixin._accept_or_ignore_variables (awx/main/models/mixins.py) decrypts the stored password before validation, and _survey_element_validation interpolates the decrypted plaintext into the "value ... is too small/too large" min/max error for text/textarea/password questions. The error dict is returned verbatim as the HTTP 400 body. A user holding only the delegated JobTemplate Admin role can POST a tightened survey_spec (e.g. "max":1) and then PATCH a schedule of that job template -- either echoing `$encrypted$` for the variable, or simply re-stating unified_job_template to force full-prompt revalidation without knowing the variable name (serializers.py forces full revalidation when unified_job_template is present) -- and read the stored plaintext password of a schedule created by a different, higher-privileged user (ScheduleAccess.can_change grants a JT admin write on all schedules of the template regardless of creator). The same base serializer backs WorkflowJobTemplateNodeSerializer, so workflow nodes are equally affected. Discovered internally; verified live on AAP 2.7 / automation-controller 4.8.1; still present on devel. Upstream: github.com/ansible/awx (api/serializers.py LaunchConfigurationBaseSerializer; main/models/mixins.py _survey_element_validation / _accept_or_ignore_variables; main/access.py ScheduleAccess.can_change)