Skip to content

EEF-CVE-2026-95105 CVE-2026-95105

Cloak AES-CTR cipher lacks ciphertext authentication, allowing chosen-plaintext forgery by bit flipping

Not rated yet Hex
Severity
0.0 / 10
Unknown · CVSS 4.0
Exploit chance (EPSS)
0.13%
Chance of exploitation in the next 30 days. Higher than 2.77% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-649 Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking
Fix
None yet
No fixed version published

Description

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.

Affected versions

Hex

PackageVulnerableFixed in
cloak
>= 0.1.0-pre
No fix yet

How to fix

No fixed version has been published yet. Until one is, remove or replace the package, or turn off or isolate the affected feature. This page updates when a fix ships.

Severity breakdown

CVSS 4.0 0.0

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

Attack vector
Network
Attack complexity
Low
Attack requirements
Present
Privileges required
None
User interaction
None
Confidentiality (vulnerable system)
None
Integrity (vulnerable system)
High
Availability (vulnerable system)
None
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
None
Availability (subsequent systems)
None

Weakness

CWE-649: Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking

The product uses obfuscation or encryption of inputs that should not be mutable by an external actor, but the product does not use integrity checks to detect if those inputs have been modified.

How to prevent it
  • Architecture and Design: Protect important client controllable tokens/parameters for integrity using PKI methods (i.e. digital signatures) or other means, and checks for integrity on the server side.
  • Architecture and Design: Repeated requests from a particular user that include invalid values of tokens/parameters (those that should not be changed manually by users) should result in the user account lockout.
  • Architecture and Design: Client side tokens/parameters should not be such that it would be easy/predictable to guess another valid state.
  • Architecture and Design: Obfuscation should not be relied upon. If encryption is used, it needs to be properly applied (i.e. proven algorithm and implementation, use padding, use random initialization vector, user proper encryption mode). Even with proper encryption where the ciphertext does not leak information about the plaintext or reveal its structure, compromising integrity is possible (although less likely) without the provision of the integrity service.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
EEF-CVE-2026-94206
Cloak PBKDF2 field ignores the configured iteration count and runs only :size rounds
Not rated yet Also affects cloak

Credits: Jonatan Männchen / EEF, Peter Ullrich

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor