CVE-2026-95105

## Summary Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking vulnerability in danielberkompas cloak allows an attacker with write access to stored ciphertext to make it decrypt to a chosen value via bit flipping. `Cloak.Ciphers.AES.CTR` encrypts with AES-256 in CTR mode and stores the key tag, the IV and the ciphertext with no MAC. `decrypt/2` checks only the key tag and the minimum length before it returns the plaintext, and `Cloak.Ciphers.Deprecated.AES.CTR` decrypts the legacy format the same way. CTR is a stream cipher, so a value XORed into the stored ciphertext is XORed into the plaintext at the same offset. An attacker who can write to the encrypted store (for example through SQL injection or a compromised replica) and who knows or can guess a stored plaintext can replace it with any value of the same length. The application receives that value with no error. This issue affects cloak: from 0.1.0-pre onward. ## Proof of concept 1. Encrypt `"role=user "` with `Cloak.Ciphers.AES.CTR.encrypt/2` and a random 32-byte key. 2. Without the key, XOR the last 10 bytes of the result (the ciphertext body) with `:crypto.exor("role=user ", "role=admin")`. Leave the key tag and the IV unchanged. 3. Call `Cloak.Ciphers.AES.CTR.decrypt/2` on the modified value. It returns `{:ok, "role=admin"}`. ## Impact An attacker who can write to the encrypted store can set encrypted fields with known or guessable contents, such as roles, flags, or fixed-format records, to values of their choice without the key. The application decrypts and trusts the forged value. ## Workarounds Configure the vault with `Cloak.Ciphers.AES.GCM` as the default cipher and re-encrypt existing values, for example with the `cloak.migrate.ecto` task from cloak_ecto. Then remove `Cloak.Ciphers.AES.CTR` and `Cloak.Ciphers.Deprecated.AES.CTR` from the vault configuration, so that ciphertext in the CTR format is no longer decrypted. AES-GCM authenticates the ciphertext and rejects modified values.