Why This Research Exists

When Theori published their disclosure of CopyFail on April 29, 2026, the writeup immediately stood out. A 732-byte, 10-line Python script that achieves reliable local privilege escalation on every major Linux distribution, across every architecture, with no race condition. That kind of claim demands independent verification.

This post documents my reproduction of the CopyFail primitive on a live system, my analysis of the three kernel commits that created the vulnerability, and what makes this bug structurally different from its predecessors. All credit for the original discovery belongs to Taeyang Lee and the Theori team.

The Three Commits That Broke Everything

CopyFail isn’t a single mistake. It’s the convergence of three individually reasonable kernel changes spanning six years.

The first was the addition of authencesn in 2011, an AEAD wrapper for IPsec Extended Sequence Numbers. The second was the introduction of AF_ALG AEAD socket support in 2015, which gave userspace access to kernel cryptographic operations. The third, and the one that created the vulnerability, was commit 72548b093ee3 in 2017. That commit added an in-place optimization in algif_aead.c, setting req->src = req->dst to avoid allocating separate input and output buffers.

None of these were dangerous on their own. The 2017 optimization was a straightforward performance improvement. It was reviewed, merged, and forgotten for nine years.

How the Primitive Works

The attack has four stages, and the elegance is in how each one is completely ordinary on its own.

Socket setup. An unprivileged user opens an AF_ALG socket and binds it to authencesn(hmac(sha256),cbc(aes)). No special permissions are required. No capabilities, no group membership. The kernel hands this to anyone who asks.

Page cache injection via splice(). The attacker uses splice() to feed the page cache pages of a target file into the crypto socket’s input scatterlist. Because splice() delivers zero-copy references, the socket now holds direct pointers to the kernel’s cached pages of that file. This is the key insight Theori identified: splice() can deliver page cache references of read-only files to crypto TX scatterlists.

The in-place corruption. Due to the 2017 optimization, the kernel sets req->src = req->dst. During AEAD decryption setup, sg_chain() links the source pages (which are the page cache pages) into the output scatterlist. Source and destination are now the same physical memory.

The write. The authencesn algorithm performs Extended Sequence Number rearrangement. The function crypto_authenc_esn_decrypt() writes seqno_lo (4 bytes from the attacker-controlled AAD) directly into the destination buffer. Because destination equals source and the source contains page cache references, this writes into the kernel’s cached copy of the target file.

The AEAD tag verification fails afterward because the data is garbage. But it doesn’t matter. The ESN rearrangement fires before tag verification. The corruption is already done.

What the Attacker Controls

The target file is controlled through splice(), which accepts any file descriptor with read permission. The offset within the file is controlled through the splice file offset combined with the CRYPTLEN parameter. The 4-byte value written is controlled through AAD bytes 4 through 7 (the seqno_lo field).

That’s a fully controlled, deterministic, arbitrary 4-byte write to any readable file’s page cache. From an unprivileged user.

Reproducing the Primitive

I reproduced the primitive on Kali Linux (kernel 6.18.12, ARM64) by targeting a test file filled with 0x41 bytes and writing 0xDEADBEEF at offset 16.

[+] before: 41414141 ('AAAA')
[+] after : deadbeef
    value : 0xDEADBEEF — CONTROLLED WRITE CONFIRMED

The write is deterministic. I ran it 20 times with the same result every time. No race condition, no timing sensitivity, no heap spray. The primitive either works or it doesn’t, and on a vulnerable kernel, it works.

The on-disk file is never modified. Only the kernel’s page cache copy is corrupted. This means standard disk-based integrity monitoring (AIDE, OSSEC, Tripwire) sees nothing. No inotify event is generated. No audit log entry for a file write appears. The corruption exists only in memory.

Why This Is Structurally Different from Dirty Cow and Dirty Pipe

The comparison to Dirty Cow (CVE-2016-5195) and Dirty Pipe (CVE-2022-0847) is inevitable, but the differences are significant.

Dirty Cow required a race condition. You had to win a race between two threads to corrupt a page table entry. This made exploitation probabilistic and sometimes unreliable, especially under load.

Dirty Pipe was more deterministic but still required specific pipe buffer manipulation and had architectural limitations that affected cross-platform portability.

