Copy Fail: Hype versus reality – the full story

Vulnerabilties in danger order

When cybersecurity vulnerabilities are ranked in danger order, RCE holes (short for remote code execution) usually come at the top of the list, and DoS bugs (for denial of service) at the bottom.

That’s because RCEs, as the name suggests, are generally used to attack and break into other computers over the internet, with the aim of implanting malware, snooping on data, launching ransomware, stealing passwords and cryptocoins, spying on users, and much more.

In contrast, DoS bugs don’t give remote attackers a backdoor to break in, but they often allow cybercriminals to crash servers or disrupt services at will.

Somewhere between RCEs and DoSes come EoPs, or elevation of privilege vulnerabilities, which are security holes that can help attackers who are already inside the network, but who only have access as a regular user or via a guest account, to get system privileges that give them full-on sysadmin powers instead.

RCE bug reports therefore tend to dominate the high-drama cybersecurity media headlines, for obvious reasons – an exploitable RCE could be used by criminals or state-sponsored attackers to take over your computer, your servers, or even your whole network, from the other side of the world.

RCE bugs that can reliably and easily be exploited sometimes end up with a Common Vulnerability Scoring System (CVSS) assessment of CVSS 10.0 CRITICAL (that’s a score out of 10, so 10.0 is clearly the worst you can get), but that rating is usually reserved for the sort of bug that almost anyone could exploit right now to break into almost any unpatched computer right now, anywhere on the internet.

If you’re a LinkedIn user and you’re not yet following @SolCyber, do so now to keep up with the delightfully useful Amos The Armadillo’s Almanac series. SolCyber’s lovable mascot Amos provides regular, amusing, and easy-to-digest explanations of cybersecurity jargon, from MiTMs and IDSes to DDoSes and RCEs.

Even if you know all the jargon yourself, Amos will help you explain it to colleagues, friends, and family in an unpretentious, unintimidating way.

BWAIN – Bug With An Impressive Name

Surprisingly, perhaps, considering it was an EoP and not an RCE, a Linux vulnerability with the impressive-sounding name Copy Fail has dominated cybersecurity threat headlines in the past week or two.

Copy Fail has also provoked a dramatic if mostly repetitive stream of social media warnings, despite having a comparatively modest vculnerability score of CVSS 7.8 HIGH.

EoPs are surprisingly commonly found and patched in Windows and Linux alike, yet no other recently-discovered EoP of this sort received anywhere near this level of attention, and most of them attracted no attention at all.

For all the hype, however, Copy Fail is a security hole that’s worth knowing about, especially if you use Linux yourself, or rely on online services that use it (as many or most of them do).

The exploit allows anyone who is already logged into a vulnerable Linux computer to boost their access privilege from a regular user to the all-powerful Linux superuser account, also known as root, without entering a password or passing any sort of authentication check.

Even though the theory of Copy Fail is quite complicated, implementing the attack is surprisingly simple, and the researchers who first reported it managed to squeeze a working demonstration exploit into fewer than 800 bytes of Python script.

Unfortunately, the florid and much-repeated media and social network coverage, combined with extensive marketing penned by the researchers themselves that talks up their exploit code, has almost certainly combined to get more people interested in “trying it out.”

Indeed, the Cybersecurity and Infrastructure Security Agency (CISA) in the US has now added this bug to its official Known Exploited Vulnerabilities (KEV) catalog, although at the time of writing [2026-05-04-T20:00:00Z] the entry contains no specific information about any real-world attacks.

Why focus on this bug?

Why, then, has Copy Fail attracted so much more attention than other vulnerabilities disclosed in the same time frame, even those that could allow remote code execution?

As we mentioned above, the researchers who published the first exploit had a clear marketing purpose in doing so.

The researchers say that although a human expert did the clever work up front by figuring out what to look for, their automated bug-hunting product quickly found a range of places where the potential mistake had found its way into published code.

Of the possibilities found, Copy Fail was deemed the most exciting, and so that’s the one for which they developed a working exploit.

By choosing the media-savvy name Copy Fail, and registering the dedicated domain name copy.fail to promote their story, they were able to dominate online searches and ensnare the IT media into writing up their story.

They turned the bug itself into a dramatic, media-friendly sales pitch for their product, and handily supplied technical-sounding promotional text that social media influencers found irresistible, and repeated wholesale, even if they didn’t understand it.

The opening salvo of the copy.fail site, for example, babbles excitably:

