So CopyFail CVE-2026-31431 is a thing.
-
Or RHEL.
I suspect that some people use that?
It's even better, the suggested mitigation does not work on RHEL-family systems: https://x.com/grsecurity/status/2049610274840158481?s=20
-
Or RHEL.
I suspect that some people use that?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.
-
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.
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.
-
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 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.
-
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.
