Op 29 april 2026 onthulde het beveiligingsteam Xint Code een Linux-kernel kwetsbaarheid die negen jaar onopgemerkt bleef: Copy Fail, geregistreerd als CVE-2026-31431. Eén dag later, op 30 april 2026, hebben wij alle door ons via Laravel Forge beheerde Linux-servers gepatcht. Hieronder uitleg over wat de bug doet, waarom de impact wereldwijd zo groot is, en hoe onze Vapor-applicaties het aanvalsmodel überhaupt buiten de deur houden.
Wat is Copy Fail (CVE-2026-31431)?
Copy Fail is een lineaire logica-fout in het authencesn-component van de Linux-kernel, die misbruikt kan worden via een ketting van AF_ALG (de kernel-crypto-API) en de splice()-systeemcall. Het netto-effect: een onbevoegde lokale gebruiker kan de page cache van willekeurige setuid-binaries — zoals /usr/bin/su — modificeren en zichzelf zo root-rechten toebedelen. Geen race conditions, geen kernel-specifieke offsets, geen exotische voorwaarden. Een Python-script van 732 bytes is genoeg (bron).
De kwetsbaarheid is geïntroduceerd in een optimalisatie van het algif_aead-pad uit 2017 en bleef daarmee bijna negen jaar exploiteerbaar. Iedereen die in die periode een Linux-server in productie heeft gehad — en dat zijn er veel — heeft dus een venster gehad waarin een attacker met minimale toegang volledige systeemcontrole kon overnemen.
De getroffen distributies zijn praktisch ieder mainstream besturingssysteem: Ubuntu 24.04 LTS (kernel 6.17.0-1007-aws), Amazon Linux 2023 (6.18.8-9.213.amzn2023), RHEL 10.1 (6.12.0-124.45.1.el10_1), SUSE 16, Debian, Arch, Fedora en Rocky. Het CVE werd toegekend op 22 april 2026 en gemeld op 23 maart 2026 — er zat dus iets meer dan een maand tussen melding en publieke disclosure (bron).
Waarom dit iedereen met een website raakt
De impact van een Linux-kernel bug is niet abstract. Volgens W3Techs (peilmoment april 2026) draait 59,2% van alle websites met een bekend besturingssysteem op Linux, en bij de top 1 miljoen websites loopt dat op tot 96,3%. In de bredere markt voor webgerichte servers ligt het aandeel rond de 78%. Met andere woorden: praktisch elke website die je vandaag bezoekt, draait op een Linux-server die deze CVE in zich droeg totdat hij gepatcht werd.
Voor een ondernemer met een website betekent dat het volgende: zelfs als je zelf geen serverbeheerder bent, draait jouw site op een omgeving die kwetsbaar was. Of je nu een WordPress-site bij een grote hoster hebt, een webshop bij een gespecialiseerde provider of een SaaS-applicatie van een leverancier — de onderlaag is in 95-plus procent van de gevallen Linux. De vraag is niet óf je geraakt bent, maar of je hostingpartner snel genoeg patcht.
De impact: een achterdeur die zich combineert met élke andere zwakte
CVE-2026-31431 is technisch gezien een local privilege escalation — geen directe remote code execution. Dat klinkt als beperkt risico, maar in de praktijk is het juist het tegenovergestelde. Iedere bestaande zwakte in de bovenliggende stack wordt door deze bug versterkt tot volledige systeemovername:
- Een verouderde WordPress-plugin die een attacker een eenvoudige web shell laat uploaden, levert normaal beperkte rechten op (de webserver-user). Met Copy Fail wordt dat in seconden volledige root-toegang. De attacker kan elke database, elke configuratie, elke privé-sleutel uitlezen, en laterale beweging starten.
- Een gestolen of zwak SSH-wachtwoord van een normale gebruiker — bijvoorbeeld een ontwikkelaar of een SFTP-account — was voorheen schadelijk maar contained. Nu betekent een gelekte set credentials gelijk een totale compromittering.
- Multi-tenant hosting omgevingen waar meerdere klanten op dezelfde server staan (shared hosting, VPS-clusters, sommige Kubernetes-setups, CI/CD runners) zijn extra kwetsbaar: een kwaadwillende klant kan via deze bug zijn buurman compromitteren.
Dat is precies waarom Xint Code en de Linux-kernel maintainers de bug zo hoog inschalen voor multi-tenant en cloud-omgevingen. Een aparte exploit is niet nodig — Copy Fail is de tweede helft van vrijwel élke aanvalsketen.
Een lokale privilege escalation is geen "minor"-bug zodra je context realistisch maakt. Combineer hem met één gelekt wachtwoord, één verouderde plugin, één misconfigured webhook — en je server is van iemand anders.
Wat wij hebben gedaan: patch op 30 april 2026
Wij beheren voor een aantal opdrachtgevers traditionele Linux-servers (Ubuntu LTS) via Laravel Forge. Forge geeft ons een gestandaardiseerde provisioning-laag bovenop AWS, DigitalOcean en Hetzner waarmee we security-updates uniform en gecontroleerd kunnen uitrollen.
De timeline van onze respons:
- 29 april 2026, avond — disclosure. Xint Code publiceert copy.fail met technische details en proof-of-concept exploit. Onze monitoring vangt dit op via security-feeds.
- 30 april 2026, ochtend — beoordeling. We controleren welke door ons beheerde servers raakvlak hebben (alle Forge-Ubuntu-instances), of de exploit relevant is in onze configuratie (ja, op alle setuid-binaries), en welk patch-pad beschikbaar is (mainline-commit
a664bf3d603dvia reguliere apt-update). - 30 april 2026, middag — uitrol. We draaien
apt update && apt upgrademet kernel-update en herstart op alle door ons beheerde Linux-servers. Forge biedt hiervoor een coordinated-restart die downtime minimaliseert. Op enkele servers stondalgif_aeadal uitgesloten via/etc/modprobe.d/als hardening-baseline; daar was de impact al beperkt. - 30 april 2026, avond — verificatie. We controleren per server de actieve kernel-versie (
uname -r) tegen de gepatchte versie en runnen een interne smoketest die de bug-conditie checkt.
De volledige operatie was binnen 24 uur na publieke disclosure afgerond. Voor opdrachtgevers met een Forge-omgeving via Coding Agency is dus geen actie vereist — het was geregeld voor de meeste sites überhaupt onder een aanvalsventiel kwamen, omdat exploitatie ook tijd kost om gericht in te zetten.
Waarom onze AWS-serverless applicaties niet kwetsbaar waren
Het overgrote deel van de applicaties die wij ontwikkelen draait niet op Linux-servers, maar op AWS Lambda via Laravel Vapor. En precies die architectuurkeuze maakt Copy Fail voor die applicaties non-existent als risico. Niet omdat de onderliggende kernels niet kwetsbaar wáren — die waren ze, AWS heeft ze ook moeten patchen — maar omdat het aanvalsmodel überhaupt niet van toepassing is.
De redenen op een rij:
- Geen langdraaiende server. Een Lambda-container leeft typisch enkele seconden tot minuten en wordt daarna vernietigd. Een attacker heeft geen tijdsraam waarin hij lokaal kan inloggen, een Python-exploit kan uploaden en setuid-binaries kan modificeren. De page cache wordt elke invocatie opnieuw opgebouwd.
- Geen shell-toegang. Er is geen SSH, geen interactieve gebruiker, geen tweede klant op dezelfde container. De voorwaarde "een onbevoegde lokale gebruiker met shell-toegang" — die in elk Linux-server scenario triviaal is — is bij Lambda gewoon niet aanwezig.
- Geen setuid-binaries in de runtime. Lambda-runtimes zijn afgeslankt; de klassieke
/usr/bin/suen/usr/bin/sudodie het primaire doelwit van Copy Fail vormen, zitten er niet in. - AWS patcht de onderlaag centraal. Als AWS een kernel-update uitrolt, gebeurt dat in de underlying Firecracker MicroVM's — onzichtbaar voor de developer, zonder downtime, en typisch parallel aan of vóór het publieke disclosure-moment. Wij hoefden voor onze Vapor-applicaties niets te doen.
Het effect is dat de hele klasse van "kernel-bug-die-elke-Linux-server-raakt" voor onze serverless applicaties simpelweg geen issue is. Hetzelfde geldt voor andere CVE-categorieën: kernel use-after-free's, container escapes, OOM-kill exploits — als jij geen container beheert, raken ze je niet.
Waarom serverless überhaupt: het bredere voordeel
Copy Fail is een illustratie van een bredere stelling die we al jaren in onze architectuurkeuzes maken: hoe minder server jij beheert, hoe minder server-bugs jou raken. Dat klinkt cynisch, maar het is een wezenlijk veiligheids-, kosten- en operationeel voordeel:
- Geen patch-druk meer. Geen handmatige
apt upgradeop zondagavond, geen wakende ogen op security-feeds, geen scheduled maintenance windows. AWS doet de onderhoudslaag — wij focussen op applicatiecode. - Automatische schaalbaarheid. Je betaalt per uitvoering, niet per uur ongebruikt CPU. Bij een verkeerspiek schaalt Lambda binnen seconden mee; in dalmomenten betaal je niets. Voor de meeste B2B SaaS-applicaties is de TCO substantieel lager dan een traditionele server.
- Hogere uptime. Lambda heeft geen single point of failure. Een Linux-server kan kapot vallen, vol-loggen, vastlopen. Lambda-invocaties verdelen zich over de Availability Zones van AWS — een zone-uitval merk je niet eens.
- Kleiner aanvalsoppervlak. Geen open SSH-poort, geen lange-levende processen, geen gedeelde state tussen requests. Veel klassieke aanvalspatronen (privilege escalation, lateral movement, persistent backdoors) werken simpelweg niet.
- Geen vendor lock-in op de code. Laravel Vapor draait gewoon Laravel — exact dezelfde code die ook op een traditionele server zou draaien. Migreren terug naar Forge of een eigen VPS kan op elk moment, met dezelfde codebase.
De keuze voor serverless is geen ideologische — het is een praktische conclusie na jaren beheer van traditionele Linux-stacks. We hebben de patch-werkdruk, de incident-respons en de "kernel CVE op vrijdagavond"-momenten gezien. AWS Lambda neemt dat hele werkpakket weg. Hoe dat technisch werkt en wanneer het wel of niet past, beschrijven we in detail in Serverless hosting met AWS & Laravel Vapor en Laravel Vapor en AWS.
Wat dit betekent voor jouw hostingkeuze
Als je nadenkt over waar je je volgende SaaS-product, klantportaal of webshop laat hosten, geeft Copy Fail een aanvullend perspectief op de afweging. Drie scenario's:
| Scenario | Impact Copy Fail | Verantwoordelijkheid patchen |
|---|---|---|
| Eigen Linux VPS bij willekeurige hoster | Volledig kwetsbaar tot je zelf patcht | Jij — en jij moet weten wanneer er een CVE is |
| Beheerde Linux-server via Forge of vergelijkbaar | Kwetsbaar tot beheerder patcht (typisch 24-48u) | Beheerder, met gestandaardiseerd update-pad |
| Serverless op AWS Lambda (Vapor) | Niet kwetsbaar — geen lokale gebruiker, geen shell | AWS, transparant voor jou |
Voor sommige type applicaties — denk aan applicaties die background workers met persistente state nodig hebben, of legacy-software die geen AWS-runtime ondersteunt — blijft een Linux-server de juiste keuze. In dat geval is een betrouwbare patch-flow van je hostingpartner cruciaal. Voor nieuw te bouwen Laravel-applicaties is serverless steeds vaker de sterkste optie, juist vanwege dit type voorvallen.
Vragen over de impact op jouw applicatie?
Heb je een bestaande Linux-server in productie en weet je niet zeker of je hostingpartner CVE-2026-31431 al heeft gepatcht? Of overweeg je een migratie van een klassieke VPS naar een serverless architectuur en wil je weten of dat past bij jouw applicatie? Neem contact op voor een vrijblijvend gesprek of bekijk onze expertisepagina maatwerk software.
