ash_cloak CVE-2026-81322

Two conditions must both be met: (1) the target application runs ash_cloak 0.1.0-0.3.x with at least one cloaked attribute that was not explicitly declared with sensitive?: true - this is the library default and therefore expected to be the common case; and (2) the attacker can read application logs, error-tracker payloads (Sentry, AppSignal, Honeybadger, etc.), :sys dumps, or telemetry streams, OR can trigger a validation error involving the cloaked attribute and observe the returned error struct or API error response. What limits exploitation: access to observability infrastructure is typically restricted to internal staff or operators; the flaw cannot be exploited remotely against applications that suppress raw error messages in external API responses; and any deployment that explicitly declared sensitive?: true on its cloaked attributes is fully protected regardless of ash_cloak version.

The CVSS 4.0 score of 2.1 (AV:L/AC:L/AT:P/PR:N/UI:N/VC:L) accurately reflects a narrow blast radius: exploitation is local in vector, low in confidentiality impact, and gated on a specific attack condition (AT:P) - the cloaked attribute must lack an explicit sensitive?: true declaration. Despite the low number, practical risk exceeds the rating for deployments that route error payloads to cloud observability platforms, because those systems persistently aggregate and index structured error messages, widening exposure across time and personnel far beyond a single log file. No EPSS score was supplied and the vulnerability is not in CISA KEV, so widespread active exploitation is unconfirmed. Critically, the AT:P gating condition may in practice describe the majority of ash_cloak deployments, since sensitive?: true is opt-in and developers adopting a field-encryption library may reasonably assume the library handles redaction without requiring explicit annotation - meaning the true exposed population is likely larger than the score alone implies.

An insider or attacker with read access to the application's error-tracking dashboard reviews recorded validation failures and finds that error structs contain the literal plaintext of fields the developer assumed were opaque encrypted values. No decryption tooling or cryptanalysis is required - the value is present verbatim in the structured error payload.