Zoom reads your clipboard uninvited

The Linux Zoom client reads the contents of the X11 clipboard proactively. The trigger is a write to the clipboard, not a paste into Zoom and not any action the user takes inside a meeting. When an application on the system places data into the X11 selection, the Zoom client reads it. This is a privacy concern and a potential security risk for users of that client.

Treat the distinction between a proactive read and a user paste as the core of this briefing. The user model of a clipboard is a transfer executed on demand. You copy, you choose a destination, you paste. Under that model, the destination application receives clipboard data only when the user directs it there. The behavior described here does not follow that model. The Zoom client acquires clipboard content without the user selecting Zoom as the destination.

What the client does with the content it reads is not confirmed. Whether the data is retained, transmitted, or discarded is not stated and is therefore not established. Absence of that information is a condition of this briefing, not a detail to be filled in. The confirmed fact is narrow and sufficient on its own: an application reads clipboard data the user did not hand to it.

What failed is the transfer boundary around the clipboard. On X11 the clipboard is a shared channel between clients connected to the same display. The observable behavior is that content written to that channel reaches the Zoom client without a user-initiated paste into Zoom. Data crossed into an application that was not the user’s chosen destination.

The scope of the read, as stated, is everything written to the X11 clipboard. It is not scoped to a specific data type, a specific source application, or a specific field the user intended for Zoom. Whether the reading is bounded by Zoom window focus, meeting state, or foreground status is not confirmed. Do not assume the behavior is limited to active meetings. The stated condition is that everything written is read, and nothing in the facts narrows it further.

What is not observable from the stated facts is what happens after the read. Retention, storage location, and network transmission are not confirmed. The read itself is the failure under examination. It stands independent of whatever follows it, because the boundary that should govern who receives clipboard content was already crossed at the point of the read.

The read is possible because nothing on the clipboard channel gates it. On X11, a client requests the selection and receives it. The observed behavior is a logically necessary demonstration that no enforced control prevented the Zoom client from reading writes it did not originate. If such a control existed and were enforced, the proactive read would not occur. It occurs. Whatever access control may be present is therefore ineffective for this behavior, and the presence of any such control is not confirmed.

The boundary that broke is the one between clients sharing a display. Identity is not the boundary on the X11 clipboard as this behavior shows it. The clipboard model assumes that a transfer happens when the user acts, and that assumption is treated as the control. An assumption is not an enforcement point. Trust in the clipboard channel is granted once, at connection, and is not validated per read. A client that can connect can read, and the Zoom client reads.

Why the client is built to read proactively is not confirmed. The facts support more than one interpretation, including an intended feature, a defect, or instrumentation, and no single one is established. Selecting a motive would extend beyond the facts, so the motive is not confirmed. What is confirmed is the mechanism and its effect: the clipboard is a shared resource, reads on it are not gated by user intent, and the Zoom client exercises that access on every write.

The mechanism is the X11 selection model itself. A client requests the current selection. The server returns it. No step in that exchange checks whether the requesting client is the destination the user chose. The read is authorized by connection to the display, not by user action. This is the point of failure. The control the user model depends on, a paste that directs the transfer, is not present in the exchange. It was never an enforcement point. It was an assumption about behavior treated as if it were a boundary.

The event that drives the behavior is the write. Once content is placed on the selection, it is available to be requested by any connected client. The Zoom client issues that request. The facts state the read occurs on everything written. The mechanism therefore operates without discrimination by data type, source application, or intended field. The read is programmatic and repeats on each write. This is access exercised by software at machine rate, not access granted per human decision.

Trust on this channel is granted once, at connection, and is not re-validated at the moment of access. A boundary validated one time is a boundary only for the duration of that check. After connection, presence is permission. The Zoom client is present. Nothing in the stated behavior gates the read behind meeting state, window focus, or foreground status, and whether any such gate exists is not confirmed. The observable behavior is that a write reaches a client that did not originate it and was not selected by the user.

The pattern is narrow and derived only from that mechanism. On a channel where trust is established at connection and access is not validated per read, any client that can connect can read what any client writes. The clipboard is not a private transfer between two endpoints under this model. It is a shared resource readable by every client on the display. Zoom is one such client. The property belongs to the channel, not to the vendor.

The same mechanism holds for any other actor. A clipboard manager, a second application, any process connected to the same display has the identical access the Zoom client used. The behavior described is not an exception carved out for one product. It is the default state of the selection channel. Any client positioned on it can perform the same read. Naming Zoom identifies the observed actor. It does not narrow the exposure to that actor.

What this exposes is a boundary defined by assumption instead of enforcement. The user model treats paste as the transfer control. The channel does not enforce that model. When a boundary is an assumption, connection becomes authorization and every participant is a potential reader. Everything written to the selection should be treated as readable by all connected clients, because that is what the mechanism permits. What any reader does with the data after the read is not observable from this channel and is not confirmed.

The X11 clipboard, as this behavior demonstrates, is a shared read channel. Treat it as one. Data written to it is available to every client connected to the display. The Zoom client reading proactively is the confirmation of that property, not the cause of it. A control that depends on the user choosing a destination is not enforced on this channel and therefore is not a control.

What Zoom does with the content it reads is not confirmed. Retention, storage, and transmission are not established by the facts. That absence is the risk posture, not a reassurance. You cannot verify a control you cannot see, and no control over the post-read handling of this data is stated. Operate on what is confirmed. The data left the user’s intended path at the moment of the read. Everything past that point is unverified.

Identity is the boundary. On the X11 selection, identity is not the boundary, so the boundary is not held. If a channel allows a read, that read will happen, and here it does, on every write. The position is to stop treating the X11 clipboard as a private transfer and to assume any sensitive value placed on it has been read by every connected client. The motive for the client’s design is not confirmed and does not change the requirement. The mechanism does. Build for the mechanism.