CVE-2026-98432: Ubuntu en RHEL hebben nog steeds geen patch, en een Claude-model heeft al de exploit geschreven

De twee feiten over CVE-2026-98432 gaan niet goed samen. Het is een use-after-free in de IPv4 TCP-handshake van de Linux-kernel, bereikbaar via het netwerk zonder inloggen en zonder interactie, en het kernel-CVE-team kende er 9,8 aan toe. Per 30 oktober 2026 heeft Ubuntu geen uitgebrachte fix voor 22.04, 24.04, 26.04 of 26.10, en Red Hat vermeldt RHEL 8, 9 en 10 als getroffen zonder fix en zonder goedgekeurde mitigatie. Het tweede feit is dat Anthropic op 27 oktober onderzoek publiceerde waarin staat dat een niet-uitgebracht Claude-model een werkend proof of concept produceerde voor ongeauthenticeerde remote root tegen een server met een MPTCP-listener — ongeveer 48 minuten om een kerneladres te lekken en nog vijf om commando's uit te voeren.

Een kwetsbaarheid die de twee grootste leveranciers van enterprise-Linux nog niet kunnen patchen, met een werkende exploit die deels door een machine is geschreven, is geen gewone Patch Tuesday. Het is de casus die bepaalt of je kernel-upgradeproces en je agenttoegangsbeleid iets met elkaar te maken hebben.

De bug, in één alinea

Wanneer een TCP-verbinding wordt opgezet, worden IP-opties die aan het inkomende packet zijn gekoppeld, aan de nieuwe socket doorgegeven in plaats van gekopieerd. Als de handshake opnieuw wordt verzonden, kan het packet worden verwerkt op een andere CPU dan degene die de optiebuffer bezit — en die tweede CPU kan geheugen lezen dat de eerste al heeft vrijgegeven. Een vergelijkbare race bestaat op het pad voor requestmigratie. Het betrokken bereik begint bij kernel 4.4, oftewel de meeste machines die nog een onderhouden kernel draaien. De upstream-fix, commit code>e3f33b0a1d89/code>, vertraagt het vrijgeven van de optiebuffers totdat geen enkele andere core nog een verwijzing kan hebben.

De exploiteerbaarheid volgt uit de mechanica: geen authenticatie, geen gebruikersinteractie, een netwerkbereikbaar pad, en een race die opnieuw kan worden geprobeerd. Anthropics eigen samenvatting van waarom de PoC praktisch is, is precies die eigenschap — een verloren race laat één handshake mislukken in plaats van de machine te laten crashen, dus een aanvaller probeert het gewoon opnieuw.

Drie leveranciers, drie ernstgetallen

De scoreverdeling is het onderdeel dat je je eigen moet maken, want die bepaalt of je scanner deze week een ticket aanmaakt.

• Kernel CVE team — 9,8, kritiek. Bereikbaar via het netwerk, geen privileges vereist, geen interactie.

• Red Hat — 8.1, Belangrijk. Het standpunt van het bedrijf is dat de race in de praktijk moeilijk te winnen is.

• Ubuntu — Hoge prioriteit, zonder dat er een numerieke score is gepubliceerd op de gecontroleerde pagina's.

Het verschil tussen 9.8 en 8.1 is geen meningsverschil over de bug; het is een meningsverschil over de kans om een race te winnen. Beide zijn verdedigbaar, en het verschil is operationeel relevant: een 9.8 met een publieke PoC is een noodgeval, een 8.1 met een moeilijke race is een geplande fix. Totdat iemand reproductiecijfers op echte hardware publiceert, is de eerlijke interpretatie dat de race te winnen is, aangezien een frontier-model die naar verluidt heeft gewonnen.

Wie heeft een oplossing, en wie niet

Per 29–30 oktober is het beeld ongelijkmatig, op een manier die mensen verrast die ervan uitgaan dat een stabiele kernel ook een gepatchte kernel betekent.

• Debian 12 bookworm — vastgelegd in 6.1.190-1 via DLA-4841-1.

• Debian 13 trixie — opgelost in 6.12.113-1 via DSA-6568-1.

• Ubuntu 22.04, 24.04, 26.04, 26.10 — geen uitgebrachte oplossing; werk in uitvoering.

• Ubuntu 16.04, 18.04, 20.04 — kwetsbaar, geen oplossing uitgebracht.

• RHEL 8, 9, 10 en OpenShift 4 — getroffen, geen oplossing en geen door Red Hat goedgekeurde mitigatie.

• RHEL 6 and 7 — niet getroffen.

• Amazon Linux 2023 — kernel 6.18 gemeld als opgelost; Oracle Linux UEK gemeld als opgelost; SUSE meldt dat sommige releases zijn opgelost en andere nog in testfase zijn, zonder versies te noemen.

Upstream stabiele releases die de fix bevatten, zijn 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 en 7.3 — dat is de lijst om tegen je eigen build te controleren als je je kernel zelf compileert in plaats van een distributiepakket te nemen.

Waarom MPTCP steeds weer opduikt

De bug is niet specifiek voor MPTCP, en dat is waar een groot deel van de berichtgeving de fout ingaat. Red Hat beschouwt elke bereikbare TCP-dienst als een mogelijke trigger. Wat MPTCP levert, is een aangetoonde route, en wat het verkeer genereert, is Go: versie 1.24 en later schakelt multipath TCP standaard in voor Linux-luistersockets wanneer de kernel MPTCP heeft ingeschakeld. Het beveiligingsteam van Go waarschuwde op 29 oktober voor de combinatie.

