CVE-2026-81322: ash-project/ash_cloak encrypted field

CISO Take

ash_cloak, a field-level encryption library for the Elixir Ash Framework, has a design flaw where the plaintext value it is supposed to encrypt gets copied into an internal action argument that inherits the source attribute's sensitive flag — so if a developer didn't explicitly mark that attribute sensitive?: true, the cleartext is never redacted. That plaintext then surfaces verbatim in changeset inspection output, validation error messages, telemetry events, :sys dumps, and any error-tracker payload (Sentry, AppSignal, etc.), meaning anyone with routine access to logs or crash reporting — or anyone who can simply trigger a validation error on that field — can recover data the application believed was encrypted at rest. There is no CVSS score, no EPSS data, no public exploit, and it is not in CISA KEV, and exploitation requires either insider/observability access or the ability to induce an error, so this is a low-urgency, high-relevance-to-scope issue rather than an actively exploited one. The blast radius is any application using ash_cloak to encrypt attributes without setting sensitive? true on the source attribute. Action: upgrade to ash_cloak >= 0.4.0, audit all cloaked attributes to confirm sensitive?: true is set on the source attribute as defense in depth, and scrub historical logs/error-tracker payloads/telemetry stores for any plaintext that may have already leaked from affected fields.

Sources:NVDGitHub Advisoryash-project/ash_cloak

What is the risk?

Low overall risk given the absence of a CVSS score, EPSS data, KEV listing, or public exploit/scanner coverage — this is a logic/redaction bug (CWE-200), not a remotely exploitable vulnerability with direct network attack surface. However, the practical exploitability floor is low: anyone with legitimate or illegitimate access to application logs, error-tracking dashboards, telemetry pipelines, or crash dumps gets the plaintext for free, and an external party can potentially trigger a validation error on a cloaked field to force the leak without any special privileges. The severity of the outcome scales with what is being cloaked — if the encrypted attribute holds PII, credentials, health data, or other regulated data, a routine operational access path (a support engineer viewing Sentry, a log aggregation tool, an APM vendor) becomes an unintended disclosure channel, defeating the entire purpose of using encryption-at-rest for that field.

How does the attack unfold?

Access or trigger

An actor either has routine access to logs/error trackers/telemetry, or sends input that triggers a validation error on a cloaked attribute.

AML.T0037

Unredacted capture

The plaintext-carrying action argument, missing the inherited sensitive? flag, is written verbatim into the error message, log line, telemetry span, or :sys dump.

Disclosure

The actor reads the captured output and recovers the plaintext of a field the application believed was protected by encryption at rest.

Access or trigger

An actor either has routine access to logs/error trackers/telemetry, or sends input that triggers a validation error on a cloaked attribute.

AML.T0037

Unredacted capture

The plaintext-carrying action argument, missing the inherited sensitive? flag, is written verbatim into the error message, log line, telemetry span, or :sys dump.

Disclosure

The actor reads the captured output and recovers the plaintext of a field the application believed was protected by encryption at rest.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
ash-project/ash_cloak	—	—	No patch
ash_cloak	—	—	No patch

How severe is it?

CVSS 3.1

N/A

EPSS

0.1%

chance of exploitation in 30 days

Higher than 2% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○CISA SSVC: Public PoC

○Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What should I do?

1 step

1) Upgrade ash_cloak to >= 0.4.0, which hardcodes sensitivity correctly on the generated argument. 2) As defense in depth, explicitly set sensitive?: true on every source attribute that ash_cloak wraps, regardless of the framework version, so Ash's built-in redaction covers the argument even if future refactors reintroduce the gap. 3) Audit historical logs, error-tracker archives (Sentry/AppSignal/Honeybadger), telemetry stores, and crash-report retention for any plaintext values tied to cloaked fields and purge/rotate exposed secrets or notify affected data subjects per your DPA obligations. 4) Add a detection rule flagging any occurrence of known-sensitive-looking values (API key formats, PII patterns) in log or telemetry pipelines as a compensating control. 5) Restrict access to logs, error trackers, and :sys dump tooling to the minimum necessary staff while the audit is in progress.

