copy.fail (CVE-2026-31431): een kleine Linux-kernelbug met een ongewoon grote blast radius

Het nieuwe domein op copy.fail ziet er uit als een browser-exploitdemo. Dat is het niet. De site is de publieke disclosure-pagina voor CVE-2026-31431, een privilege escalation in de Linux-kernel die op 29 april 2026 naar buiten kwam. En je moet je er druk om maken, ook als je zelf geen Linux-server beheert. De naam is een woordspeling op het defect zelf: de in-place AEAD-copy van de kernel slaagt er niet in om de page cache te beschermen. Het gevolg is dat elke unprivileged lokale gebruiker op een kwetsbare kernel root kan worden, op vrijwel elke Linux-distributie sinds 2017, zonder dat er ook maar één byte op disk verandert. Tools die op file integrity letten, zien er dus niets van.

Ik wil hieronder doorlopen waarom dit ertoe doet voor hosting, Kubernetes, CI/CD en gewone developer-laptops, en wat copy.fail anders maakt dan de lange rij vergelijkbare bugs die hieraan vooraf ging.

TL;DR

• copy.fail is een Linux-kernel privilege escalation, geen browser- of klembord-aanval. Op 29 april 2026 publiek gemaakt door Theori, met een werkende PoC.
• De bug misbruikt de kernel-crypto-API (AF_ALG-sockets) plus splice() om vier bytes tegelijk in de page cache te schrijven van een bestand dat de aanvaller niet bezit.
• Dezelfde exploit werkt ongewijzigd op Ubuntu, RHEL, Debian, SUSE, Amazon Linux, Fedora en de rest. Geen race condition, geen distro-specifieke offsets.
• Het bestand op disk verandert nooit. AIDE, Tripwire en checksum-monitoring zien niets.
• De Pod Security Standards (Restricted) van Kubernetes en het standaard RuntimeDefault-seccompprofiel blokkeren de gebruikte syscall niet. Een eigen seccompprofiel is nodig.
• De fix in mainline is op 1 april gemerged. Distro's rollen kernels nu uit. Patchen.

Wat copy.fail eigenlijk is

"Local privilege escalation" klinkt droog, dus laat ik even uitpakken. Het betekent: een aanvaller die al ergens code kan draaien op de machine, zelfs als de saaiste unprivileged gebruiker, kan zichzelf naar root promoveren. Vanaf dat punt mag hij elk bestand lezen, backdoors installeren, elk proces meelezen en doorhoppen naar andere systemen.

Waarom is dat een groot probleem op gedeelde infrastructuur? Omdat "lokaal" in 2026 enorm veel dekt: elke container op een gedeelde Kubernetes-node, elke tenant op een shared-hostingbox, elke CI/CD-job die untrusted pull-request-code draait, elke WSL2-instantie op een Windows-laptop, elke containerised AI-agent met shellrechten. Ze delen allemaal één Linux-kernel met hun buren. Een kernel-LPE laat die grens in elkaar klappen.

Het realistische scenario ziet er zo uit. Een aanvaller misbruikt een bekend WordPress-pluginlek en krijgt shell als www-data. Hij draait de copy.fail-PoC en is root op de host. Iedere andere tenant op die machine ligt nu open, precies zoals ik in deze hack-postmortem beschreef. De bug zelf zet de aanvaller niet op de bak; hij verandert wat er in de tien seconden daarna gebeurt.

Hoe de bug werkt

De disclosure-pagina en de uitgebreidere technische uitleg van Theori beschrijven een nette botsing van drie features in de Linux-kernel:

1. AF_ALG-sockets, sinds 2015 in de kernel, laten elke unprivileged gebruiker de kernel om cryptobewerkingen vragen. Je opent een socket, kiest een algoritme, stuurt data, krijgt output.
2. splice() met page-cache pages stopt page-references (geen data-copies) in de kernel. Splice je een gewoon bestand naar een socket, dan zitten dezelfde fysieke pages die elke andere read van dat bestand op het hele systeem voeden, ineens in jouw request.
3. In-place AEAD, in 2017 voor AF_ALG aangezet als performance-optimalisatie, zorgt dat input- en output-scatterlist naar hetzelfde geheugen wijzen.

