3 ms·

If you can access AF_ALG on a server you don't need to do shenanigans like that. It's much easier to just find another bug and exploit that one instead. The co

If you can access AF_ALG on a server you don't need to do shenanigans like that. It's much easier to just find another bug and exploit that one instead. The copy.fail website is very silly, it is not a special bug. If anyone gets compromised by that vuln their node architecture was broken anyway, patching copy.fail doesn't help.

mustardo 5mo ago
I thought copy.fail is a privelage escalation exploit, become root from a regular user? Am I missing something? How would "node architecture" make people vulnerable to this? You have to have shell access to a victim first right? Or am I missing something?
- bjackman 5mo ago
  Yeah you need native code execution, and if you have AF_ALG access there is clearly no sandboxing in place. At that point it's game over on Linux, there are too many bugs. Even if you fix all the known ones in the current kernel, by the time the version with those fixes is qualified and released (not to mention, the machine must reboot), new LPEs have been discovered.
  - eggprices 5mo ago
    To convince me Linux is full of kernel LPE bugs, can you share some of the bugs?
    - ece 5mo ago
      https://gtfobins.org https://gtfobins.org
    - bjackman 5mo ago
      Look at kCTF results. Look at the CVE database. Most of those UAFs are LPE. Many of the OOBs and many of the race conditions too. These are fixed in Linus' master but you are running an old kernel. Then look at the KASAN reports on the syzkaller dashboard. Many of them are LPE. Many of the WARNs and crashes are revealing and underlying bugs that is also an LPE. Most of these never get fixed. Then try pointing your LLM at the codebase and saying "find an LPE". It will find as many as you want (you will exhaust your tokens long before it stops finding bugs). 99.99% of them will be bogus so you need a way to evaluate them at scale, currently this is the weakest approach but we'll get better at it. I can't actually point you to a list of confirmed LPEs coz the only way they get confirmed is when someone exploits them, but there aren't enough exploit authors to do this for all of them. If inference gets really cheap and someone builds a really good agent harness we might start to see it get automated at some point.
loufe 5mo ago
In what way is it "not a special bug"? It's a publicly known root access from RCE exploit. Those cannot be a dime a dozen. I'm sure it's especially interesting for any shared hosting services which might be affected, and could be delayed. I could find any places running containered services and exfiltrate secrets parallel services, no? What constitutes "special" for you, out of curiosity? Something chaining with a hypervisor exploit?
- deleted 5mo ago
  [deleted]
- bjackman 5mo ago
  It's not RCE it's an LPE in an obscure corner of the kernel attack surface that no sensible application depends on. They are absolutely a dime a dozen. Even just in AF_ALG there have been several such vulns fixed in 2026 already. Kernel wide probably hundreds. It's true that most of them will be harder to exploit than this one but that just means you need to prompt your AI a bit harder to get an exploit. (To be fair, in a lot of cases it's gonna be hard to escalate privs without crashing the machine). Ubuntu has userns restrictions now which takes away the main sources of LPEs (random qdiscs, nftables, all that garbage) but there are still huge numbers of these vulns. This is why platforms that do native untrusted code executions have extreme sandboxing. Note Android and ChromeOS aren't affected coz they already knew this code was broken and hide it from unpriv workloads. You can't run untrusted code on Linux without either a very very carefully designed sandboxing layer (like Android/ChromeOS) or virtualization. copy.fail is just one among tens of thousands of reasons for this, and it's a pretty uninteresting one at that. What is "special" depends on your usecase but for my job it's mostly about stuff that's exposed to KVM guests. Biggest source of concerning vulns for us is probably vhost. I expect there are also lots of undiscovered and scary vulns in places like virtiofs, vfio, DAX, and wherever we do device passthrough. > I could find any places running containered services and exfiltrate secrets parallel services, no? Yes. Regardless of copy.fail. Cloud providers don't do that without a VM layer. (If yours does, you need to switch).
  - eddythompson80 5mo ago
cmg 5mo ago
My mind immediately went to chaining this with another recent vulnerability in the Ninja Forms - File Upload plugin [0] > This makes it possible for unauthenticated attackers to upload arbitrary files on the affected site's server which may make remote code execution possible. So, upload and execute a script that loads Copy Fail and even if you're only executing as www-data or another restricted user that "can't" sudo -- suddenly, uid=0! To repeat the refrain... I'm so tired. [0] https://www.wordfence.com/blog/2026/04/attackers-actively-exploiting-critical-vulnerability-in-ninja-forms-file-upload-plugin/ https://www.wordfence.com/blog/2026/04/attackers-actively-ex...
- bjackman 5mo ago
  Yes but what I'm saying is that copy.fail is a minor detail in this scenario. If you are running Ninja Forums you need to run it in its own VM so that if it gets compromised _you don't care if it has uid=0_. You need to do that regardless of copy.fail. Now that you've patched copy.fail, there are loads and loads of other vulns that can be used the same way.

