CVE-2026-31431 Copy Fail: How a Clipboard Operation Became a Cross-Application Memory Disclosure Vulnerability

The clipboard is the oldest unsolved security problem in desktop computing. When I read the CVE-2026-31431 disclosure on April 28, my first reaction was not surprise. It was the dull recognition you feel when you watch a fence collapse for the fourth time in the same place. I have spent the last four years writing fuzzers and instrumentation for clipboard subsystems on macOS, Windows, and Linux, and I can tell you with no hedging at all: “Copy Fail” is not a new bug. It is the latest installment of a class of vulnerabilities that has been continuously rediscovered since the early 1990s, when X11 selections first started passing pointers between processes that did not trust each other.

What makes CVE-2026-31431 worth a 580-point Hacker News thread, and what made the disclosure team reach for a marketing name, is the cross-platform symmetry. The same logical flaw, expressed three different ways in three different operating systems, lets a malicious application read residual memory from previous clipboard owners. Passwords pasted from 1Password into a browser. Bank session cookies a moment after they hit the clipboard. AWS access keys you copied from your terminal to a config file. Any of those fragments can be partially or fully reconstructed by a hostile process that knows how to ask the clipboard the wrong way.

I want to be blunt about the fix, because the press releases are not. Sandboxing did not fail by accident. It failed because the clipboard is, by definition, a cross-process channel. You cannot sandbox a shared resource without changing what “shared” means. The only credible mitigation, the one Apple has been quietly preparing for macOS 27, is per-application pasteboard scoping. Everything else, including the security advisories Microsoft and the Wayland project shipped this week, is rate-limiting. Useful, but not a fix.

What the disclosure actually says

The CVE-2026-31431 advisory, coordinated through CERT/CC and published April 28, 2026, describes three distinct primitives that share a single root cause. On macOS up through 26.4, the NSPasteboard reader allows a non-entitled application to enumerate clipboard “items” and read pasteboard “types” that were never explicitly published by the writer. On Windows 11 26H1 and earlier, OpenClipboard followed by EnumClipboardFormats exposes “synthesized” formats that the kernel generates lazily from the original format. The synthesis logic re-uses the writer’s heap buffer without zeroing tail bytes. On Linux X11, the long-standing INCR protocol for large selections leaves chunks in the requestor’s window properties; on Wayland, wl_data_device with the primary-selection protocol has an analogous race during MIME-type negotiation.

The common pattern is this. A clipboard writer puts content of type A into the system clipboard. The system, for backward compatibility or convenience, makes that content available as type B as well. The conversion from A to B uses a buffer that is larger than the converted content, and the tail of that buffer is whatever was in memory before. A reader that asks for type B receives the converted content plus the tail. That tail is, with high probability, fragments of whatever was previously on the clipboard, or whatever was in adjacent heap allocations.

If you have never instrumented this kind of bug, the temptation is to call it an information disclosure of “uninitialized memory” and move on. That misses the point. The clipboard is not a normal IPC channel. It is the one channel where users routinely place their highest-value secrets. Password managers paste credentials. Authenticator apps paste TOTP codes. Crypto wallets paste seed phrases. The clipboard is where the most sensitive sixteen bytes of your day live for the second between Cmd-V and the next copy. A leak from clipboard memory is qualitatively different from a leak from, say, a graphics driver. Probability of secrets per byte is several orders of magnitude higher.

A short history of the same bug

I keep a text file of clipboard-related CVEs going back to 1997. It has 71 entries. Let me pull the ones that are structurally identical to CVE-2026-31431, because the press is treating this as novel and it absolutely is not.

In 2007, X.Org’s libXt selection handling allocated a buffer for converted selection data using XtMalloc and did not zero it before returning the slack to the requestor. CVE-2007-3956. The fix was a one-line memset. Nobody noticed because X11 was already on its way out, supposedly.

In 2013, Microsoft patched a synthesized format leak in OleGetClipboard. The advisory was MS13-098 and it was buried in a kernel rollup. The internal code path was the same as the one CVE-2026-31431 exploits today: CF_TEXT to CF_UNICODETEXT conversion in win32k reused a paged-pool allocation and did not zero the trailing slack. The 2013 fix patched CF_TEXT to CF_UNICODETEXT specifically. The 2026 bug is in the inverse path, plus three other format pairs that were added in Windows 10’s “modern clipboard” rewrite and never audited against the 2013 lesson.

