CVE-2026-82727: AshPhoenix Form.Auto leaks submitted params in an unknown _union_type error message
Generation of Error Message Containing Sensitive Information vulnerability in ash-project ashphoenix writes the entire raw submitted param map into an exception message, so secrets submitted alongside a union form field leak into logs, crash reports and the dev error page.
When AshPhoenix.Form.Auto builds a union sub-form and the submitted uniontype does not match a configured type, both raise sites built the message with inspect(params, pretty: true), embedding the full untrusted param map, and also inspected the internal union constraints[:types]. Because the message is constructed by the library rather than Phoenix's parameter logger, config :phoenix, :filterparameters never redacts it. An attacker controls both the trigger and the contents: submitting %{"uniontype" => "nope", "password" => "..."} puts the password verbatim in the raised message. The fix reports only the offending uniontype and the valid type names, dropping the param and constraints dumps.
This issue affects ashphoenix: from 1.2.17 before 2.3.25.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ash-project ash_phoenixto a version that resolves this vulnerability.Fixed in 2.3.25 - Configuration
Ensure sensitive submitted parameters are redacted in the union form error path; the vulnerability description states that because the error message is constructed by the library rather than Phoenix's parameter logger, config :phoenix, :filter_parameters never redacts it. Upgrade ash_phoenix from 1.2.17 before 2.3.25 to get the fixed behavior that drops the raw submitted param map from the raised message.
AshPhoenix Form.Auto phoenix :filter_parameters = (not applied)
Event History
Frequently Asked Questions
Who is exposed to this issue?
Applications using ash_phoenix versions from 1.2.17 before 2.3.25 are affected when they use AshPhoenix.Form.Auto to build a union sub-form. Exposure occurs if an attacker can submit parameters to that form and cause an invalid _union_type value.
What does an attacker need to do to trigger the leak?
The attacker submits a union-form request with an _union_type that does not match a configured type. They can include sensitive-looking values such as a password in the same submitted parameter map, which are then embedded in the exception message.
Does Phoenix parameter filtering prevent the sensitive values from being logged?
No. The vulnerable library constructs the exception message itself using the raw parameter map, so config :phoenix, :filter_parameters does not redact values included in that message.
Where might leaked values be exposed?
The raw submitted parameters can appear in application logs, crash reports, and the development error page. Review those locations for exception messages produced by invalid union type submissions.
What version resolves the issue?
Upgrade ash_phoenix to version 2.3.25 or later. The fix limits the error to the invalid _union_type value and valid type names rather than including the submitted parameter map or internal constraints.