CVE-2026-81322: Cloaked plaintext leaks through a non-sensitive action argument in AshCloak
Exposure of Sensitive Information to an Unauthorized Actor vulnerability in ash-project ashcloak 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 ashcloak: from 0.1.0 before 0.4.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ash-project ash_cloakto a version that resolves this vulnerability.Fixed in 0.4.0 - Configuration
Ensure the cloaked attribute is declared with sensitive? = true so the generated action argument carrying the plaintext is marked sensitive and not exposed via inspect(changeset), Ash.Error.Invalid / validation errors, telemetry, :sys dumps, or error-tracker payloads.
AshCloak sensitive? (for cloaked attributes) = true
Event History
Frequently Asked Questions
Which deployments are exposed to plaintext leakage?
ash_cloak versions from 0.1.0 before 0.4.0 are affected when a cloaked attribute is declared without sensitive? true. The generated action argument then remains non-sensitive even though the encrypted attribute and decrypt calculation are marked sensitive.
What does an attacker or unauthorized party need to recover the plaintext?
They need access to logs, error trackers, crash reports, telemetry, or :sys dumps containing the affected data. A party that can trigger a validation error may also cause the plaintext to appear in validation error messages.
Where can I look for evidence that plaintext has already been exposed?
Review inspect(changeset) output, Ash.Error.Invalid and validation error messages, telemetry, :sys dumps, and error-tracker payloads for values from cloaked attributes that were not configured with sensitive? true. These locations can contain the cleartext action argument verbatim.
What mitigation is available before upgrading?
Declare each cloaked source attribute with sensitive? true so that the generated plaintext-carrying action argument is also treated as sensitive and redacted.