EUVD-2026-68334Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify union-type form endpoint in target app
-
DeliverySubmit POST with invalid _union_type and sensitive field values
-
ExploitServer raises RuntimeError embedding full params map
-
ExecutionPlaintext secrets appear in application logs or crash reporter
-
ImpactAttacker or privileged insider reads leaked credentials from log storage
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A10:2025 - Mishandling of Exceptional Conditions
ASVS 5.0
V16 - Security Logging and Error Handling Error message sanitization
MITRE ATT&CK
1 technique across 1 tactic: Discovery The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | The application must use AshPhoenix.Form.Auto with at least one Ash resource attribute of union type and forms configured with auto?: true; applications that do not use union-type form fields are entirely unaffected. The attacker must be able to submit a POST request to the relevant form endpoint, which typically requires an authenticated session (PR:L). The server must propagate exception messages to a persistent or observable store-application logger, crash reporter, or dev error page-which is the Phoenix default; deployments that suppress all exception output would not expose the leaked values. Exploitation is bounded to reading whatever values were co-submitted in the params map at error time; it does not grant arbitrary server-side read access or affect other users' sessions. The leak is not conditional on any non-default Phoenix or Ash configuration beyond the presence of a union-type field. |
| Impact | The CVSS 4.0 score of 2.3 (AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N) accurately reflects real-world risk: confidentiality impact is Low because exposure is indirect-values land in logs and crash reporters rather than being returned directly to the attacker-and AT:P captures that the application must be using union-type form fields for the vulnerable code path to be reachable. PR:L reflects that form submission typically requires an authenticated session in Ash Phoenix applications. No EPSS score was provided in the source data, and the vulnerability is not listed in CISA KEV; no public exploit code has been identified at time of analysis. Despite the low score, operational risk is meaningful for any application that co-submits credentials or tokens in the same form as a union field, because those values bypass Phoenix's built-in log filtering. Organizations using centralized log aggregation or third-party crash reporting-where plaintext secrets could persist across retention periods-should treat this as a higher operational priority than the raw CVSS implies. The CVSS Integrity and Availability scores of N are consistent with the description: there is no write primitive and no availability degradation. |
| Exploit ScenarioDerived | An authenticated user submits a Phoenix form that includes a union-type field (e.g., a polymorphic content attribute) alongside a password or API token field; by crafting the POST body with _union_type set to any invalid string such as 'nope', the user causes AshPhoenix.Form.Auto to raise a RuntimeError whose message contains the full params map in pretty-printed Elixir syntax, including the password verbatim. The exception propagates to the application logger and any configured crash reporter, where operations staff or an attacker with log-read access can retrieve it. No public proof-of-concept code exists, but the commit diff includes a regression test that demonstrates the exact trigger. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAI
Sensitive form parameters leak into server logs, crash reports, and the Phoenix development error page in ash_phoenix versions 1.2.17 through 2.3.24, where AshPhoenix.Form.Auto embeds the complete raw submitted param map verbatim into exception messages when a union sub-form receives an unrecognized _union_type value. Because the exception is raised inside library code rather than Phoenix's controller layer, the standard :filter_parameters configuration cannot redact the exposure-any field co-submitted with the union form field, including passwords and tokens, appears in plaintext in the raised message. No public exploit has been identified at time of analysis, but any user capable of submitting a form with a union field can deliberately trigger the leak regardless of intent.
RemediationAI
The primary fix is to upgrade ash_phoenix to version 2.3.25 or later, which removes user-controlled content from exception messages entirely (patch commit 0c1775c3cf8988f9abd10a8f92315afc5f06f16d; vendor advisory at https://github.com/ash-project/ash_phoenix/security/advisories/GHSA-5xf4-hgcq-xw7v). If an immediate upgrade is not possible, configure crash and error reporting tools-Sentry, AppSignal, Honeybadger, or equivalent-with custom data scrubbing rules targeting known sensitive parameter names in exception messages; most APM tools expose this capability per-integration. Note explicitly that Phoenix's built-in :filter_parameters configuration does not apply to this code path and cannot serve as a compensating control. A secondary mitigation is to restrict log access permissions to reduce the audience that could read leaked values, though this does not prevent the leak itself. Deployments that do not use union-type fields in any Ash form are not affected by this specific code path and need not treat this as urgent.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Ash Phoenix is an Elixir library (Hex package ash_phoenix, ash-project organization) that integrates the Ash Framework's data layer with Phoenix LiveView form handling. The vulnerable component is AshPhoenix.Form.Auto, which auto-generates sub-form structures for Ash union-type resource attributes. Two raise sites in the private determine_type/3 function (lib/ash_phoenix/form/auto.ex, approximately lines 254 and 309) constructed RuntimeError messages using Elixir's inspect(params, pretty: true), which recursively pretty-prints any Elixir term including nested maps of arbitrary user-supplied values. The same sites also called inspect(constraints[:types], pretty: true), leaking the internal union constraint configuration. The root cause is CWE-209 (Generation of Error Message Containing Sensitive Information): the library routed unfiltered user input directly into exception messages, which propagate to the Logger backend, crash aggregation services (Sentry, AppSignal), and the Phoenix development error overlay. Phoenix's :filter_parameters operates at the Plug/controller layer and has no visibility into exceptions raised deeper in library code, making it an ineffective compensating control. The patch (commit 0c1775c3cf8988f9abd10a8f92315afc5f06f16d) removes both dumps and introduces a union_type_names/1 helper that emits only the atom names of valid types, entirely eliminating user-controlled content from the message.
Know when Ash Phoenix gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Network form submission by a low-privilege authenticated user; confidentiality impact is Low because secrets land in logs rather than being exfiltrated directly to the attacker.
Primary rating from Vendor (EEF).
CVSS VectorVendor: EEF
DescriptionCVE.org
Generation of Error Message Containing Sensitive Information vulnerability in ash-project ash_phoenix 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 _union_type 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, :filter_parameters never redacts it. An attacker controls both the trigger and the contents: submitting %{"_union_type" => "nope", "password" => "..."} puts the password verbatim in the raised message. The fix reports only the offending _union_type and the valid type names, dropping the param and constraints dumps.
This issue affects ash_phoenix: from 1.2.17 before 2.3.25.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
GitHub
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
More in Ash Phoenix
View allTenant authorization bypass in ash_phoenix's SubdomainHook allows an authenticated user to cross tenant boundaries and a
Tenant hijacking and request degradation in AshPhoenix (ash_phoenix 2.1.26 through 2.3.24) allows unauthenticated remote
FilterForm in ash_phoenix (versions 0.6.0-rc.1 through 2.3.24) exposes private relationship data to authenticated users
Exploit-DB