Er is opnieuw onrust in de Linux-wereld: de Linux kernel TCP-kwetsbaarheid met CVE-2026-98432 heeft een hoge CVSS-score van 9.8. De fout zit in de TCP-code van de kernel en kan onder bepaalde omstandigheden geheugenproblemen veroorzaken die zelfs kunnen uitmonden in commando-uitvoering op afstand als root. Vooral omdat fixes per distributie verschillen en sommige partijen nog geen gepatchte kernel beschikbaar hebben, is snel handelen verstandig.
In dit artikel zetten we de kern van het probleem, de impact op hoofdlijnen en praktische vervolgstappen voor beheerders uiteen.
Wat is de Linux kernel TCP-kwetsbaarheid (CVE-2026-98432)?
De kwetsbaarheid is gelogd als CVE-2026-98432 en beïnvloedt volgens de broninformatie onder meer Ubuntu, Red Hat Enterprise Linux (RHEL) en andere Linux-distributies. Het gaat om een race condition in de logica die nieuwe IPv4 TCP-verbindingen opzet.
Door die timingfout kan de kernel mogelijk geheugen lezen dat al is vrijgegeven. Dat type fout staat bekend als use-after-free. In theorie kan dit leiden tot geheugen-corruptie, crashes en in de beschreven exploit-scenario’s zelfs tot remote command execution.
Waarom krijgt deze fout een CVSS-score van 9.8?
De kernel-CVE-tak bracht de CVSS 9.8 in rekening. De redenering achter die score gaat uit van een aanval die TCP-verbindingsaanvragen manipuleert met specifieke IPv4-opties (zoals Record Route of Timestamp). Vervolgens wordt de aanvraag opnieuw gestuurd om de race te winnen.
Volgens de bron wordt de aanval niet als extreem complex gezien: zowel aanvallersactie als omstandigheden rond de race worden als “attacker-induced” beschreven. Dat betekent in de praktijk: een aanvaller kan voldoende stuurkracht hebben om het timingprobleem te proberen te exploiteren.
Hoe werkt de race in TCP precies?
De race speelt zich af tijdens de TCP-handshake. Wanneer een verbinding als compleet wordt beschouwd, verwerkt de kernel de IP-opties die eerder in een pending request waren opgeslagen. Daarbij geeft de kernel die opties door aan het nieuwe socket-object—en in dit geval zonder een expliciete kopie.
Als de socket dan wordt vernietigd terwijl een andere CPU nog bezig is met het verwerken van die opties, kan de kernel eindigen met het uitlezen van vrijgegeven geheugen. Dat is precies het use-after-free mechanisme dat de fout gevaarlijk maakt.
Opmerking over IPv6
De bron meldt dat IPv6 niet door deze race wordt geraakt, omdat de kernel de relevante opties daar wel kopieert.
Welke rol speelt multipath TCP (MPTCP)?
In de details rond de exploit komt een extra factor naar voren: multipath TCP (MPTCP). MPTCP maakt het mogelijk dat één verbinding over meerdere netwerkpaden tegelijk kan lopen. Op Linux moet een toepassing daarvoor expliciet MPTCP aanvragen bij het openen van een socket.
Volgens de bron legt een bericht van Anthropic de koppeling tussen de kwetsbaarheid en MPTCP. De kernel-CVE record en de fix verwijzen niet expliciet naar MPTCP, maar de praktische exploit-situatie—zoals beschreven—maakt er wél gebruik van via een server met een multipath TCP listener.
Wat heeft Anthropic gebouwd (en hoe ziet de aanval eruit)?
De bron noemt dat Anthropic op 27 oktober meldde dat een AI-model (Claude) een exploit schreef die gebruikmaakt van de bug. Daarbij is het doel beschreven als: een remote attacker zonder credentials die opdrachten kan uitvoeren als root op Linux servers met een MPTCP-listener.
De exploit wordt in twee fasen uitgelegd:
- Fase 1: de race zorgt dat extra bytes teruggaan naar de aanvaller. In één van die antwoorden kan een adres van de kernel lekken, waarmee KASLR (kernel address randomization) beter te omzeilen wordt.
- Fase 2: dezelfde fout wordt misbruikt om een buffer-overflow te laten plaatsvinden, waarbij een callback pointer wordt overschreven. Zodra de kernel die pointer aanroept, voert de payload een shell commando naar keuze uit met root rechten.
Volgens de bron testte Anthropic dat het lekken van een kerneladres rond 48 minuten duurde, waarna command execution nog eens ongeveer 5 minuten kostte. De details over Linux-versie/configuratie en de exploitcode zelf ontbreken in de post.
Waarom verschillen de scores tussen het kernelteam en vendors?
Opvallend is dat de kernel-CVE-tak 9.8 noteert, terwijl vendors lagere of andere inschattingen hanteren. In de bron worden o.a. deze punten genoemd:
- Red Hat scoort de kwetsbaarheid in sommige advisories op 5.9 (Moderate) en later hoger.
- Op 29 oktober verschijnt een machine-readable advisorybestand met een hogere inschatting (o.a. 8.1), inclusief beschrijvingen van hogere impact op vertrouwelijkheid en integriteit.
- Amazon en SUSE/Oracle worden eveneens met waarden tussen 5.9 en 8.1 genoemd, maar met verschillen in beoordeling van aanval-complexiteit.
Die verschillen wijzen erop dat vendors anders naar praktische omstandigheden kijken: hoe haalbaar is het om precies genoeg timing te triggeren, en wat is de meest waarschijnlijke uitkomst voor typische omgevingen?
Welke distributies hebben al een fix?
Hier zit het meest praktische knelpunt: de bron meldt dat Ubuntu en RHEL op 29 oktober nog geen fixed kernel hebben uitgebracht. Red Hat zegt bovendien dat er geen mitigatie is die tegelijk makkelijk inzetbaar, breed stabiel en voor de meeste setups geschikt is.
Daartegenover staan andere distributies die wel gepatchte pakketten hebben geleverd, ten minste voor een deel van hun kernels:
- Debian
- Oracle Linux
- SUSE
- Amazon Linux
De bron noemt bovendien dat de fix upstream en teruggeport is naar onderhoudstakken van stabiele kernels. Voor wie zelf kernels compileert, worden versies genoemd waarin de fix al zit.
Wat kun je nu doen als beheerder?
De kernboodschap: update waar mogelijk, en reduceer de blootstelling waar de fix nog niet beschikbaar is. De bron geeft een duidelijke routekaart:
1) Installeer de gepatchte kernel zodra die beschikbaar is
Waar je distributie een fixed kernel of advisory pakket heeft geleverd, is het advies om die update direct door te voeren. Vooral omdat de kwetsbaarheid in de kernel zelf zit.
2) Volg de vendor-status als je op Ubuntu of RHEL draait
Omdat Ubuntu en RHEL in de bron nog geen vaste kernel vermelden, kun je in die periode kijken naar de vendor-communicatie, changelogs en advisories. In de bron wordt expliciet genoemd dat er geen public release date werd gegeven.
3) Herbeoordeel je blootstelling van TCP-services
De bron meldt dat een remote aanvaller de race kan triggeren via een blootgestelde TCP-service. In afwachting van patches kun je dus intern aftoetsen welke TCP services van buitenaf bereikbaar zijn, en waar mogelijk netwerksegmentatie of beperkte inbound toegang toepassen.
Let op: de bron noemt geen bevestigde mitigatie in de vorm van “zet MPTCP uit en het is opgelost”. Evenmin wordt er een harde garantie gegeven dat het blokkeren van TCP-verbindingsaanvragen met specifieke IP-opties het risico volledig uitsluit.
4) Check je eigen kernel-build proces
Als je eigen kernels bouwt, bevat de bron concrete kernelversies waarin de fix is verwerkt. Ook hier geldt: volg de upstream aanbeveling om naar de nieuwste stable te upgraden; cherry-picking van individuele fixes wordt niet ondersteund volgens de bron.
Past dit in bredere trends rond Linux en AI-exploits?
Los van deze specifieke bug past de casus in een groter patroon: aanvallen worden steeds vaker gecombineerd met snellere ontdekking en exploitontwikkeling. In het verleden zagen we ook meldingen waarin AI-systemen of AI-gedreven ketens bijdragen aan nieuwe aanvalsroutes.
Wil je dat soort ontwikkelingen in context bekijken, dan zijn deze artikelen op onze site relevant:
- Threat Operator: AI verandert SOC-rollen en carrières
- Gemini 4 Carbon en kwetsbaarheden: detecteer en repareer
Conclusie: prioriteit geven aan de update
De Linux kernel TCP-kwetsbaarheid (CVE-2026-98432) combineert een hoge score (9.8) met een race condition die use-after-free gedrag kan triggeren. In de beschreven exploitroute kan dit uitmonden in remote code execution met root-rechten, met name in scenario’s die gebruikmaken van MPTCP.
Omdat niet elke distributie op hetzelfde moment een fix levert—en Ubuntu en RHEL op het moment van de bron nog geen gepatchte kernel melden—is het verstandig om vandaag al te starten met: patchstatus checken, TCP-blootstelling beperken waar dat kan, en zodra updates beschikbaar zijn direct upgraden. Zo verklein je de kans dat deze bug een praktisch incident wordt.
Bron: https://thehackernews.com/2026/10/linux-kernel-tcp-flaw-with-98-cvss.html
