On Wednesday 2 September, Simon Tatham, the author of PuTTY, noticed that an update to the Linux Zoom client had started reading everything written to his clipboard. Not on paste. On every change. Ten days later the note reached the front page of Hacker News, where the discussion was mostly about whether anyone should use Zoom at all. That is the wrong argument. There is no CVE here, no malware, and no compromise. A signed, IT-approved, enterprise-licensed application used a facility the display protocol has always offered, and nobody noticed for six weeks. The interesting question is what else is holding that facility open on your developers’ machines, and what you have been putting through it.
TL;DR
- Zoom’s Linux client 7.1.5 watches the X11
CLIPBOARDselection for ownership changes and immediately requests the contents, whether or not you ever paste into Zoom. - There is nothing about the clipboard or pasting in Zoom’s release notes for that version, so no change-management process would have caught it.
- On X11 any connected client can ask for the selection at any time. There is no permission prompt, no access control list and no audit log.
- That matters because the clipboard is the last mile of almost every secret you hold: password manager to browser field, vault to terminal, connection string to dashboard.
- Wayland improves this and does not fix it, and the durable answer is to stop routing credentials through the clipboard in the first place.
What Actually Happens
X11 has no clipboard. It has selections and an owner. When you copy, your application tells the X server that it now owns the CLIPBOARD selection. When another application pastes, it asks the current owner to send the data over. The value never sits in a central store; it lives in the source application’s memory until somebody requests it.
Tatham’s finding is that Zoom 7.1.5 for Linux, build 4332, released on 20 July 2026, uses the XFIXES extension to detect a change of selection owner and then immediately sends that new owner a paste request. His previous install, 6.6, did not do this. The traditional X11 PRIMARY selection, the select-then-middle-click one, is left alone. He only spotted it because he uses a one-shot paste tool that serves exactly one paste request and then exits: Zoom consumed the single paste, so his own paste arrived empty.
Check Zoom’s release notes for 20 July 2026 and the word clipboard does not appear in the 7.1.5 entry. Neither does paste. The behaviour of a client that your staff run all day, in the presence of every credential they handle, changed without a line of documentation. And it is not only Zoom: a second person in the same thread, running 7.2.3, found that Easy Effects, an audio equaliser, was requesting the selection too. Nobody has an inventory of which locally installed applications do this, because until last week nobody thought to ask.
The Boring Explanation Is Probably the Right One
Assume no malice, because the likeliest story is a bug fix. Under X11, if the application you copied from has already exited, there is no owner left to serve the data and your paste comes back empty. Grabbing the selection the moment it changes is a crude fix for the support ticket that reads “I copied the meeting link, closed my browser, and Zoom pasted nothing.” That is almost certainly what happened here.
It changes nothing about the exposure. The value is now inside the address space of a proprietary network client, and no log on your estate records that it got there. Benign intent and unbounded access are not alternatives. They are the normal case, and they are why you govern the channel rather than the vendor.
The Last Mile of Every Secret You Hold
Look at where your credentials actually live and you will find a decent story: a secrets manager, short-lived tokens, SSO, a rotation policy, an SSH agent. Then look at how those values reach the places they are needed. A human selects them and presses Ctrl+C. Password manager into a login form. Vault into a terminal. Production connection string into a hosting dashboard. API key into a client’s CMS. Every control you bought ends at the moment of copy, and at that moment the value becomes readable by every client connected to your display.
In April we wrote that the developer workstation is the real attack surface, and that post was about credentials at rest: config files, agent configs, plaintext tokens in dotfiles. This is the same secret in motion, and not one of those controls touches it. The clipboard has no ACL, no audit trail, no rotation signal and no entry in anybody’s data processing agreement.
For an agency the shape is worse, because one machine holds more than one client’s credentials. The conferencing client you opened for client A’s standup is still resident in the afternoon when you paste client B’s database URL out of Bitwarden. No attacker is required for that to be a multi-tenancy problem.
It is also a contract question worth asking before a client asks it. You name sub-processors for client data. Is your conferencing vendor a sub-processor for whatever your developers copy during the working day? I have yet to see an agreement that answers that, and procurement questionnaires have a habit of catching up with facts like this one.
Wayland Helps. It Is Not a Tick-Box.
Under most Wayland compositors a client needs keyboard focus to read the selection, which removes the background-read case entirely, and a client that tries to steal focus in order to grab it is at least visible. That is a genuine improvement and a good reason to migrate.
It is not a closed door. Applications can still run under Xwayland and get the old semantics. Compositor policy varies, so “we are on Wayland” is not an answer without naming the compositor. The data-control protocols that clipboard managers need are an explicit exception to the focus rule, and whether a given client can reach them depends on your desktop.
The Test, and What It Will Not Tell You
On a graphical Linux session, this prints the name of the first client that asks for the selection:
echo -n test | xclip -selection clipboard -loop 1 -verboseTwo honest caveats. We could not run it against our own build hosts, which are headless, so this is Tatham’s method rather than our reproduction. And attribution is weaker than it looks: in his case the window requesting the paste was not Zoom’s main window, and mapping an X window identifier back to the application that owns it is unreliable by design. Treat a positive result as a signal, not as an inventory.
What to Do About It
- Stop moving secrets by hand where a tool can inject them. Pipe them straight into the process that needs them, generate environment files at runtime, load keys into the agent from standard input, and reserve copy-and-paste for things you would not mind reading aloud.
- Use the browser tab for conferencing wherever the feature set allows. A web application reading your clipboard needs an origin-scoped permission; an installed native client needs nothing at all.
- Sandbox the clients you must install. Flatpak, bubblewrap or a separate desktop login turns “what can this read” into a decision you made rather than a default you inherited.
- Configure your clipboard manager to forget. A short clear-down timer and an exclusion for password-manager entries removes the persistent copy that survives the meeting.
- Put locally installed proprietary clients in a register with an owner and a review date, because the behaviour that changed in a point release is the behaviour nobody re-reviews.
- Document what your own products do. If you ship a desktop, kiosk or appliance application that touches the selection, say so in the handover, for the reason above.
The X11 selection protocol encodes an assumption from a period when every program on your display was one you chose, compiled or trusted, and the only question was how to get text from one window to another. That assumption expired decades ago and the protocol did not. Mobile platforms got a clipboard permission prompt only after enough applications were caught reading it; the Linux desktop never got one, because it was built for people who owned their software. The defect is in the trust model, not in the app that used it, which is the same argument we made when a television turned out to be mapping the LAN your admin panel trusts: the boundary you assume is not the boundary that exists.
We do secure workstation and secrets-handling reviews as part of our DevOps work, and the credential-handover paths are usually the fastest thing to fix and the last thing anyone looks at. If you want someone to map where your clients’ secrets actually travel, get in touch.