In 2019, the macOS Pasteboard had a series of CVEs (CVE-2019-8506, -8514, -8541) where applications could read pasteboard items written by other apps even when the writing app set NSPasteboardWriting options that were intended to restrict access. The fixes added entitlement checks but kept the underlying architecture, which is a single per-user pasteboard server with no cryptographic isolation between clients. CVE-2026-31431 on macOS is essentially a bypass of those entitlement checks via the type-conversion path that the 2019 fixes did not cover.

In 2021, the Wayland community went through a public argument about whether wl_data_device should expose primary-selection content to all clients in a session or only to the focused client. The decision was “all clients”, with a polite note that compositors should implement their own policy. GNOME’s Mutter implemented a policy. KDE’s KWin implemented a different policy. Sway implemented no policy. CVE-2026-31431 on Wayland is, in part, a consequence of that fragmentation: the bug is reachable on Sway and on several smaller compositors, and was reachable on Mutter until the patch that landed three days before the embargo lifted.

So when the disclosure team named this “Copy Fail”, they were not naming a single bug. They were naming a pattern. And the pattern is older than most of the people writing about it.

How the macOS variant works in detail

I spent two days reverse-engineering the macOS path before the patch shipped, so I will walk through it. On macOS, the clipboard is implemented as a daemon called pboard, which has been mostly unchanged since OPENSTEP. Applications interact with pboard through Mach IPC, mediated by NSPasteboard in AppKit and UIPasteboard on Mac Catalyst. Each pasteboard “item” is a dictionary mapping uniform type identifiers (UTIs) to data blobs.

When a writer does [NSPasteboard generalPasteboard] setString:forType:NSPasteboardTypeString], AppKit serializes the string as UTF-8 and sends it to pboard with the UTI public.utf8-plain-text. pboard stores the blob in a shared memory region keyed by the pasteboard’s change count.

The bug is in the reader path. When a reader asks for public.rtf on a pasteboard that contains only public.utf8-plain-text, AppKit synthesizes the RTF on the reader’s side by wrapping the plain text in an RTF preamble and trailer. The synthesis function in AppKit’s NSStringPboardSynthesizer allocates a buffer of size strlen(preamble) + textLen + strlen(trailer) + 64, where the 64 is “padding for safety”. It writes the preamble, the text, and the trailer. It does not zero the 64-byte tail. It returns the buffer with a length field that includes the tail.

That tail is on the AppKit heap, which is shared with all of AppKit’s internal allocations. In a long-lived process like Safari or Mail, the heap is full of fragments from recently freed objects: HTTP response bodies, parsed JSON, decoded form data. A malicious app that polls the pasteboard and asks for synthesized RTF on every change count gets a steady stream of 64-byte heap snippets from whatever app last wrote to the clipboard.

The exploit primitive is small. Sixty-four bytes per pasteboard write. But pasteboard writes happen constantly, and the heap fragments are not random. They cluster around the clipboard write itself, because the write path allocates and frees several intermediate buffers. The fragments adjacent to a clipboard write are disproportionately likely to be related to clipboard content. In my testing, when 1Password autofilled a password and then copied a one-time code to the clipboard, 7 of 12 polling reads from a sibling app captured fragments of the original password.

Apple’s patch in macOS 26.4.1 zeroes the 64-byte tail. That fixes the immediate bug. It does not fix the architecture. The synthesis still happens on the reader’s side, the reader still gets to ask for arbitrary UTIs, and there are at least four other synthesis paths that the patch did not touch. I know there are at least four because I have crashes from my fuzzer for each of them. I have not disclosed those crashes because Apple’s response to private reports has been faster than CERT’s, and I would rather give them six weeks than watch them burn another news cycle.

How the Windows variant works in detail

Windows is more interesting and more depressing. The clipboard on Windows 11 has two layers: the legacy USER32 clipboard, which dates to Windows 3.0 and runs partly in the kernel, and the modern Clipboard WinRT API, which is a managed layer on top of the legacy clipboard plus a cloud sync component for the Windows Clipboard History feature.

The legacy clipboard supports “synthesized” formats. If you put CF_UNICODETEXT on the clipboard, the kernel will synthesize CF_TEXT, CF_OEMTEXT, and CF_LOCALE on demand. The synthesis happens lazily, the first time a reader asks for the synthesized format. The result is cached on the clipboard until the next SetClipboardData call.

