CVE-2026-98432: Ubuntu och RHEL har fortfarande ingen patch, och en Claude-modell har redan skrivit exploiten

De två uppgifterna om CVE-2026-98432 är svåra att förena. Det är en use-after-free i Linuxkärnans IPv4 TCP-handskakning, nåbar över nätverket utan inloggning och utan interaktion, och Linuxkärnans CVE-team bedömde den till 9,8. Per den 30 oktober 2026 har Ubuntu ingen publicerad rättning för 22.04, 24.04, 26.04 eller 26.10, och Red Hat listar RHEL 8, 9 och 10 som påverkade utan rättning och utan godkänd motåtgärd. Det andra faktumet är att Anthropic den 27 oktober publicerade forskning som visar att en ännu inte släppt Claude-modell tog fram ett fungerande proof of concept för oautentiserad fjärrroot mot en server med en MPTCP-lyssnare – ungefär 48 minuter för att läcka en kärnadress och ytterligare fem för kommandokörning.

En sårbarhet som de två största leverantörerna av företags-Linux ännu inte kan lappa, med ett fungerande exploit som delvis skrivits av en maskin, är inte en rutinmässig patch Tuesday. Det är fallet som avgör om din kärnuppgraderingsprocess och din agentåtkomstpolicy har något med varandra att göra.

Buggen, i en paragraf

När en TCP-anslutning upprättas överlämnas IP-alternativ som är kopplade till det inkommande paketet till den nya socketen i stället för att kopieras. Om handskakningen sänder om kan paketet behandlas på en annan CPU än den som äger alternativbufferten – och den andra CPU:n kan läsa minne som den första redan har frigjort. En liknande kapplöpningssituation finns i sökvägen för begärandemigrering. Det påverkade intervallet börjar vid kärna 4.4, det vill säga de flesta maskiner som fortfarande kör en underhållen kärna. Den uppströmskorrigeringen, commit code>e3f33b0a1d89/code>, skjuter upp frigörandet av alternativbuffertarna tills ingen annan kärna längre kan hålla en referens.

Exploaterbarheten följer av mekaniken: ingen autentisering, ingen användarinteraktion, en nätverksnåbar väg och en race som kan göras om. Anthropics egen sammanfattning av varför PoC:n är praktisk är just den egenskapen – ett förlorat race får ett handskakning att misslyckas i stället för att krasha maskinen, så en angripare försöker igen.

Tre leverantörer, tre allvarlighetsvärden

Poängfördelningen är den del som är värd att internalisera, eftersom den avgör om din skanner öppnar ett ärende den här veckan.

• Kernel CVE-teamet — 9,8, kritisk. Nätverksnåbar, inga privilegier krävs, ingen interaktion.

• Red Hat — 8.1, Viktigt. Företagets ståndpunkt är att racet är svårt att vinställa i praktiken.

• Ubuntu — Hög prioritet, utan någon numerisk poäng publicerad på de kontrollerade sidorna.

Skillnaden mellan 9,8 och 8,1 är inte en oenighet om buggen; det är en oenighet om sannolikheten att vinna ett race. Båda är försvarbara, och skillnaden har operativ betydelse: en 9,8 med ett offentligt PoC är ett akutläge, en 8,1 med ett svårvunnet race är en planerad åtgärd. Tills någon publicerar reproduktionssiffror på riktig hårdvara är den ärliga tolkningen att racet går att vinna, eftersom en frontiermodell enligt uppgift ska ha vunnit det.

Vem har en lösning, och vem har inte

Per den 29–30 oktober är läget ojämnt på ett sätt som fångar dem som antar att en stabil kärna innebär en patchad sådan.

• Debian 12 bookworm — åtgärdat i 6.1.190-1 via DLA-4841-1.

• Debian 13 trixie — åtgärdat i 6.12.113-1 via DSA-6568-1.

• Ubuntu 22.04, 24.04, 26.04, 26.10 — ingen publicerad fix; arbete pågår.

• Ubuntu 16.04, 18.04, 20.04 – sårbara, ingen korrigering har släppts.

• RHEL 8, 9, 10 och OpenShift 4 — påverkade, ingen korrigering och ingen mildring som rekommenderas av Red Hat.

• RHEL 6 och 7 – påverkas inte.

• Amazon Linux 2023 — kärnan 6.18 rapporteras åtgärdad; Oracle Linux UEK rapporteras åtgärdad; SUSE rapporterar att vissa utgåvor är åtgärdade och andra fortfarande testas, utan att ange versioner.

Uppströms stabila utgåvor som innehåller rättningen är 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 och 7.3 — vilket är listan att kontrollera mot din egen byggda kärna om du kompilerar din kärna i stället för att använda ett distributionspaket.

Varför MPTCP fortsätter att dyka upp

Buggen är inte specifik för MPTCP, och det är här en stor del av rapporteringen går fel. Red Hat behandlar alla nåbara TCP-tjänster som en möjlig utlösare. Det MPTCP bidrar med är en demonstrerad väg, och det som levererar trafiken är Go: version 1.24 och senare aktiverar multipath TCP som standard för Linux-lyssningssockets när kärnan har MPTCP påslaget. Gos säkerhetsteam varnade för kombinationen den 29 oktober.