Most Linux [local privilege elevations] need a race window or a kernel-specific offset. Copy Fail is a straight-line logic flaw — it needs neither. The same 732-byte Python script roots every Linux distribution shipped since 2017.

The claim that the script “roots every Linux distro” is admittedly not too far from the truth (many mainstream distros favored by big companies do seem to be vulnerable by default), and makes a riveting headline if copied-and-pasted as it stands.

Sadly, however, it’s not actually correct, so it’s a pity to see it stated as if it were, and accepted and repeated uncritically online.

In my experiments, for instance, the script needed informed modification before it would run on Slackware, due to Slackware storing the program used by the exploit in a different directory, and protecting it with access permissions that precluded its use in this attack anyway.

For all the regrettable hype of the copy.fail product-pitch site, you can nevertheless use the 732-byte proof-of-concept provided by the researchers as a quick test to see if your Linux distro is vulnerable.

As published on GitHub, it doesn’t install any unwanted extra software or make any permanent changes to your system configuration.

Unfortunately, however, if you are vulnerable and the exploit works, it leaves you stuck in a root-level terminal shell, which is directly and dangerously abusable by anyone, even non-technical users.

Also, if the exploit script doesn’t work, it doesn’t help you understand whether that’s because the vulnerability isn’t present on your system at all, or simply because the authors of the script didn’t tailor it for your distro, even though an attacker might be able to do so without much work.

Rather than leaving the system stuck in a root shell by running su for dramatic effect, as these researchers-cum-marketers did, I would have proved my point by running the id program instead. This would prove the vulnerability less dangerously and more usefully, by printing out a message declaring whether root access was acquired or not, and then exiting safely.

Security versus performance

If there’s an amusing (or at least an ironic) aspect to Copy Fail, it’s that the vulnerability, denoted CVE-2026-31431, exists inside the Linux kernel in a component first added about 15 years ago with the noble idea of helping programmers get better at cybersecurity, notably cryptography.

The kernel itself contains its own cryptographic code, safely wrapped in the kernel’s self-protecting cocoon, so it can handle features such as full-disk encryption, network protocols with encryption built in, and so on.

So, why not make the kernel’s encryption library accessible from regular programs via a secure interface, instead of forcing every developer to include a cryptographic library of their own, which they might then fail to use correctly or neglect to update?

Unfortunately, encrypting files via this interface to the kernel isn’t always as fast as you might hope, because the data you want to read and then encrypt needs to be copied back and forth between memory reserved for the kernel, and memory that’s accessible to your program.

For example, if you want to read in 100 bytes from a file, and then to encrypt it via the kernel’s cryptogrpahic code, the process gets quite convoluted:

1. Ask the kernel to read 100 bytes from the file. Typically, the kernel only reads whole sectors or chunks at a time, so it loads up, say, 4096 bytes from the file into a buffer of its own. This data is kept around for a while in the kernel, in what’s known as the page cache, in case it’s used again soon by you, or by another program. Caches often improve performance hugely, because some files, such as frequently-used programs and databases, are accessed over and over.
2. The kernel copies 100 bytes from its page cache into the memory space of your program.
3. You immediately send those very same 100 plaintext bytes back into the kernel so it can encrypt them.
4. The kernel does the encryption, and copies the 100 ciphertext bytes back into the memory space of your program.

Three out-and-back memory copies, even though all you want is the encrypted data at the end.

But what if you could signal to the kernel that you don’t actually need the raw data that was read in?

What if you could tell the kernel to keep the data to itself until the final output from the encryption algorithm was ready, so steps 2 and 3 (copying data in and out of the kernel) can be skipped?

This trick is known loosely as zero-copy, for obvious reasons, and on a busy system can improve performance significantly.

Well, Linux provides a special system call (number 275, as it happens) called splice(), described by Wikipedia as a function “that moves data between a file descriptor and a pipe without a round trip to user space.”

The name, apparently, is a somewhat strained metaphor referred to in the source code as “joining two ropes together by interweaving their strands.”

How the exploit works

Unfortunately, when used in splice() mode, there’s one unusual kernel-based encryption algorithm known as authencesn, short for authenticated encryption with extended sequence numbers, devised for and used in a protocol called IPSec…

…that, until recently, included a buffer overflow bug.

Unusually for a buffer overflow, which usually means copying too much data into an output memory buffer, thus running over the end, the CVE-2026-31431 vulnerability writes exactly four bytes of unwanted data at the end of its input buffer instead.