Combineer dat met een eigenaardigheid van het authencesn AEAD-template (het template voor IPsec extended sequence numbers): authencesn schrijft vier bytes scratch-data naar de destination buffer op een offset die jij kunt sturen. Met in-place mode aan en een spliced bestand als input is die destination buffer de page cache. Vier door de aanvaller gekozen bytes verdwijnen rechtstreeks in de kernel-cache van bijvoorbeeld /usr/bin/su, een setuid-root-binary die elke gebruiker mag lezen. Herhaal totdat de binary jouw payload bevat. Voer hem uit. De kernel laadt uit de page cache, niet van disk. Je draait als root.

Geen race condition. Geen kernel-ASLR-bypass. Hetzelfde script werkt op Ubuntu 22.04, op Amazon Linux 2023, op SUSE 15.6 én op Debian bookworm. De PoC-repository van Theori stond op de dag van disclosure publiek.

De dichtstbijzijnde historische vergelijking is Dirty Pipe (CVE-2022-0847), die ook via een splice-primitive in de page cache schreef. Dirty Pipe vereiste kernels 5.8 of nieuwer, waardoor veel LTS-omgevingen er niets van merkten. copy.fail gaat terug tot de in-place AEAD-commit uit 2017. Dat is een veel breder bereik.

Waarom je container je niet redt