CopyFail requires no race condition at all. The corruption is a direct consequence of the algorithm’s execution path. It works identically on x86_64, ARM64, and every other architecture the kernel supports. The original PoC from Theori is 732 bytes and 10 lines of Python.

The invisibility aspect is also new. Both Dirty Cow and Dirty Pipe could be detected through careful disk forensics. CopyFail corrupts only the page cache. The on-disk file remains pristine. Detection requires live memory forensics, comparing in-memory binary images against on-disk hashes while the system is running.

The Escalation Path

The 4-byte page cache write primitive is the interesting part. The escalation from there to root is straightforward and follows a well-understood pattern: corrupt the page cache of a setuid binary to alter its control flow, then execute it.

I confirmed this path works on my lab system. I’m not publishing the exploit code or the specific binary offsets because the primitive demonstration is the technically interesting contribution, and anyone who understands the primitive can work out the rest.

The AI Discovery Angle

One aspect of this CVE that deserves attention is how it was found.

Taeyang Lee at Theori identified the AF_ALG plus splice interaction as a promising attack surface, then fed the hypothesis to Xint Code, Theori’s AI-driven security scanner. The scan completed in approximately one hour and flagged CopyFail as its highest-severity finding.

Nine years of human code review, kernel security audits, and fuzzing campaigns missed this. An AI scanner found it in sixty minutes.

This doesn’t mean AI replaced the researcher. The human provided the creative hypothesis, the intuition that splice’s zero-copy semantics might interact dangerously with crypto subsystem buffer reuse. The AI performed the exhaustive cross-subsystem analysis that confirmed it. Neither would have found this alone.

For those of us in vulnerability research, this is worth paying attention to. The bugs that survive a decade of human review are exactly the kind that benefit from AI-assisted analysis: cross-subsystem interactions where the dangerous state emerges from the combination of components that were each reviewed in isolation.

Affected Systems and Mitigation

Any Linux kernel from 4.14 onward with CONFIG_CRYPTO_USER_API_AEAD enabled is vulnerable. This is the default on virtually all major distributions.

The upstream fix (mainline commit a664bf3d603d, April 1, 2026) reverts algif_aead.c to out-of-place operation. Source and destination are separate scatterlists. Page cache pages never appear in the writable destination.

If you can’t patch immediately, disabling the vulnerable module is the fastest mitigation:

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead 2>/dev/null

Be aware this may break applications using kernel crypto acceleration, including cryptsetup, Firefox, and IPsec implementations.

For container environments, deploying seccomp policies that block AF_ALG socket creation is an effective hardening measure, since container isolation alone does not protect against kernel-level page cache corruption.

Detection

Standard disk forensics cannot detect exploitation. The on-disk file is never modified.

What works is runtime monitoring. Falco or Sysdig rules can detect suspicious AF_ALG SEQPACKET socket creation from unexpected processes. Live memory forensics can compare in-memory binary images against on-disk hashes. Monitoring for unexpected privilege transitions following kernel crypto syscalls is another viable detection path.

What doesn’t work is anything that relies on the file system. Hash checks, inotify, fanotify, and VFS audit logs all see a clean disk.

Timeline

Conclusion

CopyFail is a reminder that the most dangerous vulnerabilities aren’t always the most complex. Three reasonable commits, spanning six years, created a primitive that gives any unprivileged user a deterministic 4-byte write to the page cache of any readable file. The fix is a one-line change reverting to out-of-place operation.

What makes it worth studying is the structural lesson. Each component was safe in isolation. The danger emerged from their interaction, specifically from the assumption that buffer reuse is safe when the buffers might contain zero-copy references to shared kernel data structures. That assumption was invisible to anyone reviewing a single subsystem.

Patch your systems. If you run containers, deploy the seccomp mitigation. And if you’re in vulnerability research, spend some time thinking about what other zero-copy plus in-place-operation interactions might be hiding in the kernel. CopyFail probably isn’t the last bug in this class.

Acknowledgments

All credit for the original discovery goes to Taeyang Lee and the team at Theori. Their disclosure and the Xint Code AI-assisted scanning approach represent an important development in how vulnerabilities are found. This post is an independent reproduction and analysis, not an original finding.

References

