Home » Fragnesia (CVE-2026-46300): wat de nieuwste Linux kernel root-exploit betekent voor jouw server en hoe je hem mitigeert

Fragnesia (CVE-2026-46300): wat de nieuwste Linux kernel root-exploit betekent voor jouw server en hoe je hem mitigeert

INHOUD

Op 13 mei 2026 publiceerden onderzoeker William Bowling en het V12 Security team de details van Fragnesia, een nieuwe Linux kernel local privilege escalation kwetsbaarheid die geregistreerd staat als CVE-2026-46300. Het is de derde Linux-kernel root-exploit in drie weken, na Copy Fail (CVE-2026-31431) op 29 april en Dirty Frag (CVE-2026-43284 en CVE-2026-43500) op 7 mei. Een werkende proof-of-concept staat al publiek op GitHub en de upstream patch is gisteren op de netdev mailing list gepost.

Voor iedereen die een Linux-server beheert (een Cloud VPS, een container build farm, een CI-runner, of een multi-tenant host waar onbekende gebruikers shell-toegang hebben) is dit een kwetsbaarheid die je vandaag aanpakt, niet volgende sprint. In dit artikel zetten we op een rij hoe Fragnesia technisch werkt, welke systemen geraakt worden, welke distributies al patches hebben en hoe je veilig mitigeert als rebooten nu niet kan.

Wat is Fragnesia (CVE-2026-46300)?

Fragnesia is een lokale privilege-escalatie in de Linux-kernel, in de gedeelde code rond IPsec ESP en het rxrpc-protocol. De CVSS-score is hoog (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) en de aanval slaagt zonder race-conditie. Vertaald: elke unprivileged gebruiker met een shell op het systeem kan in één enkel commando root worden, ongeacht het draaiende workload-profiel. De vereisten zijn een Linux-kernel die voor 13 mei 2026 is gepubliceerd en (op sommige distributies) ingeschakelde unprivileged user namespaces.

Hoewel de naam (“Frag” plus “amnesia”) in dezelfde familie zit als Dirty Frag, is het een aparte bug. Wel deelt Fragnesia het kwetsbare aanvalsoppervlak met Dirty Frag: dezelfde modules (esp4, esp6 en rxrpc) zijn de weg naar binnen. Wie de Dirty Frag-mitigatie van vorige week al heeft toegepast, is dus ook tegen Fragnesia beschermd.

De technische oorzaak: een vergeten markering in skb_try_coalesce()

De fout zit in de kernel-functie skb_try_coalesce() in de socket-buffer code. Wanneer deze functie paged fragments tussen socket buffers verplaatste, vergat hij de SKBFL_SHARED_FRAG-marker mee te kopiëren. Daardoor “vergat” de kernel dat een bepaald fragment extern beheerd werd, bijvoorbeeld omdat het gespliced was vanuit de page cache van een bestand op disk.

De XFRM ESP-in-TCP receive-path doet in zijn AES-GCM-decryptie vervolgens een in-place schrijfactie. Omdat de marker ontbreekt, schrijft de kernel die decryptie rechtstreeks naar de page cache van een read-only bestand. Een aanvaller hoeft alleen maar een sleutelstroom te kiezen die XOR’d met de inhoud van bijvoorbeeld /usr/bin/su een eigen instructie oplevert. Bij de volgende uitvoering van su haalt de kernel die page op uit de cache (niet vers van disk), en de aanvaller heeft root. De volledige beschrijving en de upstream-patch staan op de netdev mailing list, met als onderwerp “net: skbuff: preserve shared-frag marker during coalescing”.

Welke Linux-systemen zijn kwetsbaar?

In de praktijk: alle gangbare Linux-distributies die op 12 mei 2026 nog niet gepatcht waren. AlmaLinux, Rocky Linux, Red Hat Enterprise Linux, CentOS Stream, Ubuntu, Debian, openSUSE en CloudLinux hebben allemaal de kwetsbare code in hun standaard kernel.

Via esp4 en esp6: alle ondersteunde releases van AlmaLinux 8, 9 en 10 zijn geraakt, omdat deze modules standaard meekomen in het kernel-pakket. Ook Ubuntu, Debian, RHEL en openSUSE zijn op deze weg kwetsbaar.
Via rxrpc: dit pad is alleen relevant op systemen waar de rxrpc-module aanwezig is. Op AlmaLinux 8 wordt rxrpc helemaal niet gebouwd. Op AlmaLinux 9 en 10 zit rxrpc in het pakket kernel-modules-partner, dat in de Devel-repository leeft en standaard niet geïnstalleerd is. Op Debian, Ubuntu en andere upstream-distributies kan rxrpc wel onderdeel zijn van de standaard kernel modules.

