CVE-2026-32303: 
NixOS vulnerability analysis and mitigation

CVE-2026-32303 is a vault configuration integrity check vulnerability in Cryptomator that enables a man-in-the-middle (MITM) attack on the Hub key loading mechanism. Prior to version 1.19.1, the Cryptomator client trusted endpoints specified in the vault.cryptomator configuration file without performing host authenticity checks, allowing an attacker who can modify that file to mix a legitimate authentication endpoint with a malicious API endpoint and exfiltrate OAuth tokens. All Cryptomator versions before 1.19.1 are affected; users unlocking Hub-backed vaults are specifically at risk. The vulnerability was disclosed on March 20, 2026, and patched in version 1.19.1 released March 12, 2026. It carries a CVSS v3.1 score of 7.6 (High) per the GitHub Security Advisory (GitHub Advisory, Cryptomator Blog).

The root cause is a combination of CWE-346 (Origin Validation Error), CWE-354 (Improper Validation of Integrity Check Value), CWE-451 (UI Misrepresentation of Critical Information), and CWE-923 (Improper Restriction of Communication Channel to Intended Endpoints). The vault.cryptomator configuration file specifies both the authentication endpoint and the Hub API endpoint used during vault unlock; because the client performed no host authenticity verification against these values, an attacker with write access to the vault config file could substitute a malicious API endpoint while keeping a legitimate auth endpoint, causing the client to send Hub OAuth tokens to an attacker-controlled server. Exploitation requires the attacker to be able to alter the vault.cryptomator file — for example, via a compromised or attacker-controlled cloud storage path used to sync the vault. The fix (PR #4179, commit 6b82abc) introduced Trust-on-First-Contact (TOFU) host verification and an admin-configurable hostname allowlist (cryptomator.hub.allowedHosts) enforced before any Hub connection is attempted (GitHub Advisory, Patch Commit).

Successful exploitation results in exfiltration of Hub OAuth access tokens, which could allow an attacker to authenticate to the Cryptomator Hub API on behalf of the victim. Confidentiality impact is high (token theft enabling unauthorized Hub API access), while integrity impact is low and availability is unaffected. Importantly, Cryptomator's end-to-end encryption means vault data itself is not directly exposed — the risk is limited to token compromise and potential unauthorized Hub operations. The attack is scoped to users who unlock Hub-backed vaults in environments where the vault configuration file can be tampered with (GitHub Advisory).

No public exploit code or active in-the-wild exploitation has been reported; the Cryptomator team explicitly stated they are not aware of any active exploitation (GitHub Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.017% (0.000170), indicating very low probability of near-term exploitation. Exploitation requires an attacker to have write access to the vault.cryptomator file and the ability to operate a malicious API endpoint, making opportunistic mass exploitation unlikely (Feedly).

1. Gain write access to vault config: Obtain the ability to modify the target user's vault.cryptomator file — for example, by compromising the cloud storage account (Dropbox, Google Drive, etc.) used to sync the vault, or by having local filesystem access.
2. Identify Hub endpoints: Inspect the existing vault.cryptomator file to identify the legitimate Cryptomator Hub authentication endpoint (authEndpoint) and API endpoint fields.
3. Tamper with the config: Replace the Hub API endpoint field in vault.cryptomator with a URL pointing to an attacker-controlled server, while leaving the legitimate authentication endpoint intact so the OAuth flow proceeds normally.
4. Host malicious API server: Stand up an HTTPS server at the attacker-controlled endpoint that mimics the Cryptomator Hub API and logs incoming requests, including Authorization headers.
5. Wait for victim to unlock vault: When the victim opens Cryptomator and unlocks the Hub-backed vault, the client authenticates against the legitimate auth endpoint (obtaining a valid OAuth token) and then sends a Hub API request — including the Bearer token — to the attacker-controlled endpoint.
6. Exfiltrate token: Capture the OAuth token from the incoming request on the malicious server and use it to authenticate to the real Cryptomator Hub API as the victim (GitHub Advisory, Patch Commit).

• File System: Unexpected or unauthorized modifications to the vault.cryptomator file, particularly changes to the Hub API endpoint or authentication endpoint fields; file modification timestamps inconsistent with normal user activity.
• Network: Outbound HTTPS connections from the Cryptomator client process to unexpected or unknown Hub API hostnames (i.e., hostnames not matching the organization's known Cryptomator Hub server); OAuth Bearer token requests sent to non-standard endpoints.
• Logs: Cryptomator application logs showing Hub unlock attempts contacting unfamiliar API hosts; authentication events on the legitimate Hub server not followed by expected API calls (token used elsewhere).
• Process: Cryptomator client making network connections to hosts not previously seen in normal operation during vault unlock sequences (GitHub Advisory).

Upgrade Cryptomator to version 1.19.1 or later, which introduces TOFU host verification (requiring explicit user approval on first connection to a Hub host) and an admin-configurable hostname allowlist via the cryptomator.hub.allowedHosts system property (Release 1.19.1). For organizations unable to upgrade immediately, two workarounds are available: (1) restrict outbound client network access so Cryptomator can only reach trusted Hub hosts, and (2) protect the integrity of the vault.cryptomator file using strict file permissions and trusted sync/storage paths to prevent unauthorized modification (GitHub Advisory). Centrally managed deployments can optionally disable TOFU entirely and rely solely on the admin allowlist by configuring cryptomator.hub.allowedHosts and setting cryptomator.hub.enableTrustOnFirstUse=false.

Cryptomator published a blog post on March 13, 2026, disclosing the vulnerability and emphasizing that vault data was never at risk due to end-to-end encryption, and that no active exploitation was known (Cryptomator Blog). The release of version 1.19.1 received positive community reactions on GitHub, with 16 users reacting to the release notes (Release 1.19.1). Social media coverage was limited to automated CVE tracking accounts on Mastodon and Bluesky, with no significant independent researcher commentary or media coverage identified.