CVE-2026-81322
Summary
by MITRE • 08/30/2026
Exposure of Sensitive Information to an Unauthorized Actor vulnerability in ash-project ash_cloak allows anyone with access to logs, error trackers, or crash reports, or anyone who can trigger a validation error, to recover the plaintext of a field the library encrypts.
AshCloak.Transformers.SetUpEncryption removes each cloaked attribute from the action's accept list and adds an action argument that carries the plaintext into the encryption change. That argument is built with sensitive?: attr.sensitive?, inheriting the flag from the source attribute, so a cloaked attribute declared without sensitive? true produces a non-sensitive argument. It is the only place the cleartext value lives, and the one place Ash will not redact: it appears verbatim in inspect(changeset), Ash.Error.Invalid and validation error messages, telemetry, :sys dumps, and error-tracker payloads. The generated encrypted attribute and decrypt calculation are already hardcoded sensitive.
This issue affects ash_cloak: from 0.1.0 before 0.4.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/30/2026
The vulnerability identified in the AshCloak library prior to version 0.4.0 represents a critical failure in data protection mechanisms, specifically categorized under CWE-209 as an Exposure of Sensitive Information through an Error Message and CWE-359 regarding exposure of private information within logs or telemetry. This flaw allows any actor with access to application logs, error tracking services, crash reports, or the ability to trigger validation errors on affected records to recover plaintext values that were intended to be encrypted. The root cause lies in the implementation details of the AshCloak.Transformers.SetUpEncryption module, which manages how attributes are processed during data insertion and updates within the Ash framework.
During the setup process for encryption, the library removes each cloaked attribute from the standard action accept list to prevent direct assignment of plaintext values by external callers. Instead, it introduces a specific action argument designed to carry the raw plaintext value into an internal encryption change function. This design choice is intended to isolate sensitive data handling within the application layer. However, the logic determining whether this temporary argument should be treated as sensitive relies on inheriting the sensitive flag from the source attribute definition. If a developer declares a cloaked attribute without explicitly setting the sensitive? option to true, the resulting internal argument is not marked as sensitive by the framework's redaction mechanisms.
This oversight creates a significant security gap because this specific temporary argument serves as the sole location where the cleartext value exists during the processing pipeline. Since it lacks the sensitive flag, Ash does not apply its standard data masking or redaction protocols to this field. Consequently, when validation errors occur, or when changesets are inspected for debugging purposes, the plaintext value is exposed verbatim in multiple high-risk output channels. These include inspect(changeset) outputs, Ash.Error.Invalid exception messages, telemetry events sent to monitoring systems, Erlang :sys dumps used for system state inspection, and payloads transmitted to external error-tracking services like Sentry or Bugsnag.
The operational impact of this vulnerability is severe, as it effectively nullifies the confidentiality guarantees provided by encryption at rest if an attacker can influence validation flows or access server-side logs. An adversary with read access to application logs or the ability to send malformed requests that trigger validation failures can extract sensitive personal data, credentials, or other protected information in plaintext. This exposure persists regardless of whether the final stored value is encrypted, as the leakage occurs during the transient processing phase before encryption takes effect. The issue affects all versions of ash_cloak from 0.1.0 up to but not including version 0.4.0, where this logic was corrected to ensure that internal arguments carrying plaintext are always treated as sensitive and redacted appropriately in logs and error reports.
To mitigate this vulnerability, organizations must upgrade the ash_cloak dependency to version 0.4.0 or later, which addresses the flag inheritance issue by ensuring that all internal arguments containing cleartext data are marked as sensitive regardless of the source attribute's configuration. For systems unable to immediately upgrade, a temporary workaround involves explicitly setting the sensitive? option to true for every cloaked attribute definition in the codebase. This forces the framework to treat the generated argument as sensitive, thereby triggering redaction mechanisms that mask the plaintext value in logs and error messages. Additionally, security teams should audit existing log configurations and telemetry pipelines to ensure no other custom logging practices inadvertently expose internal changeset data or intermediate processing states. Regular review of application code for proper use of sensitivity flags is essential to maintain compliance with data protection standards such as GDPR and HIPAA, which mandate strict controls over the storage and transmission of sensitive personal information.