You can guess where this is going.

The buffer that the bug corrupts is the kernel’s page cache of the file you’re reading in, not the encrypted buffer you get back at the end.

In other words, the bug means that an unprivileged userland program can maliciously write to the kernel’s cached copy of any file, even if the program only has read access to the file.

With just read access to a superuser-privilege program file (what Linux calls setuid-root, and Windows users know by the friendlier name Run as administrator), you can overwite its cached copy with malware, which will sit around in the cache for a while – almost certainly for seconds, if not for minutes or even hours.

Then, if you immediately execute the program you just attacked, the kernel loads it back in straight from the cache, not from disk, thus granting superuser privilege to your malware instead of the named program.

More funkily, perhaps, because the infection only ever exists in the Linux page cache, the program file on disk never gets touched, and the malicious implant quietly vanishes from sight when the cached data expires.

What to do?

• Patch your kernel if you haven’t already. Many if not most distros have already updated the offending authencesc code to remove the buffer overflow. The exploit can’t work, or even be tweaked to work, once the patch is installed. You will need to schedule a reboot to load the updated kernel and any associated run-time modules.
• Consider giving your setuid-root programs execute-only permissions. Generally speaking, regular users don’t need read access to programs to run them, as harmless as having read access might seem. Alpine Linux, for example, popular with users of Linux containers, has a package called busybox-suid that routes all setuid-root tools through a single program called bbsuid, short for BusyBox set user ID. This file has the permissions ---s--x--x, so that anyone can execute it, but no one can read it. This exploit won’t work unless it can open its targeted victim file for reading.
• Review your setuid-root programs. These run as administrator tools are a necessary evil (for example, the passwd utility needs root powers to change your password in the system database), so you should have as few as possible. Even though a single setuid-root program could be enough to exploit this vulnerability, Copy Fail is as a good a motivation as any to review them all and remove ones you don’t want or need. This will help to control your attack surface even after you’ve patched this bug.
• Consider blocking the buggy kernel code from loading. Most distros activate the authencesc code when it is first used, by loading a kernel module called algif_aead. If you configure your system to prevent this module loading, the exploit won’t work. Note that some distros have this module code compiled into the kernel (Rocky Linux is a known example), in which case you will need to change your kernel’s boot-time command line to stop the buggy code being initialized during startup. (See below.)

Some useful tips for digging into and mitigating Copy Fail if you can’t patch your kernel, or a patch is not yet available for your distro:

To find setuid files (programs that run under
a different account, usually root):

   # ls -l $(find / -perm -4000 2>/dev/null)

Any files with read permissions for regular 
users (look for an 'r' in the last three
characters of the file permissions at the 
start of each line) could be exploited in 
this attack.

------

To find out whether the vulnerable algif_aead 
module is built into your kernel, rather than
loaded as a module only when first used:

   # zcat /proc/config.gz | grep -i api_aead

You should see one of the CONFIG lines below:
* Code is a module; blocklisting it prevents exploit:
   CONFIG_CRYPTO_USER_API_AEAD=m 
* Code compiled in; patching kernel prevents exploit:  
   CONFIG_CRYPTO_USER_API_AEAD=y  
* Code was excluded; exploit won't work:
   CONFIG_CRYPTO_USER_API_AEAD=n   

------

To see which kernel crypto modules are loaded,
if any:

   # lsmod | egrep -i '(af_alg|algif_)'

------

To blocklist the offending module from loading,
create this file:

   # echo 'blacklist algif_aead' > /etc/modules.d/stopcopyfail.conf

------

To blocklist the entire kernel crypto interface:

  # echo 'blacklist af_alg' > /etc/modules.d/stopkernelcrypto.conf

------

To suppress the offending code if it's built 
into the kernel, add this kernel command-line 
option and reboot:

   initcall_blacklist=algif_aead_init

Why not ask how SolCyber can help you do cybersecurity in the most human-friendly way? Don’t get stuck behind an ever-expanding convoy of security tools that leave you at the whim of policies and procedures that are dictated by the tools, even though they don’t suit your IT team, your colleagues, or your customers!

More About Duck

Paul Ducklin is a respected expert with more than 30 years of experience as a programmer, reverser, researcher and educator in the cybersecurity industry. Duck, as he is known, is also a globally respected writer, presenter and podcaster with an unmatched knack for explaining even the most complex technical issues in plain English. Read, learn, enjoy!