CVE-2026-82739 in Ash
Summary
by MITRE • 09/01/2026
Generation of Error Message Containing Sensitive Information vulnerability in ash-project ash discloses the stored value of a confirmed field to an actor who fails its confirmation check.
Ash.Resource.Validation.Confirm's atomic implementation (atomic/2 in lib/ash/resource/validation/confirm.ex) built the mismatch error with its value set to the field being confirmed. When the actor supplies only the confirmation argument and not the field itself, value resolves through atomic_ref/2 to the field's current stored value, so the mismatch error echoes that stored value back to the actor. Against a confirmation guarding a sensitive attribute, an actor can submit a deliberately wrong confirmation and read the real value from the returned error. The fix reports the actor-supplied confirmation in the error instead of the stored field value.
This issue affects ash: from 2.17.20 before 3.32.2.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified as a generation of an error message containing sensitive information represents a significant data exposure risk within the Ash framework, specifically affecting versions ranging from 2.17.20 up to but not including 3.32.2. This flaw originates in the atomic implementation of the confirmation validation logic located in the lib/ash/resource/validation/confirm.ex module. The core technical deficiency lies in how the system constructs error responses when a user-supplied value fails to match an existing stored field, particularly in scenarios where the actor provides only the confirmation argument without explicitly supplying the original field value during the request payload.
In normal operation, validation frameworks are designed to reject inputs that do not meet specified criteria while providing feedback that aids debugging or informs users of required changes. However, this implementation flaw causes the system to resolve the mismatch error by referencing atomic_ref/2, which retrieves and returns the actual stored database value for the field being confirmed rather than the user-supplied input. Consequently, when an actor submits a deliberately incorrect confirmation string against a sensitive attribute such as a password hash, personal identification number, or private key fragment, the resulting HTTP response or application error message inadvertently echoes back the true underlying value of that protected field. This behavior effectively transforms a standard validation failure into a mechanism for data exfiltration, allowing unauthorized actors to retrieve confidential information simply by observing server-side error outputs.
The operational impact of this vulnerability is severe because it bypasses traditional access controls and encryption protections surrounding sensitive fields. Even if the database column or API endpoint is restricted from direct read access, an attacker can exploit the validation layer's verbose error reporting to reconstruct secret values through iterative testing. This aligns with CWE-209, which classifies this as a generation of an error message that contains sensitive information, and falls under the broader category of CWE-200, where exposure of sensitive information to unauthorized actors occurs due to improper handling in error conditions. From a tactical perspective, this technique supports reconnaissance activities within the MITRE ATT&CK framework, specifically relating to techniques used for gathering victim identity or credentials through application-level feedback mechanisms rather than direct system exploitation.
To mitigate this vulnerability, organizations must upgrade their Ash dependencies to version 3.32.2 or later, where the fix ensures that error messages report the actor-supplied confirmation value instead of resolving back to the stored field value. This change prevents the leakage of internal state through validation errors. In environments where immediate upgrading is not feasible, defensive coding practices should be implemented at the application layer by intercepting these specific validation exceptions and replacing them with generic, non-descriptive error messages that confirm a mismatch occurred without revealing any underlying data values. Additionally, developers should audit other parts of their codebase for similar patterns where database queries or internal state references are directly interpolated into user-facing error responses to prevent analogous information disclosure vectors across the entire application stack.