After the copy-fail vulnerability, another new vulnerability was found recently. This allows a regular user to become root without the password (which means, any random program can successfully run a root command).
See https://www.openwall.com/lists/oss-security/2026/05/07/8 and https://github.com/V4bel/dirtyfrag
Some kernels in Arch are affected: https://github.com/V4bel/dirtyfrag/issues/6
openwall:
"This vulnerability has a similar impact to the previous Copy Fail.
Because the embargo has now been broken, no patches or CVEs exist for
these vulnerabilities. After consultation with the linux-distros@ā¦openwall.org
maintainers, and at the maintainersā request, I am publicly releasing this
Dirty Frag document.
As with the previous Copy Fail vulnerability, Dirty Frag likewise allows
immediate root privilege escalation on all major distributions, and it
chains two separate vulnerabilities"
WTH does āthe embargo has now been brokenā mean? a chain of custody thing?
In light of the Global Canvas .edu ransomware fiasco where ShinyObjects or whatever its called claims 275 million PII-breached students, teachers, and admins around the world and has literally stopped all online learning around the world at most colleges and unisā¦
..in light of copy/failā¦
..in light of massive DDOS on arch/UBU
ā¦thereās more Iām missing including āIranianā hacks etc
Digitally, May really feels like (cyber) war for some reasonā¦and it just startedā¦
This is the mitigation being shared by most sources:
Mitigation
- Because the responsible disclosure schedule and the embargo have been broken, no patch exists for any distribution. Use the following command to remove the modules in which the vulnerabilities occur.
sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
- Once each distribution backports a patch, update accordingly.
This will unload (rmmod) and disable three modules:
esp4 - IPsec ESP for IPv4 (xfrm subsystem)esp6 - IPsec ESP for IPv6 (xfrm subsystem)rxrpc - RxRPC protocol (used by AFS)So if youāre currently depending on IPsec, maybe first consider your options before running the proposed mitigation.
Here is a video on it
Just hold on a minute. This will disable IPSec for IPv4 and IPv6. How will VPNs work after this?
Embargo period is typically 60-90 days when the exploit is first disclosed to the original developers and they have time to fix this. So there has been no fix for this til now? Are you sh****ng me?
The embargo period was accidentally broken from my understanding
Yeah VPNās using IPsec will have an issue. There are other protocols, but sometimes one is at the mercy of corporate IT departments. If those departments are using Linux, I imagine this would get their attention at least.
VPNs using IPSec are the majority out there. This is going to be huge.
Seriously Linux Kernel needs to be broken up into a more modular setup.
About the RxRPC, disabling that impacts the Andrew File System (AFS). Beyond that it should not impact anything else. So that should be small.
IPSec is typically part of the strongswan package. If that is not installed then also the vulnerability exists?
The video does not list Arch. So does that mean Arch Linux Kernels are safe?
Pretty sure Arch is affected, you might want to just have a bit of a search to confirm it though
kernel 7.0.5 and new versions for all LTS kernels have just been released with a fix
https://cdn.kernel.org/pub/linux/kernel/v7.x/ChangeLog-7.0.5
everyone is effected by this, and more similar exploits to come sooner or later.
As posted here:
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
will clean off caches affected in case but no warranty on that.
Seems this vulnerability was leaked before anyone was able to create any real fix to close it:
Kim submitted the rxrpc patch to the netdev mailing list on April 29, 2026. The linux-distros embargo was set for May 12. An unrelated third party published the ESP exploit publicly on May 7, breaking the embargo and triggering immediate full disclosure
And i do not recommend to run the one-line-special mentioned, it is not to test if you are effected, it is to demonstrate the vulnerability itself:
On the writeup you can fine also a disclosure-timeline:
- 2026-05-08: The f4c50a4034e6 patch was merged into mainline.
- 2026-05-08: This vulnerability was assigned CVE-2026-43284.
Just saw LTS kernel is updated already others will follow soon.
Safe Version: 6.18.28-1-lts
Safe Version: 7.0.3.arch1-3
Shouldnt that read: 6.18.28 ?
i find this for current kernel..
6.18.28-1: current latest build which includes the upstream fixes plus some final fixes .. only tried to report its still ongoing and could change i think.
6.18.27-1 was the version first submitted but only partly fixing the issue.
main kernel is still not reaching repos here .. so i am on LTS for the time ..
Iām keeping an eye on the main kernel update. If it hasnāt arrived before my next break, Iāll reboot into the lts. Thatās about 10 minutes.
hmm germany slow on syncing 
That was me having not cleared the update widget after updating the lts. It was still the LTS 
Is this a typo, i.e. did you mean to say to run this command? If not, could you elaborate why not to run this command? (Or maybe I missed that part in the linked write-ups?)