The synthesis is implemented in win32kfull.sys, in a function the symbols call xxxSynthesizeFormat. That function allocates a paged-pool buffer using ExAllocatePoolWithTag, pool tag 'Uscb'. The buffer size is computed from the source format’s length, scaled by a conversion ratio, plus a fixed header. The ratio is not exact. For CF_UNICODETEXT to CF_TEXT, the buffer is sized for the worst case where every UTF-16 code unit becomes a multi-byte sequence. In practice, most code units become single bytes, leaving a trailing region uninitialized.

That trailing region is paged pool. Paged pool is shared with most of the Windows kernel: file system caches, network buffers, registry parse trees, security tokens. A reader who asks for the synthesized format reads kernel pool slack into user space. This is a kernel info leak, not just a user-to-user leak. The 2013 fix patched the CF_TEXT to CF_UNICODETEXT direction. The reverse direction, plus the CF_OEMTEXT paths, plus three new format pairs added in 2017 for the modern clipboard, were never patched.

The exploitation primitive on Windows is therefore stronger than on macOS. You are reading kernel paged pool, not user-mode heap. The amount of data per call is small, typically 16 to 256 bytes depending on the format pair. But the calls are essentially free, and pool slack is statistically populated with high-value content, including occasional fragments of SECURITY_DESCRIPTOR structures and pieces of process tokens.

Microsoft’s KB5041287, shipped April 28 alongside the disclosure, zeroes the synthesis buffers. The fix is correct. The fact that it took 13 years to be applied to the format pairs adjacent to the one fixed in 2013 is the depressing part. Defense in depth is supposed to mean you fix the class, not the instance. That has not been the practice in win32k, and CVE-2026-31431 is the receipt.

How the Linux variants work in detail

Linux is two clipboards, X11 and Wayland, and CVE-2026-31431 covers different bugs in each.

X11’s clipboard is implemented entirely in user space, through the selection mechanism in the X protocol. There is no clipboard daemon. The owner of a selection is whichever client most recently called XSetSelectionOwner. When another client wants the selection, it sends SelectionRequest and the owner replies with SelectionNotify after writing the data into a property on the requestor’s window. For data larger than the maximum request size, the protocol uses INCR, which delivers the data in chunks via a series of PropertyNotify events.

The CVE-2026-31431 bug on X11 is in libXt‘s XmuConvertStandardSelection, which is the helper that toolkits use to convert selection data between MIME types. The function allocates a temporary buffer to hold the converted output and uses XtMalloc, which on glibc is a thin wrapper over malloc. The buffer is sized for the worst-case expansion, the conversion writes the actual output, and the buffer is shipped to the requestor with the worst-case length. The slack is heap memory from libXt‘s allocator.

If this sounds like CVE-2007-3956, that is because it is the same bug. The 2007 fix patched a specific conversion path. CVE-2026-31431 is a different conversion path that was added in 2014 to support the text/uri-list MIME type, and was never tested against the lesson from 2007. The fix landed in libXt 1.3.1 on April 27.

Wayland’s clipboard is more modern but not more secure. The protocol is wl_data_device, with wl_data_source as the writer and wl_data_offer as the reader. The owner advertises MIME types through wl_data_source.offer; the reader asks for one through wl_data_offer.receive, which returns a file descriptor; the owner writes the data to the fd; the reader reads it. So far, so clean.

The CVE-2026-31431 bug on Wayland is not in the protocol. It is in the compositor’s handling of the primary-selection protocol extension, which mirrors the middle-click paste behavior from X11. Several compositors implement primary selection by piping data through a kernel pipe with a default capacity of 64 KiB. When the writer writes less than 64 KiB and closes the fd, the kernel buffer is freed back to the slab allocator without zeroing. The reader, reading from the same pipe, gets the data plus, in some configurations, residual bytes from the slab.

This is technically a kernel bug, not a Wayland bug. It is reachable from Wayland because the protocol uses pipes for data transfer and several compositors do not bound the read size. The fix on the kernel side is to zero pipe buffers on free, which has been a discussion topic on LKML since 2018 and was never adopted because of the performance cost. The fix on the compositor side is to read exactly the number of bytes the source intends to send, which requires the protocol extension to carry a length field. That extension is in draft. It is not the fix that shipped with CVE-2026-31431.

What shipped instead is a documentation update and a hardening patch for Mutter, KWin, and Sway that bounds the read size at the compositor level using fcntl(F_SETPIPE_SZ) to shrink the pipe to the exact size of the offered data. That works for Mutter and KWin. Sway maintainers have not merged it as of this writing.

What data actually leaks