Hier zou ik even willen dat operators rechtop gaan zitten. De mensen van Juliet.sh hebben copy.fail in Kubernetes getest. Ze bevestigen dat PSS Restricted het aanmaken van een AF_ALG-socket niet blokkeert. Het standaard RuntimeDefault-seccompprofiel dat met containerd meekomt doet dat ook niet, op de runtimes die ze testten (Talos en Amazon EKS). Een pod die voldoet aan je strengste workload-policy mag dus gewoon socket(AF_ALG, ...) aanroepen en het kwetsbare code-pad raken. (Eén nuance: de gepubliceerde PoC mikt op /usr/bin/su, dus op minimale immutable distro's zonder setuid-binaries moet een aanvaller een ander in-cache binary kiezen, maar de onderliggende kernel-primitive blijft gewoon bereikbaar.)

De Kubernetes Pod Security Standards hadden ook geen reden om die syscall te blokkeren. Hij ziet er onschuldig uit. Het patroon, dat ik in het artikel over multi-tenant Kubernetes-governance eerder heb uitgewerkt, blijft hetzelfde: defaults die vandaag prima lijken, anticiperen zelden op de exploitklasse van volgend jaar. De CERT-EU-advisory 2026-005 raadt nu aan om een eigen seccompprofiel te draaien dat AF_ALG-sockets expliciet weigert, ongeacht de patch-status.

Er zijn wel een paar isolatiemodellen die overeind blijven. AWS Lambda en Fargate draaien op Firecracker-microVMs met een eigen kernel per tenant. Cloudflare Workers gebruiken V8-isolates. gVisor zet er een user-space-kernel tussen die algif_aead gewoon niet implementeert. Zit je workload daar, dan ben je via deze CVE niet kwetsbaar. Draait hij op een gedeelde kernel, dan wel.

Waarom file-integrity tools blind zijn

Page-cache corruptie zet een page nooit dirty. De writeback-machinerie van de kernel flusht de aangepaste bytes dus niet terug naar disk. Na een geslaagde exploit geeft sha256sum /usr/bin/su keurig de verwachte hash. AIDE, Tripwire, OSSEC en alles wat checksums op disk vergelijkt, zien niets. Toch krijgt elk proces dat die binary op de host inlaadt de gecorrumpeerde versie uit het geheugen, totdat de page wordt evicted of de machine reboot.

Dit is wat copy.fail vervelend maakt. De compromise is onzichtbaar voor de controles waar veel gereguleerde omgevingen op leunen. Detectie moet verschuiven naar syscall-auditing (alerten op socket()-calls met AF_ALG vanuit non-root-users), eBPF-probes op het betreffende code-pad of gedragsdetectie op onverwachte privilege-escalaties. Geen van die dingen staat standaard aan.

Het grotere verhaal: een AI-tool vond dit in een uur

Het meest opvallende detail in de schrijfsel van Theori is niet de bug zelf. Het is de manier waarop hij is gevonden. Theori's commerciële code-analysetool Xint Code, in maart 2026 publiek gelanceerd, legde de bug bloot in ongeveer een uur analyse van het Linux crypto/-subsysteem, op één enkele operator-prompt. Een mens formuleerde de hypothese. De tool schaalde hem op.

De analyse van Bugcrowd zegt het rauw: de kosten om diepe logica-bugs in de kernel te vinden, kunnen met een orde van grootte zijn gedaald. Dat snijdt aan twee kanten. Verdedigers kunnen hun eigen codebases sneller auditen. Aanvallers, ook degenen met minder zuivere motieven dan Theori, kunnen de volgende copy.fail met minder moeite vinden. Dezelfde verschuiving die net deze nette, responsibly disclosed kernelbug opleverde, is ook de verschuiving die curl vorige maand het bug-bountyprogramma deed beëindigen onder een vloed van AI-gegenereerde rommel-rapporten. Beide trends komen uit dezelfde tooling.

Wat je nu moet doen

Patch je kernels. De fix zit sinds 1 april 2026 in mainline (commit a664bf3d603d) en is gebackport naar stable 6.18.22 en 6.19.12. Volg de tracker van je distro:

• Ubuntu: elke huidige LTS (16.04 tot en met 24.04) is kwetsbaar. Ubuntu 26.04 op kernel 7.0 is dat niet.
• Red Hat: RHEL 10.1 bevestigd kwetsbaar, fixes worden uitgerold.
• Debian: fixed in forky en sid. bullseye, bookworm en trixie zijn op 30 april nog kwetsbaar.
• SUSE: security-update gepubliceerd op 30 april.
• Amazon Linux: "Pending Fix" voor de relevante packages op 30 april.
• CloudLinux KernelCare biedt een live patch, handig voor shared hosting waar reboots pijnlijk zijn.

Kun je deze week niet patchen? De praktische mitigaties uit de oss-security-disclosure en de CERT-EU-advisory zijn: blacklist de algif_aead-module (echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf), of voor kernels waarin hij is in-gecompileerd, voeg initcall_blacklist=algif_aead_init toe aan de kernel-commandline. Voor Kubernetes: rol een eigen seccompprofiel uit dat socket(AF_ALG, ...) clusterbreed weigert.

Heb je shell-gebruikers, CI/CD-runners of multi-tenant containers op Linux-hosts? Behandel dit dan als urgent. Een Linux-systeem dat alleen z'n eigen first-party-applicatie draait vanuit een hardened image, zonder dat er untrusted code wordt uitgevoerd, loopt veel minder praktisch risico en kan op de reguliere patch-cyclus wachten. De pers tot nu toe (The Register, Help Net Security) meldt nog geen exploitatie in het wild, maar de PoC is openbaar en het venster tussen "PoC beschikbaar" en "opportunistisch misbruik" sluit historisch in dagen.

Belangrijkste punten

• copy.fail (CVE-2026-31431) is een Linux-kernel privilege escalation, geen browser- of klembord-bug. De grappige naam verbergt een serieuze primitive.
• Hetzelfde exploit-script werkt op vrijwel elke moderne Linux-distributie vanaf 2017, zonder race condition.
• Page-cache corruptie laat geen sporen op disk achter, waardoor de file-integrity-monitoring waarop veel organisaties leunen, niets ziet.
• De Pod Security Standards van Kubernetes en RuntimeDefault-seccomp blokkeren de onderliggende syscall niet. Patch de kernel én voeg een seccompprofiel toe.
• De bug is gevonden door een AI-gestuurde code-analysetool in ongeveer een uur. Reken erop dat de cadans van diepe kerneldisclosures gaat versnellen.