DoS in the Tresorit Linux client

Sep 4, 2026Medium · CVSS 4.0: 5.7CWE-674 → CWE-400Disputed · vendor: by design

Local denial of service

A symlink loop in a Tresorit-watched folder makes Tresorit allocate memory without bound until the machine runs out of RAM and freezes.

The trigger is about eight bytes of symlink text. No exploit code, no privileges, no network. I hit it by simply cloning an open-source repository onto my machine. Tresorit 3.5.1281.4700.

Severity

CVSS 4.0: 5.7 (Medium), CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Metric	Value	Why
Attack Vector	Local	The symlinks have to end up in a Tresorit-watched folder on the victim’s machine. Shared tresors don’t carry symlinks, so there is no network route.
Attack Complexity	Low	The trigger is two symlinks and works the same way every time.
Attack Requirements	Present	The symlinks only take effect if the victim clones, extracts or mounts them inside a folder Tresorit syncs, which the attacker can’t control.
Privileges / User Interaction	None / Passive	The victim only performs an ordinary action like `git clone`; Tresorit picks up the loop on its own, with no further interaction.
Confidentiality / Integrity	None / None	Nothing is read or modified.
Availability	High	Memory grows without bound until the machine freezes, and the leak resumes after every restart until the symlinks are permanently deleted.
Subsequent system	None	The effects stay on the victim’s own workstation.

What happens

Put two symlinks in a watched directory: one pointing at its own folder (.qa -> .) and one nested link resolving back through the loop (sub/.qa -> ../.qa/). Tresorit walks by textual path, not by the (device, inode) identity the kernel uses, so a/.qa/.qa/.qa/… looks like an endless run of new directories and the walk never stops.

While discovering the directory’s content, Tresorit follows this endless loop. Memory climbs steadily, about 10 MB/min from a single symlink and 3 GB/min from the real example that first triggered it.

Why it’s nasty

Ordinary content. .qa -> . is a normal test convention in the Ceph repo; a plain git clone set it off on my machine. Extracting an archive or mounting a share would trigger the same crash.
Delayed effect. On my machine it took about 15-20 minutes until all memory got eaten up. It’s hard to pinpoint the cause as the file was downloaded or created a while ago.
Survives reboots. SIGTERM takes over 30 s, past most stop timeouts, and Tresorit automatically restarts within a minute. It re-reads the files and repeats its leak.
Survives trashing. Trash is watched too, so moving the symlinks there just keeps Tresorit looping over them. They have to be permanently deleted.
GUI freezes; unsyncing impossible. Tresorit’s GUI hangs, so you can’t unsync the directories from inside the app.

Shared tresors are not a vector: symlinks aren’t stored server-side, so the trigger can’t reach another user. Every real vector is local, usually a cloned repository, whether stumbled into or specially prepared.

Possible vendor fixes

Dedupe the walk by (device, inode) so a cycle terminates, or
Stop descending symlinks at scan time, matching the app’s own no-sync-symlinks policy.

Vendor position and rebuttal

Tresorit judged it “not a security issue”, citing the deliberate choice to follow symlinks. That justifies traversal, but not unbounded memory allocation. The suggested sync-filter workaround assumes you already know the toxic path and have a responsive GUI.

My view: that “deliberate design decision” is indefensible. The bug is not easy to weaponize against specific targets, but it occurs in the wild as is and causes out-of-memory crashes that are hard to diagnose and hard to stop.

Timeline

Date	Event
2026-05-10	A routine repo clone drives my workstation into an OOM freeze.
2026-05-11	Inquiry to the vendor.
2026-05-13	Report sent to the vendor.
2026-06-01	Vendor requests more time.
2026-06-06	Vendor declines, citing a deliberate design decision.
2026-09-04	Public disclosure.

Credits

Found and reported by Alexander Boll.