Theori/Xint, “Copy Fail: 732 Bytes to Root on Every Major Linux Distribution.” Help Net Security, “Nine-year-old Linux kernel flaw enables reliable local privilege escalation.” Tenable, “Copy Fail CVE-2026-31431 FAQ.” The Register, “Linux cryptographic code flaw offers fast route to root.” CERT-EU, Security Advisory 2026-005. Sysdig, “CVE-2026-31431 Copy Fail analysis.”

This research was conducted in an isolated lab environment. All testing was performed on systems owned and operated by the researcher.

Abstract

This paper presents an analysis of CVE-2026-23669, a heap buffer overflow in Microsoft’s RPC runtime library (rpcrt4.dll). Although the vulnerability is publicly categorized under the Print Spooler umbrella, our research shows the underlying bug sits in the endpoint mapper (epmap) client code within the RPC runtime itself. The Print Spooler serves as an attack vector, but the flaw is not exclusive to it. Any Windows service that performs remote endpoint resolution through rpcrt4.dll could, in principle, be affected.

Through binary diffing, Ghidra decompilation, and controlled testing on a pre-patch Windows 11 system, we confirmed a reliable remote denial-of-service condition and identified a privilege escalation path from any domain user to domain administrator via NTLM coercion. We also examine why direct remote code execution from this primitive alone is effectively blocked by several overlapping mitigations in modern Windows, offering a practical look at how Microsoft’s defense-in-depth strategy holds up in the real world.

1. Introduction

Microsoft’s March 2026 Patch Tuesday addressed 67 vulnerabilities, among them CVE-2026-23669, a heap overflow in the Windows Print Spooler rated at CVSS 8.8. The vulnerability was originally identified by security researcher Andrea Pierini, who noted publicly that the bug is not confined to the print spooler but resides in the endpoint mapper protocol within rpcrt4.dll.

That observation turned out to be the key to understanding this vulnerability. Unlike PrintNightmare and its successors, CVE-2026-23669 does not exploit a flaw in spooler-specific logic. Instead, it targets a fundamental weakness in how the RPC runtime resolves remote endpoints, a mechanism that underpins dozens of Windows services beyond printing.

Our research spanned 18 days and involved binary diffing of six patched DLLs, full Ghidra decompilation of rpcrt4.dll, ntdll.dll, and spoolsv.exe, combined with controlled exploitation in an isolated lab environment. What follows is a detailed account of our findings, including what works, what doesn’t, and why.

2. Vulnerability Mechanics

2.1 The Endpoint Mapper Protocol

When a Windows service needs to reach a remote RPC endpoint, it queries the target machine’s Endpoint Mapper on port 135 using the ept_map RPC call (opnum 3). The response carries an array of “towers”, binary structures that describe available network endpoints in terms of protocol, address, and port.

Inside rpcrt4.dll, the relevant data structure is what we call the EPM Registration Context. It is a 0x388-byte heap object. At offset +0x2D8, it holds a fixed 4-slot pointer array (32 bytes) meant for up to 4 tower pointers. The count of active entries lives at offset +0x2F8.

2.2 The Missing Correlation Check

The ept_map response is a conformant varying array, defined in the IDL with [size_is(max_towers)] constraining the maximum number of entries returned. On the wire, this translates to a MaxCount field in the NDR encoding, which should be validated against the caller’s max_towers parameter, hardcoded to 4.

Our analysis of the client-side NDR unmarshaling code reveals that this correlation validation is skipped because the correlation descriptor pointer is NULL. This is a compile-time artifact. The MIDL-generated stub for ept_map does not emit correlation validation metadata on the client-side path.

The consequence is straightforward. A malicious EPM server can return any number of towers. NDR writes all of the corresponding tower pointers into the 4-slot array without complaint, overflowing into adjacent fields of the EPM context structure.

2.3 Triggering the Overflow

The attack hinges on getting the target’s spooler to issue an EPM query against a machine the attacker controls. This is accomplished through the notification callback mechanism.

First, the attacker authenticates to the target’s \pipe\spoolss using RPC_C_AUTHN_LEVEL_CONNECT, the lowest authentication level, available to any domain user. Then, the attacker invokes RpcRemoteFindFirstPrinterChangeNotificationEx (opnum 65) with a callback address pointing to the attacker’s host. The target’s win32spl.dll then attempts to resolve the remote spoolss endpoint by querying the attacker’s IP on port 135. At that point, the attacker’s rogue EPM responds with more than 4 towers.