Belangrijk om te beseffen: ook al gebruik je IPsec niet, dan nog ben je kwetsbaar zolang de modules geladen kunnen worden. De aanvaller hoeft de module niet vooraf in gebruik te hebben; een unprivileged user die de module via autoload triggert is voldoende.

Patches per distributie

AlmaLinux heeft het snelst gereageerd en levert vanaf 13 mei 2026 gepatchte kernels in de testing-repository, vooruitlopend op de upstream RHEL-update. De versies zijn:

AlmaLinux 8: kernel-4.18.0-553.124.2.el8_10 en hoger
AlmaLinux 9: kernel-5.14.0-611.54.4.el9_7 en hoger
AlmaLinux 10: kernel-6.12.0-124.56.2.el10_1 en hoger
AlmaLinux Kitten 10: dedicated patched build volgt kort na de stable releases

De stappen om op AlmaLinux te updaten naar de testing-kernel zijn vrij standaard:

sudo dnf install -y almalinux-release-testing
sudo dnf update 'kernel*' --enablerepo=almalinux-testing
sudo reboot

Na het rebooten verifieer je met uname -r en rpm -q kernel dat je op de juiste versie zit, en schakel je de testing-repo weer uit op productiesystemen met sudo dnf config-manager --disable almalinux-testing. Voor andere distributies geldt: volg de officiële advisories.

Red Hat: access.redhat.com/security/cve/CVE-2026-46300
Ubuntu: ubuntu.com/security/CVE-2026-46300
Debian: security-tracker.debian.org/tracker/CVE-2026-46300
AlmaLinux: de oorspronkelijke aankondiging bevat zowel de patched-kernel versies als de stappen om te updaten

Mitigatie als je nu nog niet kunt patchen

Een kernel-reboot kan op productie soms even niet, bijvoorbeeld omdat je in een wijzigingsvenster zit of omdat je eerst regressietests wilt draaien. Voor die situatie blokkeer je het aanvalsoppervlak door de drie kwetsbare modules te blacklisten. De drie regels hieronder schrijven een modprobe-config die laden van esp4, esp6 en rxrpc voorkomt, en lossen de modules direct als ze al geladen zijn.

echo 'install esp4 /bin/false' | sudo tee /etc/modprobe.d/fragnesia.conf > /dev/null
echo 'install esp6 /bin/false' | sudo tee -a /etc/modprobe.d/fragnesia.conf > /dev/null
echo 'install rxrpc /bin/false' | sudo tee -a /etc/modprobe.d/fragnesia.conf > /dev/null
sudo rmmod esp4 esp6 rxrpc 2>/dev/null || true

Belangrijk: pas dit niet toe als je IPsec ESP of AFS/rxrpc actief gebruikt op het systeem. Die workloads breken zonder deze modules. De juiste oplossing is dan de patched kernel installeren en herstarten.

Vermoed je dat het systeem al doelwit was voordat je de mitigatie aanzette, dan kun je de page cache leegmaken zodat eventueel gemanipuleerde pages opnieuw vers van disk gelezen worden:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

Dit commando is veilig op een live systeem (het laat alleen schone cache en dentry/inode-entries gaan) en past goed bij de blacklist erboven.

Hoe controleer ik of mijn VPS kwetsbaar is?

Drie snelle commando’s geven je een duidelijk beeld:

# Toont je huidige kernelversie
uname -r

# Geeft aan of esp4/esp6/rxrpc op dit moment geladen zijn
lsmod | grep -E '^(esp4|esp6|rxrpc)'

# AlmaLinux specifiek: is het pakket dat rxrpc levert geinstalleerd?
rpm -q kernel-modules-partner

Vergelijk je uname -r met de versies in het patch-overzicht hierboven. Zit je nog onder de patched versie en geen mitigatie actief, dan ben je kwetsbaar. Een leeg resultaat op lsmod | grep betekent niet dat je veilig bent: de modules kunnen alsnog door een unprivileged user via autoload getriggerd worden.

Wat betekent dit voor klanten van PC Patrol?