Dus 'MPTCP uitschakelen' verwijdert het pad dat Anthropic heeft aangetoond, niet de kwetsbaarheid. Het is een verdedigbare tussentijdse maatregel met een specifieke kanttekening: het is vandaag de moeite waard om het op Go-services toe te passen, en het is geen vervanging voor een gepatchte kernel.

De controles zijn kort:

• code>ss -Mltnp/code> — toon sockets die momenteel MPTCP gebruiken.

• code>net.mptcp.enabled/code> — of de kernelfunctie überhaupt is ingeschakeld.

• code>net.ipv4.tcp_migrate_req/code> — standaard uit; als je het hebt aangezet, zet het weer uit.

Specifiek voor Go: code>GODEBUG=multipathtcp=0/code> tijdens runtime, of een code>godebug/code>-regel in code>go.mod/code> schakelt de binary uit.

Geen van deze is door de leverancier goedgekeurd. Red Hat stelt ronduit dat het geen mitigerende maatregel heeft die aan zijn eigen standaard voldoet, wat een nuttiger zin is dan een lijst met hoopvolle tijdelijke oplossingen.

Wat Anthropic daadwerkelijk heeft gepubliceerd

Het onderzoek is smal en specifiek. Een nog niet uitgebracht Claude-model produceerde, gegeven de CVE en een doel met een MPTCP-listener, een keten die in ongeveer 48 minuten een kerneladres lekte en ongeveer vijf minuten later commando-uitvoering bereikte. Anthropic heeft de exploit niet gepubliceerd, en per 29 oktober hadden noch leveranciers noch het CVE-record aanvallen in het wild gemeld; de kwetsbaarheid staat niet in CISA's KEV-catalogus. Op 30 oktober publiceerde een GitHub-repository van een derde partij hulpmiddelen voor een race-trigger- en geheugenleklab — een reproductieharness, zonder volledige code-uitvoering.

Die combinatie is het interessante deel. De capaciteit wordt gedemonstreerd, het wapen wordt achtergehouden, en het detail dat het mogelijk maakt — de retry-eigenschap die een fragiele race in een betrouwbare race omzet — staat publiekelijk in proza. Iedereen die de race kan reproduceren, weet nu waarom het de moeite waard is om vol te houden.

Wat te doen deze week

• Patch en herstart waar een fix bestaat. Een kernelfix die is geïnstalleerd maar niet is herstart, is geen fix; controleer met code>uname -r/code>.

• Waar je distributie geen patch heeft — Ubuntu 22.04 tot en met 26.10, RHEL 8 tot en met 10 — beslis nu of je een live patch van de leverancier neem, naar een versie ga die is gefixt, of de blootstelling accepteer met MPTCP uit op Go-diensten.

• Inventariseer de MPTCP-blootstelling in plaats van aan te nemen dat deze uit staat. De standaardwaarde is gewijzigd in Go, niet in je configuratie, en een wijziging aan een standaardwaarde is onzichtbaar in een config-diff.

• Oefen de herstart. Dit soort oplossingen vereist een volledige herstart, en de organisaties die de meeste tijd verliezen, zijn degenen die hun failoververhaal pas tijdens het onderhoudsvenster ontdekken.

De twee vragen die deze CVE eigenlijk oproept

De eerste gaat over het genereren van exploits, en het is niet filosofisch. Een model vond een sequentie die een groot aantal menselijke onderzoekers niet had gevonden, op een doelwit met een specifieke configuratie die dit mogelijk maakt, in minder dan een uur. Of de exploit nu wordt gepubliceerd of niet, de tijdlijn is veranderd: het venster tussen een openbaar beveiligingsadvies en een werkende exploit wordt nu afgemeten aan modellen die het beveiligingsadvies lezen.

De tweede gaat over wat patchen betekent wanneer de leveranciers niet kunnen patchen. De distributie die je een kernel levert en de kernel die de fix bevat, zijn niet hetzelfde object, en de kloof tussen beide is precies waar deze kwetsbaarheid leeft voor de meeste lezers van dit bericht. Het OrcaRouter AI Incident Archive indexeert incidenten zoals dit aan de hand van hun primaire bronnen, ernst en betrouwbaarheid, en dat is de versie van dit verhaal die het waard is om te bewaren zodra de nieuwscyclus verdergaat.

Wat je vooral niet moet doen, is dit wegzetten onder ‘wachten op de leverancier’. De eigen pagina van de leverancier zegt dat er nog niets is om op te wachten.

Bronvermelding: het mechanisme, het getroffen bereik vanaf kernel 4.4 en de upstream-commit code>e3f33b0a1d89/code>, de lijst met stabiele versies en de mitigatierichtlijnen komen uit het CVE-record en de distributieadviezen die op 30 oktober 2026 zijn gelezen. De beoordelingen 9.8, 8.1 en Ubuntu Hoog zijn respectievelijk die van het kernel-CVE-team, Red Hat en Canonical. De patchstatus per distributie komt uit Debian's DLA-4841-1 en DSA-6568-1, de CVE-pagina's van Red Hat en Ubuntu, en leveranciersverklaringen van dezelfde datum. De tijdlijn van het proof-of-concept, de cijfers van 48 minuten en vijf minuten en de retry-eigenschap zijn afkomstig uit het onderzoek van Anthropic van 27 oktober, dat de exploit niet openbaar maakte. Het labrepository van 30 oktober wordt beschreven als van derden en is niet van ons.