Ash Framework CVE-2026-82739

All three of the following conditions must be present simultaneously: (1) the Ash action must be configured with require_atomic? true, forcing the atomic/2 code path in Ash.Resource.Validation.Confirm rather than the non-atomic fallback; (2) the action is defined such that the actor can submit the confirmation argument (confirm_secret) without also supplying the original confirmed field (:secret), causing atomic_ref/2 to fall back to the stored database value; and (3) the confirmed attribute holds genuinely sensitive data such as a password, API key, or secret token - disclosure of non-sensitive fields is not a security event. Exploitation yields read-only disclosure of a single field value per request; there is no integrity or availability impact. Authentication requirements are entirely determined by how the consuming Phoenix or API layer exposes the action - the Ash framework itself imposes no authentication on this path (PR:N in the vendor CVSS vector), so an unauthenticated actor can exploit this if the endpoint is publicly reachable.

The CVSS 4.0 base score of 2.1 (AV:L/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N) is consistent with the narrow, condition-dependent nature of the flaw. The AT:P (Attack Conditions: Present) metric correctly encodes that three simultaneous conditions are required before exploitation is possible. The vendor's AV:L rating, however, is potentially understated for production deployments: Ash actions are most commonly exposed over Phoenix HTTP APIs, making AV:N a more realistic representation for many environments - this discrepancy should be verified against the specific application's deployment model. EPSS data is unavailable but is expected to be negligible given the low base score, niche Elixir-ecosystem footprint, and absence of a KEV listing. No independently published POC exists; the fix commit's regression test (test/actions/validation_test.exs) functions as a minimal, readable proof-of-concept. Real-world risk is meaningful only in applications that combine atomic confirm validation on a genuinely sensitive attribute with an action interface that accepts the confirmation argument without requiring the original field value as input.

An attacker with access to an Ash update action that uses require_atomic? true and validates via confirm(:secret, :confirm_secret) sends the action with only confirm_secret set to a known-wrong string, omitting the :secret field itself. The atomic validator resolves the mismatch error's value to the current stored database value of :secret and returns it in the Ash.Error.Changes.InvalidChanges error payload. The attacker reads the real secret from the returned error in a single unauthenticated (or minimally authenticated, depending on application policy) request.