276 - copy.fail Explained-The Linux Kernel Bug That Turns Any User Into Root

Speaker A: Welcome back and thank you for tuning in to use of One Security, the cyber security podcast for Everyday Defender. From analyst to the cseeds in plain English, I'm um, your host Ibrahim Youssef. This week we are talking about a bug with one of the most misleading names I've seen in a while. It's called Copy Fail. If you saw that name pop up perhaps in your feed you will be forgiven for thinking it was some clever browsing pop ups demos, you know, that kind of stuff. Or maybe a problem with your clipboard as it might go as well. Well it's neither. Copy Fail is a Linux kernel vulnerability. Its official label of course in the cve name is CVE 2026 dash 31431 and what makes it worth a full episode? It's not because it's exotic or it has a strange name, it's actually quite simple. It is about how wide its reach is. This single floor lets an ordinary are you sitting and privileged user, uh, on a Linux machine promote themselves all the way up to root. And that is R O O T just so that you hear that correctly. And it does so on nearly every modern Linux distribution shipped since 2017. So in the next 15 to 30 minutes that we have together I want to talk you through, you know, what this bug is all about and uh, how it works and why two of the defenses you probably trust the most, for example your containers or your file integrity monitoring will not save you. And um, finally the biggest story behind how this bug was even found because that part should make every defender sit up. We have all that in this week's episode. This is use of home security episode 276 recorded Saturday 16th of May 2026. Copy fail explain the Linux kernel bug that turns any user into root. So without further ado, let's get into it. Let's start by clearing out the name Copy Fail. And the way they wrote the name is copy, you know, C O P Y dot fail F A I L. Copy Fail is what we call a uh, local privilege escalation. And local privilege escalation, or as uh is termed shortly is lpe. Local means the attacker already has some foothold on the machine. Even the most boring low permission account privilege escalation means they find a way to climb up to a higher level of access, you know, put together. And low privilege escalation is like a ladder. The attack is already inside the building and this bug hands them a ladder straight to the top floor. That's essentially what is going on here. Now you might Be thinking if the attacker already has access, how bad can it really be? And that's exactly the trap. In 2026 the word local covers an enormous amount of grant. Think about what shares a single Linux kernel today. Every container sitting on a shared, you know, kubernetes node, every customer on a shared web hosting box. Every automated uh build job that runs code from an untrusted for example pull request, every window underneath and increasingly every AI agent these days that has been handed shell access. All of those neighbors share one kernel, a kernel level escalation, collapse the wall between them and here's the realistic chain of event picture. Or imagine an attacker who exploits a vulnerable WordPress uh, plugin and they then land on a server as a limited web user. You know the kind of account that can serve web pages but should not really be able to touch anything beyond that anything sensitive normally that is contained um, you know annoying but you know you can, you can, you can probably survive the problem. But now they run the copy fail proof of concept and within seconds they are root on the entire host. Every other tenant on that box is suddenly within reach. The vulnerability doesn't get the attacker through the front door. It changes everything that happens in a few seconds after they are inside. And the official security rating really just paints the picture clearly. The kernel security team scored 7.8 out of 10 on the CVSS scale squarely in the top echelon. You know the high end really. And um, for those of you who not familiar with these jargon CVSS the common vulnerability scoring systems that's what it stands for. It is uh, the industry's standard 0 to 10 rule for how dangerous something can be. Anything in the 7 and 8 is serious and demand definitely you know a uh, prompt attention and critically and this is you know never than some of the early write up suggests. The U. S Cyber security and infrastructure security agency CISA has added copy fail to to its known exploitable vulnerability catalog. You know shortened as kev. That listing came with a hard deadline for U. S Federal agencies for example to go ahead and patch this. And this was in the middle of May. When a bug lands on that list it's no longer really theoretical. It means there is some serious credible evidence that has been, you know that this is actually being used and it might be used against real system that belongs to you. Total compromise. So how does a 4 byte write turn into a total compromise, you might ask? Well let me walk you through without drowning you into kernel discussions and jargons etc. Because the really the elegance, as they put it, of this thing is in the collision of three perfectly normal features. The the first one is, is what is called an M AF ALG socket. And this is a built in Linux feature in the kernel space. Um, since 2015 that lets any normal program ask the kernel to do cryptography on its behalf. Encrypting, hashing, scrambling data, that sort of thing. You open a socket, name the algorithm you want, hand over your data and get the result back completely ordinary, available to any users. The other feature is a function, what is called a splicing and splice on the page cache, you know, is an efficient trick. Instead of copying data around in memory, it hands the kernel a reference, essentially a pointer. Um, for those of you who might have studied computer science C and, and that data is already loaded. The page cache is the kernel in memory, copy of files it has recently read, kept around so it doesn't have to keep going back to the, so you know, to the, the slow disks. The real important part is when you splice a file, you are pointing at the very same cache page that every other program on the system sees when it reads that file. Uh, number three is an optimization which was switched on back in 2017 and that made the cryptography operation work in place. And that really means the input and the output to the same memory spaces are copied. Now watch what happens when you line up all of those three, for example splicing, for example, the socket dealing, etc. Optimization. Um, when you do all of those, one specific cryptographic mode has something going wrong, a quirk if you will. It writes a few bytes of its own scratch data into the destination buffer and with that in place, um, the whole thing really then essentially has a kernel shared in memory copy of real files. So the attacker picks a file that every user is allowed to read, but nobody is allowed to modify. The classic target is the small program that lets you switch to root, for example, four attacker controlled bytes go straight into the cache copy of that program. You know, repeat that fourth byte bytes at a time until the cache version of the program contains the attacker's own instruction, then simply run it. The kernel um, essentially follows the instruction, loads the program from a poisoned memory and executes the attacker's code as root. And what makes copy fail much, you know, nastier if you will. That is because there is no race condition to win, no timing, nothing involved, you know, no need to defeat the kernel's memory randomization, for example, um, the exact same script works unmodified, let's say Back as they said in Ubuntu, Red Hat, Debian, Suzy, Amazon Linux its closest relative, a uh, 2022 bug called Dirty Pipe. Only uh, you know, affected kernel from version 5.8 onward, which you know, spares a lot of other older operating systems. So Copy fail reaches all the way to 2017 optimization and that's very very far in terms of the wide net it really casts on a lot of operating system. And if you really wonder about containers and the integrity of files that I've mentioned earlier, and this is the section I wanted to have a look and lean in if you will and it really calls in the leaders here because it strikes at two controls that most of organization fall. The first one is when we're talking about containers, um, when we're talking about the kernel um, containers, um. Etc is it's the technology like I've talked about and I covered the, the EBBF M technology etc a lot of teams comfort themselves with the belief that if a workload um is locked down inside the properly restructured containers, for example, you know, an attacker is basically really prevented to cause more damage. The attacker has been as they put it, boxed in, right? And um, copy fail against kubernetes running its, let's put it, the strictest workload policy and some teams have actually gone as far as testing copy fail against kubernetes running the strictest workload policies, etc. And against the default security filters that ships with the common containers. Unfortunately the truth um or the finding that is not comfortable here is neither the restricted standard nor the default filters blocked the creation of the suckers that we've touched, for example the call looks completely iniquis. It's just asking for cryptography. So nobody ever had a reason really to block it. And a container that perfectly satisfies your. Your strict policy can still reach a vulnerable code. SETEU has now issued an advisory recommending teams to add a custom filter, et cetera of the socket creation, regardless of whether the kernel is patched. But probably what I would interject is you meant to definitely have a look at the world of ebpf, right? Um, Extended Buckley packet filter that we've touched on previous episode that you can definitely read in a lot of technical jargons today because that's where the world is heading and therefore really looking at the low level of the UM operating system, at the kernel level and what exactly you can do. And in my um, to my knowledge now the, the discussion that we are having is kernel level security, which we definitely need to be aware of so that we can flag out. But kernel level security is something that we, we need to look deeper and not glance over. So I'm picking up the, the controls that we need to depend on is not necessarily file integrity, but definitely kernel level security as a whole and as a jargon to just to explain file integrity monitoring, you know, if you're not familiar with uh, with all of those um, tools like um, Tripwire osec that keep fingerprinting of files of important nature, for example, will raise an alarm if that fingerprint ever changes. Right? So the integrity has been deviated from is what we actually mean here. They are you know, a stable of you know, regulated environment precisely because they are supposed to catch tampering. And a lot of modern of course EDRs include file integrity M monitoring so that we jump on as soon as something funny is going on on the file and it deviates from the norm at the beginning. It sets a baseline and then it then uses that baseline to make sure that it doesn't actually fail a checksum and therefore the integrity. And that's really what it is. Whereas the container level security will make sure something sits at the very low level, uh, as low as it can be and that is assigned. And of course the vendors of operating system sellers, big names will be able to do something at the kernel level without obviously recompiling kernel and updating because we know that takes a long time, months if not probably years to update a kernel. Whereas this low level EPPF nature um, that you can actually um, rely on doesn't actually need that level of scrutiny and you know that amount of time so that you can actually then rely on immediate update even though is at the low level that you can be without even kernel reboot um required as well. So let's have a look at the, the AI side of things that probably will catch a lot of people's attention. Even though this part of the um, the details of this um, copy fail is actually buried inside the technical details that you might actually read on a lot of um, um outlets out there. So I want to call out that upfront because we live in, you know, the age of AI and of course we absolutely need to be aware of where this world is heading. Now this bug was not found by a researcher staring at kernel code for months, although that is possible and there are people who are talented at uh, doing that kind of job is certainly not an easy one to do. It was found by an um, AI assisting code analysis tool in roughly an hour after Heman. You Know, gave it a single prompt pointing at the kernel cryptography subsystem. Because that's really what we are talking about, the human frame the hypothesis. So that expertise is still needed. But the machine did the scaling, right, because that's what we lack. You know, we can throw a lot of eyeballs into it, but you're not going to do that in an hour because you can, you can scale up in a different way because it needs a lot of resources and memory powers and GPUs etc rather than eyeballs. But you can see where this is going now sit with that for a moment because it really cuts in two direction at once. On the defensive side, this is genuinely good news, right, because teams can now audit their own code. And um, this is why Project mitos was all about right for deep logic flow. Far faster and far cheaper than before. But the second capability is available to people with much worse attention, right, like myself. And the cost of hunting for the next copy fail may have just dropped by an order of magnitude. We are also seeing you know, the messy side unfortunately of this shift elsewhere. The Curl project recently ended its bounty program and I think I've touched this on a previous um, um, episode, um, exhausted by uh, you know, a flood of low level quality AI, ah, generated report. What I'm getting at is a lot of back bounties are now attracting a lot of people who are not knowledgeable in terms of attacking systems and back hunting and you know, white hat hunting because they are using AI, um, and therefore they're reporting which is a good thing. But unfortunately it buries the actual talented human beings who are really good at and have tons of experience and years of, of, of doing this kind of research under their belt. So for example, the curl project ended their back bounty because they just could not cope and unfortunately you get, you know, you get stuck between a rock and a hard place in the sense where you can't ignore, ignore every single report that someone throws at you. You need to validate, you need to go to the bottom of it equally. Right? You can't really sift through that. Yes you can use AIs and all of that but you know, we're talking about real impactful vulnerability that might actually be genuinely found by someone but also genuinely found by an AI. But unfortunately you know, you can absolutely, uh, I probably, I will put the justification that Curl developer uh put forward and why they have and it their back bounty in the show notes so that you can make your own judgment. But unfortunately it buried them and therefore they don't have the scale and the human um, um, eyeballs to do all of them. And therefore they probably going to be doing this in some other way, shape or form rather than sifting through of hundreds, probably thousands of reports, um, that has been sent just because someone generated reports, um, etc. So they basically envy the backbone to meaning they're not paying and therefore because everyone wants to get paid, they threw this report at Curl and then Curl has to sit down and sift through. The reason and the justification they gave, just to give you a heads up, is because only the genuine, perhaps the people who are motivated will go through the due diligence without expecting a reward. And you can see the two sides of the coin where you know, you should pay the people who are reporting. And then of course the other side of the cone is exactly what I've said, Dennis. There's going to be a flood of reporter. Actually some of them are, you know, below the bar. But I'll re, I'll link the show notes um, to this um, episode so that you can absolutely have you know, a balanced view rather than me just regurgitating exactly how um, how the intention was put across. Now the same wave of, of tooling that produced um, if you go back to our uh, story of this clean, you know, responsibly disclosed kernel bug is also generating a lot of noise, right? It's exactly the reason why I pick up the Curl being, you know, abandoned in the back bounty. Both are uh, downstream of the same change unfortunately. Right. The, the cadence of these deep disclosures is going to be picked up, you know, because a lot of genuinely good people will be able to use this tool and catapult, you know, and leapfrog most of the other people. Um, but also patching discipline has to keep pace because things are going to be heating up and this is what, you know, Project Mythos and of course OpenAI saying their own AI model, you know, some of their version, latest version is at par with, with mythos etc. You know, the things are going to heat up unfortunately or fortunately depending on where you stand. So let's make this practical. What to do. Here's your probably action list that I would actually um, boil it down to maybe four bullet points first and foremost, which is important, patch your kernels. Right? The fix landed in the mainline Linux kernel on uh, the 1st of April and has been backported into the stable release. For example, the, the ones we're talking about track use specific distribution of security advisory and you know, roll out the Updated kernel that needs to be updated uh for environment that are shared hosting etc, you know painful though it is rebooted is absolutely needed. Live patching services exist of course we with you know EPPF and this newly uh developed approach to kernel security but you know not everything is actually um at speed. So therefore you know to be absolutely precise um you need to follow the guidelines of the developer of the distribution that you have. And as I said a lot of uh distributions are affected. Secondly if you genuinely cannot patch you know when this was actually reported um now what we are talking about but also in the future there are um always interim mitigation published by the vendors um at ah their disclosure. You can blacklist for example certain modules that relies on this copy fail um which then closes that um loophole. It might have an impact in your productivity etc. But you know you need to be safe rather than actually uh, you know have your cake and eat it until you really have your cake and eat it. If you want to put it that way so that you can legitimately rely um on something as a stopgap until you fix that for good. Then number three uh, for kubernetes shops uh ship a custom um restriction um across your cluster um that should deny the creation of the um um af you know underscore alg sockets that has been referred to in the research. Um for example SETEU recommends doing this regardless of your patch status, you know as a quote unquote belt and braces measures for example and fourth and this is where I will finish this is the judgment call for leaders, right? Prioritize by exposures. And I've talked about in previous live, if you rely on just the CVE um reports you know between 1 and 10 you're going to drown because you're lacking priority. You need to prioritize what matters most to your environment. So you definitely need to have some sort of a um vulnerability prioritization system and not necessarily vulnerability scanners alone. You can definitely do vulnerabilities scanners and then you know pass that scanner to something that is actually more intimate to your environment then then sifts through what is exposed within your environment. Does that, you know part of your system or servers or or or environment have higher uh exposure. For example they might have, they might be sitting on the edge. DMZ have a leg on the Internet and a leg on some sort of an internal network. Although you shouldn't, you should put a delineation between the real environment in that we call internal and what is actually Called internal but necessarily reachable from the outside world. And that's why the DMZ um name is coined. If those systems have that kind of footholds then they absolutely more exposed than a server that is completely an internal server. So you need to know and have some system that can actually then sift through that you will be surprised how much you can cut down what you need to focus on. And this is what I mean by prioritize by exposure. If you run a shell users multi tenant containers and you have and we've talked about CID cd, you know the continuous integration continuous development system on the previous episode when we were talking about AI, you know that kind of pipeline that executes and trust code treat this as urgent because that's precisely you know the local foothold um, the attackers will need to, to then you know really propagate throughout your environment. On the other hand a uh, hardened for example single purpose let's say ah, a server running only your own you know, first party application that you develop that you know intimately inside side out with that you fatted and you know quote unquote. There is nothing really called completely trusted because we all depend on third party and open source and third party you know other libraries nowadays. But at least if you really have an intimate knowledge of what is going on and what you know what kind of library is running on, um, you know, don't be surprised when look for shell style kind of vulnerability lands and you don't know anything about what is going on. So if you have an intimate knowledge of what is going on within the application that I called you know first party application that you develop that you know inside out, you know it's, it's, it's much lower practical risk and can fall this into a regular patch cycle for example but don't be fooled, you've got to be cautious and not really be uh, complacent. So that's it with those hopefully pointers that would actually absolutely help copy fail. Just to recap, CVE2026 31431 is a Linux privilege escalation that takes you all the way to root right. It has a cute name I have to say um, but it definitely hides a sinister side um of what it does and unfortunately it goes way back and we're talking about 2017. It goes beyond the usual practical control that you absolutely have and therefore you absolutely need to be vigilant and you know lean in towards your patch. And it was found uh, by an AI tool in about an hour right that changes the economics really of finding deep kernel stuff. And this is what we're seeing really mushrooming and A.I. uh, helping absolutely defenders. But also uh, that's why Mythos was limited to only few companies and not except exposed to everyone from the get go so that those companies can actually then do their homework and absolutely go back and fix their code before it goes mainstream. This is another example. That's it for today. As always, please share and like this episode or any episode that you have listened to and definitely share with your colleagues who might need to hear these type of stories. You can contact me in multiple ways. You can go to usefulsecurity.com about and there you'll find my email or in the show notes there is a hyperlink button that you can send a direct message to me and I read all messages and I do reply as well. So with that said, until next week, take care.