So CopyFail CVE-2026-31431 is a thing.
-
If you're curious about IOCs for copyfail, look in syslog for:
NET: Registered PF_ALG protocol family
for attempts to exploit copyfail on systems that use the vulnerable code as a module. For systems that have the vulnerable code compiled into the kernel, like RHEL, you'll see this line on every boot.
And at least for this particular flavor of exploit, a wall-clock nearby:process 'su' launched '/bin/shwith NULL argv: empty string added`
is an indication of successful exploitation.But it's worth noting that the "process launched" stuff is merely what this one ITW PoC will leave behind. Other exploitation techniques do not provide the above.
As such, perhaps looking for
alg: No test for authencesnis perhaps more useful for looking for evidence of the affected endpoint being used.
@wdormann
Ok for Ubuntu, but I can’t find the first one on RHEL 10, instead I have:
kernel: alg: No test for authencesn(hmac(sha256),cbc(aes)) (authencesn(hmac(sha256-avx2),cbc-aes-aesni)) -
@wdormann
Ok for Ubuntu, but I can’t find the first one on RHEL 10, instead I have:
kernel: alg: No test for authencesn(hmac(sha256),cbc(aes)) (authencesn(hmac(sha256-avx2),cbc-aes-aesni))@patpro
RHEL will haveNET: Registered PF_ALG protocol familyin the log on boot, as it's built into the kernel.
Not as a kernel module. -
@patpro
RHEL will haveNET: Registered PF_ALG protocol familyin the log on boot, as it's built into the kernel.
Not as a kernel module.@wdormann OK so in that case it can’t be seen as an IOC on RHEL, is that correct?
-
@wdormann OK so in that case it can’t be seen as an IOC on RHEL, is that correct?
@patpro
Correct.
That's what I indicated in my post.for attempts to exploit copyfail on systems that use the vulnerable code as a module
-
@patpro
Correct.
That's what I indicated in my post.for attempts to exploit copyfail on systems that use the vulnerable code as a module
@wdormann perfect, thank you.
-
@wdormann Sigh, as nerd with a homelab working on really understanding stuff this chaos and lack of documentation doesn't help. From what your saying my main 4 distros are all impacted w no patches in sight. My distros, picked in part to mitigate single point of failure of an individual distro: Mint, MX, Kinoite (Fedora immutable), and Manjaro.
@CliffsEsport
All of those are vulnerable except for Fedora, if it has updates installed.
If you're the only user of these systems, then you have much less to worry about than multi-user systems. -
While this vulnerability seems to be discovered using AI ("Xint Code"), I have to assume that they also let the AI decide how to do the vulnerability coordination as well.
major builds are out as of this writing
No distros have official updates for CVE-2026-31431. Fedora 42 and newer have updates, but no official advisory or acknowledgement of CVE-2026-31431. So with them it's unclear if it's even intentional. Red Hat, Ubuntu, Amazon Linux, and Suse all have advisories as of now, but NO updates.disable the algif_aead moduleas a mitigation.
Bespoke distros like RHEL don't use a module, it's compiled into the kernel.
I can't figure out what the Xint Code angle is with this copyfail stuff. On one hand, yes, it is a true vulnerability that affects a LOT of Linux distros available. And they did submit the bug for fixing to the upstream kernel people.
BUT the CVE has only existed for a week. And NONE of the distros IN THEIR ADVISORY had updates available at the time that they pulled the trigger for publication of the shiny copy.fail website.
I struggle to think of how this even happens. In all my years of infosec, you're either on board with doing CVD (e.g. coordinating with the former CERT/CC) or you're not (dropping 0day). But this all fits bizarrely in the middle. The publication gives the guise that they did the right thing, (and please use our AI services). But at the same time, they clearly chose to release the vulnerability details and functional exploit before any distro had the ability to properly do anything about it.
Either these Xint Code (Theori) people have a hidden agenda or ulterior motive that we aren't aware of yet. Or they're just really bad at coordinated vulnerability disclosure. You pick.
@wdormann sidenote : I personally tested against several Amazon Linux 2023 (aged a few months to 2 days), all of them are immune to this exploit.
(default 'recommended' image, no tweaks) -
@wdormann sidenote : I personally tested against several Amazon Linux 2023 (aged a few months to 2 days), all of them are immune to this exploit.
(default 'recommended' image, no tweaks)@squalouJenkins
Hmm, that does not jive with what Amazon says -
While this vulnerability seems to be discovered using AI ("Xint Code"), I have to assume that they also let the AI decide how to do the vulnerability coordination as well.
major builds are out as of this writing
No distros have official updates for CVE-2026-31431. Fedora 42 and newer have updates, but no official advisory or acknowledgement of CVE-2026-31431. So with them it's unclear if it's even intentional. Red Hat, Ubuntu, Amazon Linux, and Suse all have advisories as of now, but NO updates.disable the algif_aead moduleas a mitigation.
Bespoke distros like RHEL don't use a module, it's compiled into the kernel.
I can't figure out what the Xint Code angle is with this copyfail stuff. On one hand, yes, it is a true vulnerability that affects a LOT of Linux distros available. And they did submit the bug for fixing to the upstream kernel people.
BUT the CVE has only existed for a week. And NONE of the distros IN THEIR ADVISORY had updates available at the time that they pulled the trigger for publication of the shiny copy.fail website.
I struggle to think of how this even happens. In all my years of infosec, you're either on board with doing CVD (e.g. coordinating with the former CERT/CC) or you're not (dropping 0day). But this all fits bizarrely in the middle. The publication gives the guise that they did the right thing, (and please use our AI services). But at the same time, they clearly chose to release the vulnerability details and functional exploit before any distro had the ability to properly do anything about it.
Either these Xint Code (Theori) people have a hidden agenda or ulterior motive that we aren't aware of yet. Or they're just really bad at coordinated vulnerability disclosure. You pick.
@wdormann I'm running F43 and don't appear to be affected (in so far as I can't get the exploit to run). But yeah this is a bit
-
While this vulnerability seems to be discovered using AI ("Xint Code"), I have to assume that they also let the AI decide how to do the vulnerability coordination as well.
major builds are out as of this writing
No distros have official updates for CVE-2026-31431. Fedora 42 and newer have updates, but no official advisory or acknowledgement of CVE-2026-31431. So with them it's unclear if it's even intentional. Red Hat, Ubuntu, Amazon Linux, and Suse all have advisories as of now, but NO updates.disable the algif_aead moduleas a mitigation.
Bespoke distros like RHEL don't use a module, it's compiled into the kernel.
I can't figure out what the Xint Code angle is with this copyfail stuff. On one hand, yes, it is a true vulnerability that affects a LOT of Linux distros available. And they did submit the bug for fixing to the upstream kernel people.
BUT the CVE has only existed for a week. And NONE of the distros IN THEIR ADVISORY had updates available at the time that they pulled the trigger for publication of the shiny copy.fail website.
I struggle to think of how this even happens. In all my years of infosec, you're either on board with doing CVD (e.g. coordinating with the former CERT/CC) or you're not (dropping 0day). But this all fits bizarrely in the middle. The publication gives the guise that they did the right thing, (and please use our AI services). But at the same time, they clearly chose to release the vulnerability details and functional exploit before any distro had the ability to properly do anything about it.
Either these Xint Code (Theori) people have a hidden agenda or ulterior motive that we aren't aware of yet. Or they're just really bad at coordinated vulnerability disclosure. You pick.
@wdormann thanks for this. I checked out from the website after I noticed the Claude Code sheen on the site and seeing discourse about the PoC.
Figured someone wanted to acclaim fame for chucking a few dollars in the token machine, and getting it 80% right. Now the actual smart people can figure out the rest.
-
@CliffsEsport
All of those are vulnerable except for Fedora, if it has updates installed.
If you're the only user of these systems, then you have much less to worry about than multi-user systems.@wdormann @CliffsEsport fedora was vulnerable to me (maybe not if a kernel got released in the last few hours but otherwise yes it’s vulnerable )
-
@wdormann @CliffsEsport fedora was vulnerable to me (maybe not if a kernel got released in the last few hours but otherwise yes it’s vulnerable )
@letoams @CliffsEsport
Up-to-date Fedora (42 or later) are not affected at the time of publication (Yesterday).
At least on this Fedora 42 system, the kernel was built on April 23 and in stable 2 days ago. Not a few hours ago. -
@squalouJenkins
Hmm, that does not jive with what Amazon says@wdormann weird,
I get the same result (error on .splice) on amzn out of the box as on my desktop after applying mitigation -
@wdormann weird,
I get the same result (error on .splice) on amzn out of the box as on my desktop after applying mitigation@squalouJenkins
Oh,spliceis a python error. Not that the platform isn't vulnerable.Interestingly, though, even with a new-enough python version, it still appears as not affected (prompt for password).
Given that Amazon Linux 2023 is kernel 6.1.166 (package built on March 23), and the fix for CVE-2026-31431 didn't happen until 6.1.170.
Perhaps something other than a true fix is interfering with the successful exploitation?
-
@letoams @CliffsEsport
Up-to-date Fedora (42 or later) are not affected at the time of publication (Yesterday).
At least on this Fedora 42 system, the kernel was built on April 23 and in stable 2 days ago. Not a few hours ago.@wdormann @letoams @CliffsEsport confirmed up to date Fedora 43 is also not vulnerable but not if installed kernel is before 6.18.22
-
@wdormann @letoams @CliffsEsport confirmed up to date Fedora 43 is also not vulnerable but not if installed kernel is before 6.18.22
@chillybot @letoams @CliffsEsport
Right, Fedora seems to be the odd one out in that they seem to actually be on top of kernel versions. -
If you're curious about IOCs for copyfail, look in syslog for:
NET: Registered PF_ALG protocol family
for attempts to exploit copyfail on systems that use the vulnerable code as a module. For systems that have the vulnerable code compiled into the kernel, like RHEL, you'll see this line on every boot.
And at least for this particular flavor of exploit, a wall-clock nearby:process 'su' launched '/bin/shwith NULL argv: empty string added`
is an indication of successful exploitation.But it's worth noting that the "process launched" stuff is merely what this one ITW PoC will leave behind. Other exploitation techniques do not provide the above.
As such, perhaps looking for
alg: No test for authencesnis perhaps more useful for looking for evidence of the affected endpoint being used.What went wrong with this case?
Theori appear to have only contacted the linux kernel devs with the vulnerability, as opposed to going the usual CVD route that includes all of the major Linux distros.
Why is this a problem? Since the linux kernel became a CNA, there has been a flood of CVEs for the Linux kernel. The Linux kernel devs' arguments is that any given kernel flaw could presumably be leveraged to behave as a vulnerability, and it's not worth their time to determine "vulnerability" or "not a vulnerability". Everything gets a CVE.
Now the case with copy.fail? It was indeed reported to the kernel devs. And it got a CVE. A single CVE buried in flood of all of the Linux kernel CVEs.
And it appears that every distro on the planet was blindsided by this proven-exploitable vulnerability because they were not given any warning. Or even any suggestion to pick this single CVE out of the sea of Linux kernel CVEs as worth cherry picking.
Much to the chagrin of the Linux devs, RHEL doesn't use up-to-date Linux kernels. They cherry pick CVEs to backport to their chosen kernel version. (e.g. the latest and greates RHEL 10.1 uses 6.12.0, which was released November 17 2024). And in this world where bad actors like Theori don't involve vendors in vulnerability coordination, and just about every Linux kernel bug gets a CVE, this workflow fails. Hard.
Good times...
-
@CliffsEsport
All of those are vulnerable except for Fedora, if it has updates installed.
If you're the only user of these systems, then you have much less to worry about than multi-user systems.@wdormann Thanks! After rereading my post, I didn't intend it as any criticism towards you, hope it didn't come across that way. Just frustration with the CVE & related ecosystem.
-
@wdormann Thanks! After rereading my post, I didn't intend it as any criticism towards you, hope it didn't come across that way. Just frustration with the CVE & related ecosystem.
@CliffsEsport
No, none taken.The CVE ecosystem is a mess. And even more so a mess when it comes to the Linux kernel.
This is a shining example of what can go poorly in such a world.
-
What went wrong with this case?
Theori appear to have only contacted the linux kernel devs with the vulnerability, as opposed to going the usual CVD route that includes all of the major Linux distros.
Why is this a problem? Since the linux kernel became a CNA, there has been a flood of CVEs for the Linux kernel. The Linux kernel devs' arguments is that any given kernel flaw could presumably be leveraged to behave as a vulnerability, and it's not worth their time to determine "vulnerability" or "not a vulnerability". Everything gets a CVE.
Now the case with copy.fail? It was indeed reported to the kernel devs. And it got a CVE. A single CVE buried in flood of all of the Linux kernel CVEs.
And it appears that every distro on the planet was blindsided by this proven-exploitable vulnerability because they were not given any warning. Or even any suggestion to pick this single CVE out of the sea of Linux kernel CVEs as worth cherry picking.
Much to the chagrin of the Linux devs, RHEL doesn't use up-to-date Linux kernels. They cherry pick CVEs to backport to their chosen kernel version. (e.g. the latest and greates RHEL 10.1 uses 6.12.0, which was released November 17 2024). And in this world where bad actors like Theori don't involve vendors in vulnerability coordination, and just about every Linux kernel bug gets a CVE, this workflow fails. Hard.
Good times...
@wdormann This was one of the reasons I pushed so hard to standardize on a rolling release version; because it was easier to deal with reverting to a known good version with breakage than trying to keep track of all the CVEs with different distros and whatever kernel they are packaging for what release cadence for a particular flavor/variant/age/release/support.
I'm still behind, but an understandable behind.