What does CISA's SSVC say?

DecisionTrack*

Exploitationpoc

AutomatableNo

Technical Impactpartial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Data LeakagePrivacy ViolationFrameworkAML.T0037- Data from Local System

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15-Accuracy, robustness and cybersecurity

ISO 42001

Annex A - Data for AI systems-Data governance and protection

OWASP LLM Top 10

LLM06-Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-81322?

ash_cloak, a field-level encryption library for the Elixir Ash Framework, has a design flaw where the plaintext value it is supposed to encrypt gets copied into an internal action argument that inherits the source attribute's sensitive flag — so if a developer didn't explicitly mark that attribute sensitive?: true, the cleartext is never redacted. That plaintext then surfaces verbatim in changeset inspection output, validation error messages, telemetry events, :sys dumps, and any error-tracker payload (Sentry, AppSignal, etc.), meaning anyone with routine access to logs or crash reporting — or anyone who can simply trigger a validation error on that field — can recover data the application believed was encrypted at rest. There is no CVSS score, no EPSS data, no public exploit, and it is not in CISA KEV, and exploitation requires either insider/observability access or the ability to induce an error, so this is a low-urgency, high-relevance-to-scope issue rather than an actively exploited one. The blast radius is any application using ash_cloak to encrypt attributes without setting sensitive? true on the source attribute. Action: upgrade to ash_cloak >= 0.4.0, audit all cloaked attributes to confirm sensitive?: true is set on the source attribute as defense in depth, and scrub historical logs/error-tracker payloads/telemetry stores for any plaintext that may have already leaked from affected fields.

Is CVE-2026-81322 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-81322, increasing the risk of exploitation.

How to fix CVE-2026-81322?

1) Upgrade ash_cloak to >= 0.4.0, which hardcodes sensitivity correctly on the generated argument. 2) As defense in depth, explicitly set sensitive?: true on every source attribute that ash_cloak wraps, regardless of the framework version, so Ash's built-in redaction covers the argument even if future refactors reintroduce the gap. 3) Audit historical logs, error-tracker archives (Sentry/AppSignal/Honeybadger), telemetry stores, and crash-report retention for any plaintext values tied to cloaked fields and purge/rotate exposed secrets or notify affected data subjects per your DPA obligations. 4) Add a detection rule flagging any occurrence of known-sensitive-looking values (API key formats, PII patterns) in log or telemetry pipelines as a compensating control. 5) Restrict access to logs, error trackers, and :sys dump tooling to the minimum necessary staff while the audit is in progress.

What systems are affected by CVE-2026-81322?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks.

What is the CVSS score for CVE-2026-81322?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworks

MITRE ATLAS Techniques

AML.T0037Data from Local System

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: Annex A - Data for AI systems

OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

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.

Exploitation Scenario

An internal user with read access to the company's error-tracking dashboard (a common integration role) or an external attacker who can submit malformed input to trigger a validation error on a cloaked field (e.g., submitting an over-length or malformed value to an API endpoint backed by an Ash resource) causes Ash to raise Ash.Error.Invalid. Because the plaintext-carrying argument was never marked sensitive, the full unredacted value of the 'encrypted' field appears in the resulting error message, log line, or telemetry span. The attacker or insider then simply reads that output — from application logs, the error tracker UI, or captured telemetry — to recover data (e.g., an API key or PII field) that the application's data model assumed was protected by encryption at rest.

Weaknesses (CWE)

CWE-200Exposure of Sensitive Information to an Unauthorized Actor

CWE-200 — Exposure of Sensitive Information to an Unauthorized Actor: The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.

[Architecture and Design] Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

Source: MITRE CWE corpus.