Voor onze managed webhosting en managed WordPress hosting houden wij de kernel-patches actief in de gaten en plannen we updates in zodra de patches door onze tests komen. Klanten op deze omgevingen hoeven zelf niets te doen, anders dan eventueel een gepland herstart-venster goedkeuren.

Heb je een unmanaged Cloud VPS bij ons of elders draaien, dan is patchbeheer jouw eigen verantwoordelijkheid. Dit is een goed moment om twee structurele vragen te beantwoorden: weet je welke kernel-versies er op je servers draaien en heb je een proces voor security updates dat binnen 24 tot 72 uur na een disclosure tot een nieuwe kernel leidt? In Cloud VPS in gebruik nemen beschrijven we hoe je dit vanaf dag één goed inricht, en Welke Linux-distributie kies je voor je VPS in 2026 helpt bij de keuze van een distributie met een patch-cadans die past bij jouw operationeel model.

Voor wie monitoring serieus wil nemen (en daarmee veel eerder weet wanneer een module ineens wel of niet geladen is), is onze gids server monitoring met Prometheus en Grafana een goede volgende stap.

Waarom drie kernel root-exploits in drie weken?

Copy Fail (29 april), Dirty Frag (7 mei) en Fragnesia (13 mei) raken alle drie dezelfde brede code-zone: de combinatie van het XFRM-subsysteem, ESP-in-TCP en de bijbehorende socket-buffer manipulaties. Dat is geen toeval. Wanneer onderzoekers een nieuwe klasse van bugs vinden, gaan ze meestal door tot ze alle varianten in dezelfde regio in kaart hebben. Voor beheerders betekent dit: ga er niet vanuit dat Fragnesia de laatste is. Een goede operationele les is je patch-proces voor deze drie weken stevig op te krikken en daarna structureel te verankeren.

Veelgestelde vragen over Fragnesia (CVE-2026-46300)

Heeft Fragnesia een werkende exploit?

Ja. Het V12 Security team heeft de proof-of-concept publiek beschikbaar gemaakt op GitHub onder github.com/v12-security/pocs/tree/main/fragnesia. De code geeft een unprivileged shell binnen één commando root, zonder race-conditie.

Werkt Fragnesia ook als ik IPsec niet gebruik?

Ja. De aanvaller hoeft IPsec niet vooraf in gebruik te hebben. Zolang de modules esp4, esp6 of rxrpc op het systeem geladen kunnen worden (en bij module-autoload is dat standaard het geval), is de exploit bruikbaar. Daarom werkt de mitigatie via blacklisting van die modules zo effectief: je sluit de weg helemaal af.

Volstaat alleen de Dirty Frag-mitigatie?

Ja, voor de korte termijn wel. Omdat Fragnesia dezelfde modules gebruikt als Dirty Frag, blokkeert de bestaande blacklist van esp4, esp6 en rxrpc ook deze nieuwe kwetsbaarheid. Wie de mitigatie van 7 mei al doorvoerde, hoeft nu niets extra’s te doen tot de gepatchte kernel klaarstaat.

Wat is mijn maximaal aanvaardbare patch-window?

Voor een kernel-LPE met publieke PoC adviseren wij binnen 24 uur te mitigeren (de modules blacklisten of de testing-kernel installeren) en binnen 7 dagen op een production-grade gepatchte kernel te zitten. Op multi-tenant systemen, hosts met onbekende shell-gebruikers en publieke CI-runners adviseren we sneller te handelen, in praktijk binnen enkele uren.

Loop ik risico als ik een gehoste WordPress-website heb zonder shell-toegang?

Het directe risico van Fragnesia is een lokale aanvaller die al een unprivileged shell heeft. Op een puur gehoste WordPress-omgeving zonder shell-toegang voor externen is het primaire scenario dus niet de eindgebruiker zelf, maar een aanvaller die via een andere kwetsbaarheid (een onveilige plugin, een gestolen SSH-key) eerst een shell krijgt en daarna escaleert. De combinatie van strakke plugin-veiligheid en proactieve kernelpatches maakt deze keten een stuk korter.

Hulp nodig met patching of monitoring?

Wil je kernel-updates en proactieve mitigatie volledig aan ons overlaten? Bekijk managed webhosting, managed WordPress hosting of plan een adviesgesprek over je VPS-beheer. Eén partner, één Nederlandse factuur, één aanspreekpunt, ook als de volgende kernel-CVE morgen binnenkomt.

Bronnen

Tik je bedrijfsnaam in en check de extensies.

Eén afrekening, drie domeinen, volledige bescherming.