CVE-2026-81319: Unsafe deserialization of decrypted terms enables node DoS in AshCloak
Deserialization of Untrusted Data vulnerability in ash-project ashcloak allows an attacker who can influence the bytes of an encrypted column to crash the BEAM node, by triggering unbounded atom creation or a decompression bomb during decryption.
AshCloak.Calculations.Decrypt decodes the decrypted binary with Ash.Helpers.nonexecutablebinarytoterm/1 without the :safe option, so atoms in the payload are interned during the decode and never garbage collected, and the term format's compressed form is inflated transparently. vault.decrypt!() is the only barrier and stops tampering only for an authenticated cipher. Cloak also ships the unauthenticated AES.CTR, whose ciphertext an attacker who knows their own plaintext can XOR into any same-length payload without the key, so an ordinary read of the forged column reaches the decoder. A few hundred kilobytes of distinct atoms exhausts the atom table, or a small compressed payload inflates to gigabytes.
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 decrypted column data is only processed after vault.decrypt!() with an authenticated cipher, since vault.decrypt!() is stated as the only barrier that stops tampering only for an authenticated cipher.
ash-project ash_cloak vault.decrypt!() / decrypted-column access controls = Authenticated cipher only - Compensating control
If you cannot immediately upgrade, prevent untrusted users from influencing the bytes of the encrypted column that ash_cloak decrypts/deserializes, because an attacker who can influence those bytes can crash the BEAM node via unbounded atom creation or a decompression bomb.
Event History
Frequently Asked Questions
Which deployments are most exposed to exploitation?
Deployments using an affected ash_cloak version with encrypted columns that an attacker can modify are exposed. Risk is especially high when Cloak's unauthenticated AES.CTR cipher is used, because an attacker who knows plaintext they supplied can alter a same-length ciphertext without knowing the key.
What attacker access is required?
The attacker must be able to influence the stored bytes of an encrypted column and cause that column to be read and decrypted. With an authenticated cipher, vault.decrypt!() prevents tampering; with AES.CTR, forged ciphertext can reach the decoder.
Are versions prior to 0.4.0 affected?
Yes. The affected range is ash_cloak 0.1.0 through versions before 0.4.0.
What is the impact if exploitation succeeds?
A forged decrypted term can create unbounded atoms, exhausting the BEAM atom table, or trigger decompression of a small payload into gigabytes of data. Either condition can crash the BEAM node.
What can be done if upgrading is not immediately possible?
Prevent untrusted parties from modifying encrypted-column bytes and avoid use of the unauthenticated AES.CTR cipher. Authenticated encryption causes vault.decrypt!() to reject tampered ciphertext before it reaches deserialization.