The PuTTY Author Caught Zoom Reading the Linux Clipboard on Every Copy
Simon Tatham found that Zoom 7.1.5 uses the XFIXES extension to monitor every clipboard change on Linux, requesting the contents before the intended target can. Zoom has not responded.
The WJS Desk
Sep 13, 2026 · updated 11 days ago · 5 min read
Simon Tatham, the developer who created and maintains PuTTY (the SSH client installed on practically every Windows machine that has ever touched a server), noticed something wrong after updating his Linux Zoom client from version 6.6 to 7.1.5. A clipboard tool he uses, designed to terminate after fulfilling a single paste request, was dying immediately. Something was requesting the clipboard contents before the intended target application could.
That something was Zoom. Tatham posted his findings on Mastodon, and the thread hit 183 points on Hacker News. We traced the technical details, checked Zoom's history, and the pattern is familiar enough that we stopped being surprised halfway through.
What Tatham Found
Zoom 7.1.5 uses the XFIXES extension, specifically XFixesSelectSelectionInput(), to receive a notification every time any application claims ownership of the X11 CLIPBOARD selection. That is the Ctrl+C / Ctrl+V clipboard, the one most Linux desktop users interact with. When ownership changes, Zoom immediately sends the new owner a ConvertSelection request to retrieve the data.
This happens continuously in the background. Zoom does not need to be focused. Zoom does not need the user to paste anything. Every time you copy text, a file path, a password, or a token, Zoom requests a copy for itself.
Tatham confirmed that Zoom reads only the CLIPBOARD selection and ignores PRIMARY (the traditional X11 select-then-middle-click mechanism) and SECONDARY (virtually unused). What Zoom does with the clipboard contents after receiving them is unknown. Tatham could not determine whether the data is stored locally, transmitted to Zoom's servers, or discarded.
The quiet part: Password managers like KeePassXC, Bitwarden, and 1Password commonly use the clipboard to transfer credentials to browser fields. Every password copy is intercepted by Zoom. So is every API token, SSH key, and authentication code copied from a terminal or email.
Why X11 Makes This Worse
The X11 clipboard model is fundamentally different from Windows or macOS. It is pull-based, not push-based. When you "copy" text, your application merely claims ownership of a selection by calling XSetSelectionOwner(). The actual data stays in your application's memory. When another application wants to "paste," it sends a ConvertSelection request through the X server, which relays it to the owner.
This means any connected X11 client can request data from any selection owner at any time. There is no permission prompt. There is no notification banner. On iOS 14, Apple added a banner that exposes apps reading the clipboard (this is what caught TikTok reading clipboard data every few keystrokes in 2020). X11 has no equivalent mechanism.
| Platform | Clipboard Access Model |
|---|---|
| iOS 14+ | Banner notification on every clipboard read |
| Android 12+ | Toast notification on clipboard access |
| macOS Sonoma+ | Permission prompt for sandboxed apps |
| Wayland (Linux) | Focus-gated: only focused app can read |
| X11 (Linux) | No restrictions. Any client reads any selection. |
Wayland, the successor to X11, is better. Under Wayland, the compositor mediates all clipboard access, and generally only the application with keyboard focus can read contents. A backgrounded Zoom window would be blocked. However, applications running under XWayland (the compatibility layer) share a single X11 session and may bypass this restriction. HN user superkuh warned that Wayland's restrictions also break legitimate use cases like command-line paste tools run non-interactively.
The Pattern Nobody Should Be Surprised By
This is not Zoom's first time. We counted at least 6 prior incidents:
- 2019: Security researcher Jonathan Leitschuh discovered Zoom installed a hidden web server on macOS that persisted after uninstall. Any website could force-join a user to a call with their webcam on. Apple pushed a silent macOS update to remove it (CVE-2019-13450).
- 2020: The Zoom installer used pre-installation scripts to install without proper consent, behavior described by researchers as "akin to malware."
- 2020: The iOS app sent analytics data to Facebook, including device info, even for users without Facebook accounts (reported by Motherboard).
- 2020: Zoom marketed "end-to-end encryption" but actually used transport encryption (TLS). The Intercept reported this; the FTC settled with Zoom over the deceptive claim.
- 2020: Zoom admitted some calls from non-Chinese users were routed through Chinese servers.
- 2020: Weak default security settings enabled mass meeting intrusion ("Zoom-bombing"), leading to an $85 million class-action settlement.
Tatham himself had previously documented identical behavior in Slack's Linux client: Slack reads the clipboard whenever it gains focus, though Slack offered a configuration option to disable it. Zoom's version is more aggressive (continuous monitoring regardless of focus) and offers no disable option.
What the Thread Said
HN user st_goliath clarified the technical context: "There is no such thing as an 'X11 clipboard.' X11 has a concept of a 'selection,'" explaining how modern desktop environments use daemons to emulate Windows-style behavior on top of X11's architecture.
User ryandrake critiqued the clipboard as a "legacy idea" and proposed permission-based access similar to mobile platforms. User amelius asked the broader question: "When will Linux distributions properly sandbox our applications? Our phones have had a better permission system for years."
User porridgeraisin offered the most charitable reading: Zoom might monitor clipboard events to work around X11's selection ownership model, where the source application closing causes the clipboard to lose data before the target can paste. This would be a reliability feature, not surveillance. But as user rmellow pointed out, reliability features do not need to run continuously in the background on every clipboard change.
User fsflover offered the nuclear option: "Qubes OS saved me, once again. On it, Zoom only has access to an empty VM and no access to the clipboard." Bitcoin Core developer nullc (Greg Maxwell) seconded this, noting Qubes' advantages for VM isolation, though he acknowledged video performance tradeoffs.
What You Should Do
We checked the practical options:
- Use Zoom in the browser. Firefox or Chromium's sandbox prevents clipboard access entirely. Video quality is somewhat degraded but functional. HN user jrm4 confirmed this works as a daily driver.
- Sandbox the native client. Flatpak with restricted permissions, Firejail, or a dedicated VM (Qubes) all isolate Zoom from the host clipboard.
- Switch to Wayland. If your desktop environment supports it, Wayland's focus-gated model blocks background clipboard reads (with the XWayland caveat noted above).
- Downgrade to 6.6. The behavior was introduced in 7.1.5. If clipboard privacy matters more than whatever 7.x added, the older version does not do this.
- Close Zoom before copying sensitive data. The lowest-tech option. If Zoom is not running, it cannot request your clipboard.
Zoom has not issued any public response. No blog post, no community forum reply, no statement to press. Given their history, we expect the response, if one comes, will describe the behavior as a feature for improving paste reliability. The question they will not answer: why a video conferencing application needs to read every clipboard change, continuously, in the background, without asking.
iOS caught TikTok with a banner. X11 has no banner, which is why it took the PuTTY author noticing a one-shot paste tool dying too early.