mustardo 5mo ago

I thought copy.fail is a privelage escalation exploit, become root from a regular user? Am I missing something? How would "node architecture" make people vulnerable to this? You have to have shell access to a victim first right? Or am I missing something?

bjackman 5mo ago
Yeah you need native code execution, and if you have AF_ALG access there is clearly no sandboxing in place. At that point it's game over on Linux, there are too many bugs. Even if you fix all the known ones in the current kernel, by the time the version with those fixes is qualified and released (not to mention, the machine must reboot), new LPEs have been discovered.
- eggprices 5mo ago
  To convince me Linux is full of kernel LPE bugs, can you share some of the bugs?
  - ece 5mo ago
    https://gtfobins.org https://gtfobins.org
  - bjackman 5mo ago
    Look at kCTF results. Look at the CVE database. Most of those UAFs are LPE. Many of the OOBs and many of the race conditions too. These are fixed in Linus' master but you are running an old kernel. Then look at the KASAN reports on the syzkaller dashboard. Many of them are LPE. Many of the WARNs and crashes are revealing and underlying bugs that is also an LPE. Most of these never get fixed. Then try pointing your LLM at the codebase and saying "find an LPE". It will find as many as you want (you will exhaust your tokens long before it stops finding bugs). 99.99% of them will be bogus so you need a way to evaluate them at scale, currently this is the weakest approach but we'll get better at it. I can't actually point you to a list of confirmed LPEs coz the only way they get confirmed is when someone exploits them, but there aren't enough exploit authors to do this for all of them. If inference gets really cheap and someone builds a really good agent harness we might start to see it get automated at some point.

loufe 5mo ago

In what way is it "not a special bug"? It's a publicly known root access from RCE exploit. Those cannot be a dime a dozen. I'm sure it's especially interesting for any shared hosting services which might be affected, and could be delayed. I could find any places running containered services and exfiltrate secrets parallel services, no? What constitutes "special" for you, out of curiosity? Something chaining with a hypervisor exploit?

deleted 5mo ago
[deleted]
bjackman 5mo ago
It's not RCE it's an LPE in an obscure corner of the kernel attack surface that no sensible application depends on. They are absolutely a dime a dozen. Even just in AF_ALG there have been several such vulns fixed in 2026 already. Kernel wide probably hundreds. It's true that most of them will be harder to exploit than this one but that just means you need to prompt your AI a bit harder to get an exploit. (To be fair, in a lot of cases it's gonna be hard to escalate privs without crashing the machine). Ubuntu has userns restrictions now which takes away the main sources of LPEs (random qdiscs, nftables, all that garbage) but there are still huge numbers of these vulns. This is why platforms that do native untrusted code executions have extreme sandboxing. Note Android and ChromeOS aren't affected coz they already knew this code was broken and hide it from unpriv workloads. You can't run untrusted code on Linux without either a very very carefully designed sandboxing layer (like Android/ChromeOS) or virtualization. copy.fail is just one among tens of thousands of reasons for this, and it's a pretty uninteresting one at that. What is "special" depends on your usecase but for my job it's mostly about stuff that's exposed to KVM guests. Biggest source of concerning vulns for us is probably vhost. I expect there are also lots of undiscovered and scary vulns in places like virtiofs, vfio, DAX, and wherever we do device passthrough. > I could find any places running containered services and exfiltrate secrets parallel services, no? Yes. Regardless of copy.fail. Cloud providers don't do that without a VM layer. (If yours does, you need to switch).
- eddythompson80 5mo ago

cmg 5mo ago

My mind immediately went to chaining this with another recent vulnerability in the Ninja Forms - File Upload plugin [0] > This makes it possible for unauthenticated attackers to upload arbitrary files on the affected site's server which may make remote code execution possible. So, upload and execute a script that loads Copy Fail and even if you're only executing as www-data or another restricted user that "can't" sudo -- suddenly, uid=0! To repeat the refrain... I'm so tired. [0] https://www.wordfence.com/blog/2026/04/attackers-actively-exploiting-critical-vulnerability-in-ninja-forms-file-upload-plugin/ https://www.wordfence.com/blog/2026/04/attackers-actively-ex...

bjackman 5mo ago
Yes but what I'm saying is that copy.fail is a minor detail in this scenario. If you are running Ninja Forums you need to run it in its own VM so that if it gets compromised _you don't care if it has uid=0_. You need to do that regardless of copy.fail. Now that you've patched copy.fail, there are loads and loads of other vulns that can be used the same way.