If your organization runs Linux servers, this is not something you can defer to next sprint.
On April 29, 2026, security researchers at Xint Code publicly disclosed a critical vulnerability in the Linux kernel called Copy Fail, tracked as CVE-2026-31431. It has been present in every major Linux distribution since 2017 and allows any user with basic access to a Linux system to gain full administrative control, reliably, with no special skills required.
The security community is already calling it one of the most impactful Linux vulnerabilities in recent years, and for good reason.
What Is Copy Fail Vulnerability?
Copy Fail (CVE-2026-31431) is a local privilege escalation vulnerability in the Linux kernel. It exploits a chain of three kernel features authencesn, AF_ALG, and a page cache optimization, that were introduced separately between 2011 and 2017. Used together, they allow any local user to modify the kernel's in-memory copy of a file and execute it as root, in seconds.
How Did This Happen?
The vulnerability is the result of three separate kernel changes made over a decade:
In 2011, a feature called authencesn was added to handle a specific type of network encryption. It had a design quirk where it used a part of memory it did not own as temporary scratch space. At the time, no external code could reach that memory, so it was harmless.
In 2015, an interface called AF_ALG was expanded to let regular users access kernel encryption routines directly. Still not exploitable, because input and output were kept separate.
In 2017, a performance optimization in the same code merged the input and output paths. Without anyone realizing it, this connected the 2011 scratch write directly to the system's file cache. Any readable file was now within reach.
Nobody connected these dots until Taeyang Lee at Xint Code did, in 2026. The vulnerability had been sitting there, silently exploitable, for nine years.
How the Exploit Actually Works
Here is what happens step by step, without going too deep into kernel internals.
Step 1: The attacker opens a crypto socket.
Linux has a feature called AF_ALG that lets any regular user talk directly to the kernel's encryption engine. Think of it like a door that was intentionally left unlocked because it was only supposed to do math, not touch files. No admin privileges needed to open it.
Step 2: A file gets mapped into that door.
Linux also has a system call called splice() which moves file data between processes without making a copy. It passes a reference to the actual memory pages that back the file. When the attacker uses splice() to feed a file into the crypto socket, the kernel's file cache for that file is now sitting inside the crypto operation's working memory.
Step 3: The scratch write lands on the file.
When the attacker triggers decryption using the specific authencesn algorithm, that algorithm does its ESN byte-rearrangement trick and writes 4 bytes into what it thinks is scratch space it owns. Because of how the 2017 optimization connected things, that scratch space is actually the kernel's cached copy of whatever file was spliced in.
The operation returns an error (the input was garbage on purpose). But the 4-byte write already happened. Errors do not undo memory writes.
Step 4: Repeat until done.
The attacker loops through this, writing 4 bytes at a time, carefully placing each chunk at a specific offset within the target file's in-memory copy. The target is usually /usr/bin/su , a setuid binary that runs as root when executed. After enough iterations, the in-memory version of that binary has been replaced with shellcode.
Step 5: Run the binary, get root.
The attacker calls su. The kernel loads it from the page cache, which is the corrupted version. The shellcode runs with root privileges. The whole thing takes a few seconds.
The file on disk is never touched. The kernel never marks the modified pages as needing to be written back to disk. From every disk-based monitoring tool's perspective, the binary is clean and unmodified.
This is what makes Copy Fail Vulnerability genuinely different from most privilege escalation exploits: it is deterministic, fast, and leaves no forensic trail on disk.
Who Is Affected?
If your Linux kernel was built between 2017 and the patch date, you are in scope.
The following environments carry the highest risk:
Shared Linux servers. Development boxes, jump hosts, build servers, any system where multiple users have shell access. One compromised or malicious account means full control of the host.
Virtual desktop environments. If you are delivering virtual desktops or applications to users over a shared Linux session host, one user could escalate to root and affect every other session on that machine.
CI/CD runners. Self-hosted GitHub Actions, GitLab, or Jenkins runners that execute code from pull requests are especially exposed. Untrusted code in a PR can become a root shell on your build infrastructure.
Container and Kubernetes environments. Because the Linux page cache is shared across the host, the attack can cross container boundaries. A compromised pod can compromise the node.
What Accops Is Doing
Accops uses multiple Linux distributions across various products. For some modules, Accops supplies the OS; for others, customers provide the OS on which Accops modules are deployed. Accops has validated the vulnerability across all affected products.
Both Accops-provided customized Linux OS and customer-provided OS are affected by this vulnerability. A Hotfix has been released for HySecure, and mitigation scripts are available for all other products. Customers should actively apply the recommended fix to all instances of Linux.
The following Accops products should be patched by following the steps mentioned in the advisory ASA-2026-0501:
- Accops HySecure
- Accops VDI (set with Linux as guest OS)
- Accops HyDesk thin client OS
- Accops NanoOS for repurposing the PC
- Accops Reporting Server running on Linux
- Accops HyID modules (ADS, DMS — with or without Kubernetes)
What You Should Do Right Now
Step 1: Patch your kernel. This is the only complete fix.
Update to the latest kernel package from your distribution's official repositories. The fix is mainline commit a664bf3d603d. After updating, reboot for the change to take effect.
# Ubuntu / Debian
sudo apt update && sudo apt upgrade
# RHEL / Amazon Linux / Rocky / Alma
sudo dnf update kernel
# SUSE
sudo zypper update -t patchStep 2: If you cannot patch immediately, disable algif_aead.
Run the following to block the exploit path while you prepare for a maintenance window:
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.confrmmod algif_aeadThis will not affect disk encryption, VPNs, TLS, or SSH. Those all use separate kernel APIs. For the vast majority of systems, disabling this module has zero operational impact.
Step 3: For containerized or multi-tenant environments, add a seccomp policy that blocks AF_ALG socket creation regardless of patch state. This adds a defensive layer that remains useful even after patching.
Step 4: Make sure whoever manages your Linux infrastructure knows about this. The patch is straightforward, but it requires a reboot, which means planning for production systems.
Detecting Copy Fail Vulnerability Activity
This vulnerability leaves minimal traces, but there are signs to watch for:
Monitor for unexpected AF_ALG socket usage. The algif_aead socket type is rarely used in normal workloads. Logging or auditing unexpected AF_ALG calls, especially with the authencesn algorithm which can flag suspicious local activity. Tools like auditd can be configured to watch for this.
Watch for suspicious local process behavior. Sudden su or privilege escalation from a low-privileged account, especially followed by unusual network or filesystem activity, is a strong indicator of compromise.
Check your kernel version. A simple uname -r check tells you whether you are still running a vulnerable kernel. Any kernel built before April 29, 2026, that has not been patched is at risk.
Closing Thoughts
What stands out about Copy Fail Vulnerability is not how clever the exploit is. It is how invisible it is. No disk writes, no new processes, no unusual network traffic. If you ran a standard security scan on a compromised system, you would likely see nothing. The attack lives entirely in memory and clears itself on reboot.
This is the kind of vulnerability that reinforces why layered security matters. Kernel patching and integrity monitoring are both important, but neither is sufficient alone. You also need behavioural detection, least-privilege access policies, and network segmentation that limits what a compromised host can reach, even if an attacker does get root.
For any assistance, please write to support@accops.com with ASA-2026-0501 in the subject line.
Written by the Accops Security Team
CVE: CVE-2026-31431 | Severity: Critical | Affected since: 2017 kernels
Original research: Xint Code, Taeyang Lee