What was found
Simon Tatham, the developer behind PuTTY, noticed in early September that an update to the Linux Zoom client had started proactively reading everything written to the X11 clipboard. Zoom 7.1.5 on Linux does it. The previous version he ran, 6.6, did not. He documented the behavior in a Mastodon thread that has since drawn hundreds of boosts, and the HN discussion pushed it to the front page.
The mechanics are straightforward once you know how X11 selections work. Zoom watches for clipboard changes using the XFIXES extension. Whenever a new client claims ownership of the CLIPBOARD selection, Zoom immediately sends it a paste request. That means the moment anything lands on your clipboard, whether a password from your manager, a token, a paragraph you copied to move between documents, Zoom asks for it and receives it.
Why the clipboard leaks by design
The X11 selection model puts the data source in charge. When an application wants to paste, it contacts the current selection owner and requests the data. Nothing is stored in the server; the owner hands over bytes on demand. This design enables tricks like a selection client that always pastes the current time, and it also means the owner knows exactly when someone is reading the clipboard.
The flip side is that any client can also ask proactively. There is no permission prompt on X11, no user consent step between “something new is on the clipboard” and “an application now has it.” Wayland closes this hole by making clipboard access go through the compositor with focus rules, which is one reason the Wayland migration keeps coming up in security contexts, despite its own rough edges for tools that legitimately need clipboard access.
How to see it yourself
The neat part of Tatham’s writeup is that his workflow caught it. He uses a one-shot paste tool: it claims clipboard ownership, fulfills exactly one paste request, then exits. It is handy for queuing several values and pasting them into form fields one by one. After the Zoom update, the tool started terminating instantly, because Zoom had already consumed its one allowed paste request.
You can reproduce the check with xclip, which is in Debian and Ubuntu repositories already:
echo -n foo | xclip -selection clipboard -loop 1 -verbose
On a clean system, that command sits and waits until you actually paste somewhere, then exits. On a machine with Zoom 7.1.5 running, it exits immediately. Zoom requested the paste the moment xclip claimed the selection. It is about the cheapest clipboard monitor test available, and it works as a general audit for other clients too. Tatham caught Slack doing something similar last year, though Slack at least gated it on window focus and offered a setting to turn it off. Zoom offers no such toggle.
Why it matters even if you trust Zoom
It is easy to shrug this off. Video conferencing software reading the clipboard is not exfiltrating data anywhere, presumably. But the pattern matters for three reasons.
First, many password managers on Linux still use the clipboard as the delivery mechanism for credentials. Copy a password, paste it into a login form, done. With Zoom running, that password passed through Zoom’s process on the way. Even if Zoom stores nothing, the secret has now crossed a trust boundary nobody consented to.
Second, there is no opt-out. The behavior arrived in a routine client update with no disclosure in release notes. If a feature is intentional, say so. If it is a bug, fix it. Silence is the part that erodes trust.
Third, this generalizes. Any application on X11 can do exactly this, and the only reliable detection is watching for paste requests against selection owners, which is precisely the trick Tatham’s one-shot tool performs. If you care about clipboard hygiene on Linux desktops, running a one-shot claim and seeing who immediately asks for the data is a five-second audit worth adding to your routine.
What Zoom’s options look like
Zoom has not responded publicly at the time of writing. The plausible explanations run from deliberate clipboard caching for its own paste features, to a framework-level change in whatever toolkit the Linux client uses, to an outright bug in how the client handles selection ownership. None of those explanations excuse the silence, but they predict different fixes: a framework regression can disappear in the next update, while a deliberate feature only goes away if enough customers push back.
History suggests pushback works. When Slack was caught doing something similar last year, the behavior was focus-gated and a configuration option existed to disable it. That looks like a company that heard from users and added an escape hatch. Zoom’s client has no equivalent setting today, so the practical levers are filing a support ticket, raising it on the Zoom forums, and in the meantime treating the clipboard as shared with every running application on the desktop.
It is also worth noting who found this. A one-shot paste tool is an obscure piece of workflow plumbing, and the only reason the behavior surfaced is that someone’s tooling broke loudly instead of silently. Clipboard access is invisible in process monitors, does not show up in file access logs, and leaves no trace in most audit setups. If an application is going to quietly collect everything you copy, a broken paste workflow is about the only thing that will expose it. That asymmetry, between how easy it is to read the clipboard and how hard it is to detect, is the real story here.
For now, the practical advice: on Linux, paste passwords with the keyboard-only tools your password manager provides where possible, keep sensitive values out of the shared clipboard, and if you run Zoom, run the xclip test yourself and see what happens. Then decide whether that is the behavior you want on your desktop.