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.
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.
-
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 get that this was supposed to be a huge ad for Xint Code but the sloppy disclosure really just makes them look incompetent
-
@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?
@squalouJenkins
And interestingly, even downgrading to an older kernel (to ensure that nothing got backported into this otherwise vulnerable 6.1.166 kernel) still gives the same results.
-
@wdormann I get that this was supposed to be a huge ad for Xint Code but the sloppy disclosure really just makes them look incompetent
@k8ie
Yes, it's clear that it was published as a "Look at us!" vehicle.But their abysmally bad coordination put every Linux user on the planet at risk, and is clear evidence that they don't care about anybody other than themselves.
-
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 I wrote about what happens when vulnerability triage (in a broader sense) fails under the pressure from the expected surge of LLM discovered triage in the link below.
I totally missed what you have highlighted here as a case where the CVE, CVD systems fail not because a vuln is not reported but because it is not appropriately (or accurately?) enriched and the report is subsequently lost in the noise.
-
@wdormann I wrote about what happens when vulnerability triage (in a broader sense) fails under the pressure from the expected surge of LLM discovered triage in the link below.
I totally missed what you have highlighted here as a case where the CVE, CVD systems fail not because a vuln is not reported but because it is not appropriately (or accurately?) enriched and the report is subsequently lost in the noise.
@aristot73
Unless something changes, it won't be the last time this happens with the Linux kernel.
-
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 cves turning into marketing vehicles for every company thats a cna is also undoubtedly creating problems in this vein
-
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 And a CVSS 7.8 won't standout when only 8.0+ typically get patched by OS. LPE are very underrated by CVSS.
-
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.
> I have to assume that they also let the AI decide how to do the vulnerability coordination as well.
r/MurderedByWords material right there.
-
@squalouJenkins
And interestingly, even downgrading to an older kernel (to ensure that nothing got backported into this otherwise vulnerable 6.1.166 kernel) still gives the same results.@wdormann I 'll take this as good - even if weird - news.
Less servers to patch... -
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...
Unlike what the buffoons at Theori published as a "mitigation", the folks at Red Hat actually published a viable mitigation for CopyFail CVE-2026-31431.
Specifically, edit your grub (or whatever you use to load your kernel) configuration to have one of the following arguments:
initcall_blacklist=algif_aead_initinitcall_blacklist=af_alg_initinitcall_blacklist=crypto_authenc_esn_module_initWith such boot arguments to the Linux kernel, the affected bits won't be reachable.
-
@wdormann cves turning into marketing vehicles for every company thats a cna is also undoubtedly creating problems in this vein
-
@joshbressers @Viss
If only there were human beings out there who had any sort of experience with coordinating vulnerabilities... -
@joshbressers @Viss
If only there were human beings out there who had any sort of experience with coordinating vulnerabilities... -
@wdormann I 'll take this as good - even if weird - news.
Less servers to patch...@squalouJenkins @wdormann This[1] exploit worked on AL2023 `2023.11.20260413`, the modprobe.d + rmmod combo "fixed" it (`bind: No such file or directory`)
[1]: https://gist.github.com/blasty/d7b5d0599b154c9ec83c182acbd56e8b
-
Unlike what the buffoons at Theori published as a "mitigation", the folks at Red Hat actually published a viable mitigation for CopyFail CVE-2026-31431.
Specifically, edit your grub (or whatever you use to load your kernel) configuration to have one of the following arguments:
initcall_blacklist=algif_aead_initinitcall_blacklist=af_alg_initinitcall_blacklist=crypto_authenc_esn_module_initWith such boot arguments to the Linux kernel, the affected bits won't be reachable.
As mentioned earlier in this thread, the
sucorruption route was only one possible strategy to be used by this exploit.Here's another variant of the exploit that doesn't have to rely on such things to achieve its goal.
For example, the simple
escalateargument simply removes the password requirement for su'ing to root. There are other payloads also possible.Such exploits will not have
process 'su' launched '/bin/shIOCs in the syslogs. Perhaps all that is relevant is thealg: No test for authencesn(hmac(sha256),cbc(aes)) (authencesn(hmac-sha256-lib,cbc-aes-aesni))part. But there's no evidence of what was done.
-
As mentioned earlier in this thread, the
sucorruption route was only one possible strategy to be used by this exploit.Here's another variant of the exploit that doesn't have to rely on such things to achieve its goal.
For example, the simple
escalateargument simply removes the password requirement for su'ing to root. There are other payloads also possible.Such exploits will not have
process 'su' launched '/bin/shIOCs in the syslogs. Perhaps all that is relevant is thealg: No test for authencesn(hmac(sha256),cbc(aes)) (authencesn(hmac-sha256-lib,cbc-aes-aesni))part. But there's no evidence of what was done.There's also a C version of it that works quite well. Even supports aarch64.