Because the encoding is valid NDR, with MaxCount and ActualCount simply reflecting the actual number of towers, all client-side validation passes. The overflow is immediate and deterministic.

2.4 Overflow Geometry

With 11 towers in the response, the overflow map looks like this:

Each overflow slot receives a heap pointer to the corresponding tower data allocation, a valid, attacker-influenced heap block.

3. Self-Terminating Cleanup

One of the more interesting aspects of this vulnerability is the behavior of the cleanup loop that runs after the overflow.

Once NdrClientCall3 returns, the tower processing function iterates over the pointer array, freeing each tower and zeroing the slot. But here’s the catch. At iteration 4, the loop reaches the count field itself (offset +0x2F8). The 8-byte zero-write at that location sets the count to 0, and the loop terminates on the next check.

This self-termination is deterministic. Slots 5 and beyond are never touched by the cleanup. They persist as valid heap pointers to attacker-controlled tower data until the object is eventually destroyed.

In practice, the cleanup still crashes roughly 80% of the time. The count field temporarily holds the low 32 bits of tower[4]’s heap pointer, which is a large value. The loop tries to free non-heap addresses at the overflow offsets before it gets a chance to zero the count, and the result is a STATUS_HEAP_CORRUPTION (0xc0000374) crash.

4. Patch Analysis

4.1 Binary Diff Results

We diffed all six DLLs modified by KB5079473:

The 728KB byte diff in rpcrt4.dll initially had us wondering whether a second vulnerability was hiding in the update. After exhaustive analysis, comparing API call counts, searching for new validation functions, and examining every change that wasn’t clearly compiler noise, we’re confident it’s all recompilation artifacts. Only the 80-byte ShouldCapEndpointArray function constitutes a security fix.

4.2 Defense in Depth

Microsoft’s patch is notably thorough, employing three independent layers.

Layer 1, Authentication Gate (spoolsv.exe): A new function, VerifyRpcValidSecurityLevelForWinspool, is added to the notification handler opnums (58, 59, 60, 65, 66). It rejects connections made at RPC_C_AUTHN_LEVEL_CONNECT, now requiring at least RPC_C_AUTHN_LEVEL_PKT_PRIVACY. This cuts off low-privilege users from the vulnerable code path.

Layer 2, Array Bounds Cap (rpcrt4.dll): ShouldCapEndpointArray is called before the cleanup loop, capping the iteration count to 4 regardless of whatever value sits at +0x2F8. This defuses the cleanup overflow even if the authentication gate is somehow bypassed.

Layer 3, Attack Surface Reduction (win32spl.dll): Point-and-Print functions are removed entirely, closing off the remote printer driver installation vector.

5. Exploitation Assessment

5.1 Denial of Service

The DoS condition is straightforward. With an honest NDR encoding containing more than 4 towers, the spooler crashes shortly after receiving the rogue EPM response. The crash is logged as Event 7031 (Service Control Manager) and generates WER crash reports. The spooler auto-restarts within about 15 seconds, meaning the attack can be repeated indefinitely.

5.2 Remote Code Execution, Why It Doesn’t Work

We put considerable effort into trying to convert the heap overflow into remote code execution. Over 16 iterations of binary analysis and live testing, we systematically ruled out every direct path. The short version is that modern Windows mitigations work.

Control Flow Guard (CFG) is enabled on spoolsv.exe. Any attempt to call a heap address as a function pointer is caught by __guard_dispatch_icall. We scanned thousands of function entry points across loaded DLLs looking for CFG-valid stack pivot gadgets and came up empty.

LFH Bucket Separation puts the EPM context (0x388 bytes) and Connection objects (0x350 bytes) into different Low Fragmentation Heap buckets. You can’t corrupt into a neighboring object’s vtable through adjacent heap writes.

Object Lifecycle is another blocker. The corrupted EPM context is a transient client-side object. It’s allocated for the ept_map call and destroyed immediately after. There’s no window to reference the corrupted state from a separate code path.

Synchronous Execution seals it off further. Network EPM calls go through NdrClientCall3, which is synchronous. The async notification callback at +0x338, which would have been the most promising dispatch target for the corrupted fields, never fires for non-ncalrpc transports.

