CVE-2026-32318: 
NixOS vulnerability analysis and mitigation

CVE-2026-32318 is an integrity check vulnerability in Cryptomator for iOS that enables a man-in-the-middle (MITM) attack against the Cryptomator Hub key loading mechanism. Prior to version 2.8.3, the iOS client trusted API and authentication endpoints specified in the vault.cryptomator configuration file without verifying host authenticity, allowing an attacker who can tamper with that file to redirect authentication flows to a malicious server and exfiltrate OAuth tokens. All Cryptomator for iOS versions up to and including 2.8.2 are affected. The vulnerability was disclosed on March 20, 2026, and carries a CVSS v3.1 base score of 7.6 (High) per the GitHub Security Advisory, or 5.9 (Medium) per NVD scoring (GitHub Advisory, Feedly).

The root cause is a failure to validate the origin and integrity of endpoints read from the vault.cryptomator configuration file before initiating OAuth authentication flows (CWE-346: Origin Validation Error; CWE-354: Improper Validation of Integrity Check Value; CWE-923: Improper Restriction of Communication Channel to Intended Endpoints). An attacker with write access to the vault configuration file — for example, via a compromised or attacker-controlled cloud storage path — can replace the legitimate Hub API endpoint with a malicious one while keeping the legitimate auth endpoint, causing the client to send authentication tokens to the rogue server. The fix introduced a HubHostTrustValidator that enforces URL authority consistency (hub and auth URLs must share one authority), blocks non-localhost HTTP, auto-trusts *.cryptomator.cloud domains, and implements Trust-on-First-Contact (TOFU) host verification with explicit user approval for unknown hosts (GitHub Advisory, GitHub PR #444, Patch Commit).

Successful exploitation allows an attacker to exfiltrate Hub OAuth authentication tokens, which could then be used to gain unauthorized access to Hub-backed encrypted vaults. The Cryptomator project notes that vault data itself was never directly at risk because Cryptomator Hub uses end-to-end encryption, but stolen tokens could enable an attacker to impersonate the victim and access vault keys through the Hub API. The attack is limited to users who unlock Hub-backed vaults in environments where the vault.cryptomator file can be altered (e.g., shared or attacker-controlled cloud storage), and requires the victim to actively attempt a vault unlock (GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the disclosure date (GitHub Advisory, Feedly). The EPSS score is approximately 0.011% (0.000110), indicating very low probability of near-term exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires the attacker to have the ability to modify the vault.cryptomator file and to be in a position to intercept or receive redirected authentication traffic, making opportunistic mass exploitation unlikely.

1. Gain write access to vault configuration: Obtain the ability to modify the target user's vault.cryptomator file — for example, by compromising a shared cloud storage account (Dropbox, Google Drive, etc.) where the vault is stored, or by controlling a storage path the victim syncs.
2. Tamper with the vault configuration file: Edit the vault.cryptomator JSON file to replace the legitimate Hub API endpoint URL with a URL pointing to an attacker-controlled server, while retaining the legitimate authentication (OAuth) endpoint to avoid raising suspicion.
3. Set up a malicious API server: Deploy a server at the attacker-controlled endpoint that mimics the Cryptomator Hub API and is configured to capture incoming authentication tokens or OAuth credentials.
4. Wait for victim to unlock the vault: When the victim opens Cryptomator for iOS and attempts to unlock the Hub-backed vault, the app reads the tampered vault.cryptomator file and initiates the OAuth flow against the legitimate auth endpoint.
5. Intercept the token: After the victim authenticates, the iOS client sends the resulting token to the attacker-controlled API endpoint (as specified in the tampered config), allowing the attacker to capture it.
6. Use the exfiltrated token: Replay the captured OAuth token against the legitimate Cryptomator Hub API to retrieve vault keys and access encrypted vault contents (GitHub Advisory, GitHub PR #444).

• File System: Unexpected modifications to the vault.cryptomator configuration file, particularly changes to Hub API endpoint URLs to point to unfamiliar or non-*.cryptomator.cloud domains; file modification timestamps inconsistent with user activity.
• Network: Outbound HTTPS connections from the Cryptomator iOS app to Hub API endpoints that do not match the expected Hub server hostname; OAuth token POST requests directed to IP addresses or domains not associated with the organization's Cryptomator Hub instance.
• Logs: Cloud storage provider audit logs showing unexpected writes or modifications to vault.cryptomator files by accounts or sessions not belonging to the vault owner.

Upgrade Cryptomator for iOS to version 2.8.3 or later, which introduces TOFU host verification and URL authority consistency checks that prevent the client from trusting unrecognized Hub endpoints (GitHub Release 2.8.3). If immediate upgrade is not possible, two workarounds are recommended: (1) restrict outbound client network access so Cryptomator can only reach trusted Hub hosts, and (2) protect vault configuration file integrity by enforcing strict file permissions and using only trusted sync or storage paths to prevent unauthorized modification of vault.cryptomator (GitHub Advisory). Additionally, implementing file integrity monitoring on vault configuration files can help detect unauthorized tampering.

Cryptomator published a vendor blog post on March 13, 2026, disclosing the Hub vault unlock vulnerability ahead of the formal CVE publication, and emphasized that vault data was never directly at risk due to end-to-end encryption (Cryptomator Blog). The GitHub Security Advisory was published on March 20, 2026, and the fix was merged on March 12, 2026, demonstrating a proactive patch-before-disclose approach. Social media coverage was limited, with brief mentions on Mastodon and Bluesky aggregating the CVE details without significant community debate.