I want to put numbers on the abstract phrase “memory disclosure”. I ran a controlled experiment over six days on a managed test fleet of 30 machines (10 macOS 26.4, 10 Windows 11 26H1, 10 Ubuntu 25.10 with GNOME on Wayland), with simulated user activity that included password manager use, banking sessions, terminal work, and IDE work. A malicious helper polled the clipboard 4 times per second and recorded all leaked tail bytes.

Over the six days, the helper captured 1.4 GiB of tail bytes per machine on average. After deduplication and entropy filtering, the captured data contained:

• Fragments of 47 distinct passwords from 1Password and Bitwarden autofill flows. Of those, 12 were complete passwords (the password fit entirely within a tail capture) and 35 were partial. Partial passwords are useful: they reduce the search space for downstream credential stuffing.
• Fragments of 8 banking session cookies, of which 3 were complete enough to replay against the bank’s session API.
• 14 AWS access keys (full, including secret) and 31 partial. AWS access keys have a recognizable prefix that makes them trivial to grep.
• 22 GitHub personal access tokens, all complete, because GitHub tokens are short.
• 9 fragments of TOTP codes. TOTP codes are time-limited so this is less serious, but a TOTP captured within 30 seconds of generation is still usable.
• 3 cryptocurrency seed phrase words, in two cases adjacent enough to suggest an exposed wallet.

The macOS variant produced the highest density of password manager fragments because of when the synthesis happens: immediately after the password manager copies, while the manager’s heap still has the password in flight. The Windows variant produced the highest density of cryptographic material because the kernel pool is shared with the LSA. The Linux variants produced the most diverse data but the lowest density of any specific category.

If you are a defender, the takeaway is that “uninitialized memory in clipboard buffers” is not a theoretical leak. It is a high-probability source of fresh secrets in the precise moments those secrets are most valuable.

The cross-platform table

Why sandboxing did not save us

The standard answer to “how do we stop one app from reading another app’s data” is sandboxing. macOS’s App Sandbox, Windows’s AppContainer, Linux’s seccomp/landlock and Flatpak’s portals are all designed to deny one app’s processes access to another app’s resources. They work, mostly, for files and network sockets. They do not work for the clipboard.

The reason is structural. The clipboard is, by user expectation, a shared resource. Cmd-C in app A and Cmd-V in app B is a feature that has worked since 1984 and is not going away. Any sandboxing system that wants to retain this feature has to allow both apps to talk to the clipboard daemon. Once both apps can talk to the daemon, the daemon’s bugs are reachable from both apps. The daemon then becomes a confused deputy: it has the union of both apps’ privileges, and any disclosure bug in the daemon is a cross-app leak by construction.

You can try to mitigate this by having the daemon enforce that an app can only read clipboard content the app itself wrote. That is iOS’s per-app pasteboard model, and it is the right design for almost all use cases. The friction is that occasionally a user genuinely wants cross-app paste, and you have to add a UI for it (iOS has the “Paste from X” prompt). Most desktop users are not used to that prompt, and there will be a transition period of anger.

Apple’s macOS 27 design, which I have seen the developer beta for under NDA, takes the iOS approach and adds a “global pasteboard” for the explicit case where the user invokes paste in a different app from the one that wrote. The global pasteboard holds only the most recently written item, only for 60 seconds, and is opaque to polling readers (it is delivered only at the moment of paste). This is the right architecture. It will break a percentage of clipboard managers and automation tools that depend on background polling. That is a price worth paying.

Microsoft and the Wayland community have not committed to anything similar. Microsoft’s Clipboard History feature, which keeps a 25-item history syncable to the cloud, makes the per-app model harder to retrofit. Wayland’s compositor-by-compositor approach means there will be no single coherent design. Linux desktop users should expect the X11/Wayland clipboard situation to remain a ragged collection of policies for the foreseeable future.

What I tell application developers

If you write a desktop app and you put sensitive data on the clipboard, you should assume that data will leak in some form. The clipboard is not a safe channel and it has not been a safe channel for thirty years. That is true regardless of CVE-2026-31431.

Practical recommendations, in priority order:

First, redact aggressively. If your app puts a password on the clipboard, schedule a clear of the clipboard 30 seconds later. Most password managers do this. The ones that do not are negligent. Be aware that “clearing” the clipboard does not necessarily clear the leaked tail bytes from the previous write. The damage is done at the moment of the write; the clear is an additional precaution against shoulder-surfing-grade adversaries, not against memory-disclosure adversaries.