Alltså: att ”inaktivera MPTCP” eliminerar den attackväg som Anthropic demonstrerade, inte sårbarheten. Det är en försvarbar tillfällig åtgärd med ett specifikt förbehåll: den är värd att genomföra på Go-tjänster idag, och den är inte en ersättning för en patchad kernel.

Kontrollerna är korta:

• code>ss -Mltnp/code> — listar sockets som för närvarande använder MPTCP.

• code>net.mptcp.enabled/code> — huruvida kärnfunktionen är aktiverad överhuvudtaget.

• code>net.ipv4.tcp_migrate_req/code> — avstängt som standard; om du har slagit på det, slå av det igen.

Specifikt för Go, code>GODEBUG=multipathtcp=0/code> vid körning, eller en code>godebug/code>-rad i code>go.mod/code>, gör att binärfilen väljer bort det.

Inget av detta är leverantörsgodkänt. Red Hat säger rakt ut att företaget inte har någon motåtgärd som uppfyller dess egen standard, vilket är en mer användbar mening än en lista med förhoppningsfulla kringgåenden.

Vad Anthropic faktiskt publicerade

Forskningen är snäv och specifik. En ännu inte utgiven Claude-modell producerade, givet CVE:n och ett mål med en MPTCP-lyssnare, en kedja som läckte en kärnadress på cirka 48 minuter och nådde kommandokörning ungefär fem minuter senare. Anthropic har inte publicerat exploiten, och per den 29 oktober hade varken leverantörer eller CVE-posten rapporterat attacker i det vilda; sårbarheten finns inte i CISA:s KEV-katalog. Den 30 oktober publicerade ett tredjeparts-GitHub-förråd verktyg för race-triggning och minnesläckage i labbmiljö – en återskapande testrigg, dock utan att nå hela vägen till fullständig kodkörning.

Det är kombinationen som är det intressanta. Kapaciteten demonstreras, vapnet hålls tillbaka, och den möjliggörande detaljen – återförsöksegenskapen som förvandlar ett skört race till ett tillförlitligt sådant – är offentlig i prosa. Den som kan återskapa racet vet nu varför det är värt att fortsätta med det.

Vad du ska göra den här veckan

• Patcha och starta om där en fix finns. En kärnfix som är installerad men inte har startats om är ingen fix; verifiera med code>uname -r/code>

• Där din distribution saknar patch – Ubuntu 22.04 till 26.10, RHEL 8 till 10 – måste du nu besluta om du kommer att ta en leverantörs livepatch, flytta till en version som är åtgärdad, eller acceptera exponeringen med MPTCP avstängt för Go-tjänster.

• Kartlägg MPTCP-exponering i stället för att ant att det är avstängt. Standardvärdet ändrades i Go, inte i din konfiguration, och en ändring av ett standardvärde är osynlig i en konfigurationsdiff.

• Öva på omstarten. Den här typen av åtgärd kräver en fullständig omstart, och de organisationer som kommer att förlora mest tid är de som upptäcker sin failover-lösning under underhållsfönstret.

De två frågor som denna CVE faktiskt väcker

Den första handlar om exploitgenerering, och den är inte filosofisk. En modell hittade en sekvens som väldigt många mänskliga forskare inte hade hittat, mot ett mål med en specifik möjliggörande konfiguration, på under en timme. Oavsett om exploiten publiceras eller inte har tidslinjen förändrats: fönstret mellan en offentlig rådgivning och en fungerande exploit mäts nu mot modeller som läser rådgivningen.

Den andra handlar om vad patchning innebär när leverantörerna inte kan patcha. Distributionen som levererar en kärna till dig och kärnan som innehåller rättningen är inte samma objekt, och gapet mellan dem är precis där den här sårbarheten finns för de flesta av läsarna av det här inlägget. OrcaRouter AI Incident Archive indexerar incidenter som den här mot sina primärkällor, allvarlighetsgrad och konfidens, vilket är den version av den här historien som är värd att bevara när nyhetscykeln har rört sig vidare.

Det man inte ska göra är att kategorisera detta som "vänta på leverantören". Leverantörens egen sida säger att det ännu inte finns något att vänta på.

Källnotering: mekanismen, det berörda intervallet från kernel 4.4, upstream-commit code>e3f33b0a1d89/code>, listan över stabila versioner och vägledningen för mitigering kommer från CVE-posten och distributionsrådgivningarna som lästes den 30 oktober 2026. Betygen 9.8, 8.1 och Ubuntu High är kernel-CVE-teamets, Red Hats respektive Canonicals. Statusen för patch per distribution kommer från Debians DLA-4841-1 och DSA-6568-1, Red Hats och Ubuntus CVE-sidor samt leverantörsuttalanden samma datum. Tidslinjen för proof-of-concept, siffrorna 48 minuter och fem minuter samt retry-egenskapen är Anthropics forskning från 27 oktober, som inte offentliggjorde exploiten. Laboratorierepot från 30 oktober beskrivs som tredjeparts och är inte vårt.