So CopyFail CVE-2026-31431 is a thing.
-
i have 2 debian 12, kernel 6.1.0-42-amd64 which are not affected.
1 debian 12 - kernel 6.1.0-38-amd64 affected, event with algif_aead unloaded
@randomized
Interesting that some Debian 12's are not affected, while a fully-patched 13 is affected.
-
@wdormann amusingly, it does not appear to be a thing on musl.
-
If you're using an obscure distro like "Debian", you may not have a fix available.
@wdormann inb4 AI agents incorporate this hack as a workaround for not having high enough privs to accomplish their paperclip maxxing
-
If you're using an obscure distro like "Debian", you may not have a fix available.
Or RHEL.
I suspect that some people use that?
-
If you're using an obscure distro like "Debian", you may not have a fix available.
@wdormann The fix for Debian for users who don't need algif_aead (i.e. most of them): rmmod algif_aead ; find /lib/modules -name algif_aead.ko -exec rm '{}' \;
-
-
@wdormann feel free to ask if you need more info on tthose systems
-
-
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