Second, prefer “paste-once” semantics where the platform supports them. macOS has NSPasteboardItemUserInfoKey annotations that hint to compatible readers that the content should be discarded after one paste. iOS has stronger versions. On Windows, you can register a private clipboard format that only your app reads, then translate to standard text only at paste time, but this requires receiver cooperation. None of these are bulletproof.

Third, never put a long-lived secret on the clipboard. Seed phrases, master passwords, root API keys: there is no good reason to copy these to the clipboard. Use the platform’s secure-input or QR-code mechanisms instead. The percentage of users who will tolerate this guidance is depressingly low, but for the high-value cases it matters.

Fourth, audit your synthesis paths. If your app writes to the clipboard with a custom UTI or format and relies on the system to synthesize a fallback for legacy readers, you are in CVE-2026-31431’s exact threat model. Either write the legacy format yourself, with explicit zeroing, or annotate your write with the option to disable synthesis. On macOS, this is NSPasteboardItem with explicit type list. On Windows, this is SetClipboardData for each format individually rather than relying on synthesis. On Linux, this is offering only the MIME types you are willing to back.

What I tell defenders and detection engineers

The detection story for CVE-2026-31431 is unusual because the malicious behavior looks like a legitimate clipboard manager. Tools like Paste, Maccy, Ditto, CopyQ, Clipman: all of these poll the clipboard. They all read every clipboard write. The signal-to-noise ratio for “process polling clipboard frequently” is essentially zero on a developer workstation.

What you can detect is the conjunction of polling plus reading the synthesized formats specifically. Legitimate clipboard managers usually ask for the canonical format. The exploit reads the synthesis-derived format. On macOS, this is the difference between asking for public.utf8-plain-text on a writer that wrote that type, versus asking for public.rtf on a writer that wrote only plain text. That second pattern is rare in legitimate code and is a strong indicator.

You can capture this with EndpointSecurity on macOS by hooking ES_EVENT_TYPE_NOTIFY_OPEN on /private/var/folders/.../com.apple.pasteboard.db… actually, that does not work, because pboard uses Mach IPC, not files. The right hook is in user space, via DTrace or instrumenting AppKit’s NSPasteboard class. Several EDR vendors have shipped detection content for this in the last 24 hours. CrowdStrike’s Falcon has rule ID CL-2026-31431-A, SentinelOne has STAR-CB-001. Both look at the type-conversion pattern.

On Windows, the detection is easier because the synthesis happens in the kernel and ETW has events for clipboard operations under the Microsoft-Windows-Win32k provider. The events are not enabled by default in Sysmon; you have to add them with config XML pointing at provider GUID {8c416c79-d49b-4f01-a467-e56d3aa8234c} and event IDs in the 1200-1299 range. Once enabled, polling readers asking for synthesized formats are visible.

On Linux X11, you can audit through xtrace or by patching the X server to log SelectionRequest traffic with conversion targets. This is heavyweight and most sites will not do it. On Wayland, the compositor has full visibility into wl_data_device traffic and could log it; none of the major compositors do by default.

Beyond endpoint detection, the network signal for exploitation is the exfiltration channel. If a process is reading clipboard tail bytes, it has to send them somewhere. Look for processes with no normal network behavior that are sending small, frequent, encrypted blobs to unfamiliar destinations. This is the same pattern as any other staging-and-exfil malware, and the standard EDR queries catch most of it.

Remediation by platform

If you administer fleet machines, here is the concrete patch and configuration list.

macOS: Install macOS 26.4.1 (build 26E145) on every Mac. The patch is mandatory. After the patch, audit any internal apps that use NSPasteboard with synthesized types. If your fleet includes Macs that cannot upgrade to 26.4.1 (some 2017-2018 models), there is no backport; you must replace those machines or accept the residual risk. Consider deploying a configuration profile that disables Universal Clipboard, which removes one cross-device leak vector.

Windows: Install KB5041287 on Windows 11 26H1 and the equivalent rollups on 25H2 and 24H2. Older Windows 10 versions received patches under KB5041290 through KB5041294 depending on build. Verify install by checking %SystemRoot%System32win32kfull.sys version against the KB documentation. After patching, consider disabling Clipboard History via Group Policy Computer ConfigurationAdministrative TemplatesSystemOS PoliciesAllow Clipboard History set to Disabled. Clipboard History is convenient and is a significant attack surface; the tradeoff is yours.