We did identify one interesting CFG bypass candidate in ntdll.dll that performs an unguarded indirect call. But it’s only reachable during exception dispatch, not from an arbitrary vtable call, creating a dependency loop that doesn’t resolve.

The takeaway is that no single one of these mitigations is bulletproof on its own. Together, they close off every practical RCE path we could identify from this primitive.

5.3 Privilege Escalation via NTLM Coercion

While direct RCE is off the table, the vulnerability does enable a meaningful escalation path.

The pre-patch authentication gap on the notification opnums allows any domain user to force the Print Spooler, running as SYSTEM, to initiate an outbound SMB connection to an attacker-controlled host. That connection authenticates as the machine account, yielding an NTLM coercion primitive.

This is the same class of technique as the well-known PrinterBug (MS-RPRN abuse). When combined with standard NTLM relay methods against Active Directory services, it can lead to full domain compromise in environments that haven’t hardened their relay defenses. The specific fix in KB5079473 closes this gate by enforcing PKT_PRIVACY on the affected opnums.

We are intentionally omitting the specific relay chains here, as they are well-documented elsewhere and adding them to a CVE-specific writeup would lower the barrier without adding meaningful defensive insight.

6. Comparison with PrintNightmare

CVE-2026-23669 is often mentioned alongside PrintNightmare (CVE-2021-1675 / CVE-2021-34527), but the two are fundamentally different vulnerabilities.

Our testing on Windows 11 24H2 (Build 26200) also confirmed that traditional PrintNightmare exploitation is independently blocked on recent builds through UNC path validation in RpcAddPrinterDriverEx. Several established implementations all returned ERROR_INVALID_PARAMETER on this build, regardless of CVE-2026-23669’s patch status.

7. Detection and Mitigation

7.1 Detection Indicators

Windows Event Logs:

Event 7031 (System) with the message “The Print Spooler service terminated unexpectedly” is the primary indicator. Repeated spooler crashes with snmpapi.dll or ntdll.dll referenced in WER reports should also raise flags.

Network Indicators:

Look for outbound connections from spoolsv.exe to unexpected external hosts on port 135. Also watch for ept_map responses where MaxCount exceeds 4 in the conformant array header.

WER Crash Signatures:

The most common crash signature is exception code 0xc0000374 (STATUS_HEAP_CORRUPTION) with faulting modules snmpapi.dll or ntdll.dll in the crash reports.

7.2 Mitigation

The primary recommendation is to apply KB5079473, the March 2026 cumulative update.

If patching is not immediately possible, the following registry change disables remote RPC endpoint registration for the spooler, preventing the notification callback from triggering the vulnerable EPM query:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Print" ^
    /v RegisterSpoolerRemoteRpcEndPoint /t REG_DWORD /d 2 /f

8. Responsible Disclosure Timeline

9. Conclusion

CVE-2026-23669 is a significant vulnerability in the Windows RPC runtime that extends beyond the Print Spooler. The heap overflow in the endpoint mapper client code is deterministic and remotely triggerable by any authenticated domain user, providing both a denial-of-service condition and a privilege escalation primitive through NTLM coercion.

Modern Windows mitigations, including CFG, LFH bucket isolation, and synchronous object lifecycles, collectively prevent direct remote code execution from this primitive alone. But the NTLM coercion path demonstrates that real-world impact can still reach domain compromise when combined with standard Active Directory attack techniques.

Microsoft’s patch is well-engineered, with three independent layers of defense that each address a different aspect of the attack chain. It’s a good example of how patching done right doesn’t just fix a bug but closes off entire categories of follow-on abuse.

More broadly, this vulnerability reinforces a pattern we see again and again in modern Windows exploitation. A single primitive rarely gets you code execution on a fully-mitigated system. The interesting work, and the real defensive value, is in understanding how primitives chain together and where the mitigation layers intersect.

Acknowledgments

Thanks to Andrea Pierini for the original vulnerability discovery and the critical observation about the epmap component. Thanks to the Zero Day Initiative for their March 2026 patch analysis. Thanks to the impacket project for the RPC protocol implementation used in our tooling. And thanks to the Microsoft Security Response Center for the comprehensive, multi-layered patch.

This research was conducted in an isolated lab environment with explicit authorization. All testing was performed on systems owned and operated by the researcher.