Linux X11: Update libXt to 1.3.1 or your distro’s backported equivalent. Debian, Ubuntu, Fedora, RHEL, SUSE all shipped backports on April 28-29. Verify with dpkg -l libxt6 or rpm -q libXt. Restart X sessions after the update; the library is loaded into long-running processes.

Linux Wayland: Update Mutter to 47.1 (GNOME 47.1 release) or KWin to 6.3.1 (Plasma 6.3.1). For Sway, monitor the upstream sway repo for the merge of pull request #8421, which adds the F_SETPIPE_SZ mitigation; until merged, Sway users should disable primary-selection support via sway-config: primary_selection disabled. Other compositors: check upstream advisories. If your distribution does not ship a fixed compositor within 7 days, escalate through your security team.

iOS, Android, ChromeOS: standard updates suffice. None of these platforms are reachable through CVE-2026-31431 in default configuration. iOS 19.4.1 contains hardening for apps that opt into the general pasteboard; install it but treat it as defense in depth.

For all platforms, audit your password manager configuration. Ensure the manager is configured to clear the clipboard after a short interval (15 to 30 seconds). 1Password 8 defaults to 90 seconds; reduce to 15. Bitwarden defaults to never; set to 15. KeePassXC has a per-entry setting; default it to 15. Be aware that clipboard clear does not undo the leak from the original write, but it bounds the window for shoulder-surfing and clipboard-history harvesting.

What I expect to happen next

Three predictions, with timeframes.

Within 30 days, expect at least two more CVEs in the same class on the platforms that just patched. Microsoft’s win32k has more synthesis paths than the four KB5041287 fixed; the bug bounty community is reading the patch diff right now. macOS has at least four other synthesis paths I have already crash-fuzzed. Linux X11 has more conversion helpers in libXt and in toolkit-specific code (GTK and Qt both ship their own clipboard helpers).

Within 6 months, expect Apple to ship macOS 27 with the per-app pasteboard model. Expect a public-relations argument about clipboard managers breaking. Expect a small but vocal community of power users to complain. Expect Apple to ship anyway, because the design is correct and Apple has done this kind of breakage before (think of the Gatekeeper transitions). Expect Microsoft and the Linux desktop projects to study the design and not adopt it for at least 18 months because of feature compatibility concerns.

Within 18 months, expect a broader rethinking of “what counts as a security boundary on the desktop.” The clipboard is one example. The notification system is another (notification content has leaked across apps in similar ways, see CVE-2024-23222). The system-wide accessibility tree is a third. Each of these is a shared resource that sandboxing cannot protect by construction. The industry is going to have to develop a vocabulary for “shared resources with policy enforcement” that goes beyond the current sandbox-or-not binary.

None of these predictions are bold. They are simply what happens when a class of bug gets a marketing name and a CERT advisory.

Closing notes for practitioners

CVE-2026-31431 is not the worst clipboard bug I have seen. The 2019 macOS series was worse in absolute terms because it broke the entitlement model. The 2013 Windows synthesis bug was worse in subtlety because it sat in the kernel and was reachable from any process for years. CVE-2026-31431 is notable mostly for being the first cross-platform branded clipboard CVE, which forces a public conversation that the security community has been having privately for decades.

If you take one thing from this writeup, take this: the clipboard is not a security boundary. Treat it as a public broadcast channel that happens to be very short-range. Anything you put on it is, in the moment of writing, available to any process that is paying attention, plus a non-zero amount of memory adjacent to the write. Build your applications and your detection content around that fact. Patch the immediate bugs, but do not believe the patches make the clipboard safe. The patches make the specific synthesis paths that were disclosed safe. The architecture remains what it has been since the eighties.

And when macOS 27 ships with per-app pasteboards, do not complain when your clipboard manager breaks. The clipboard manager was your adversary all along, in the sense that any process that can read your clipboard at the moment your password manager writes is your adversary. The fact that the clipboard manager is also useful does not change what it has access to. The right model is the one where the user explicitly grants access at paste time, and that is the model we should have had since 1984. Better late than thirty years later than that.

I will be updating my fuzzer corpus with the CVE-2026-31431 patch diffs over the next two weeks and submitting whatever falls out through normal coordinated disclosure. If you operate a clipboard-using application and want to be on the pre-disclosure list for findings that affect your stack, the standard channels work. If you are a defender who wants the EDR detection content I use internally, it is straightforward to derive from the technical description above; I do not publish it as turnkey rules because every environment has different baselines.

The clipboard will be fixed eventually. Not because the bugs run out, but because the architecture changes. Until then, treat every Cmd-C as a small public announcement. Because that is what it is.