Ang Kahinaan sa Madaling Salita
Ang CVE-2026-98432 ay isang race condition sa Linux kernel’s IPv4 TCP handshake code na maaaring magdulot ng use-after-free. Ang may-sira na lohika ay naroroon na mula pa noong Linux 4.4. Kapag natapos ang isang bagong koneksyon, inililipat ng kernel ang IP options na nauugnay sa pending request patungo sa bagong socket nang hindi ito kinokopya. Kung ang socket ay sinira habang may isa pang CPU na gumagamit pa rin ng mga options upang sagutin ang muling ipinadala na connection request, binabasa ng kernel ang memory na matagal nang na-free. Hindi apektado ng partikular na race na ito ang IPv6. Inilagay ng kernel’s own CVE team ang isyu sa 9.8 sa CVSS scale, na itinuturing na mababa ang attack complexity. Ilang distribusyon ang una na nagbigay ng mas mababang score dahil sa hirap manalo sa race, bagama’t ang Red Hat ay naging mas malapit na sa mas mataas na pagtatasa.
Isinaplay ang isang upstream fix noong unang bahagi ng Oktubre at ibinalik sa mga maintained stable kernel branches. Naglabas na ng naayos na kernels ang Debian, Oracle Linux (para sa UEK kernels nito) at ilang Amazon Linux at SUSE packages. Hanggang sa unang bahagi ng Nobyembre 2026, ang mga suportadong release ng Ubuntu (kasama ang kamakailang LTS at cloud variants) at Red Hat Enterprise Linux 8, 9 at 10 ay patuloy na nakalista bilang vulnerable o work-in-progress, na walang na-release na fixed packages. Hindi apektado ang RHEL 7 dahil walang vulnerable code ang kernel nito.
Ang ipinakitang remote root exploit ay gumamit ng multipath TCP (MPTCP) listener bilang entry point. Gumawa ang unreleased research model ng Anthropic ng two-stage attack na una ay nag-leak ng kernel pointer upang talunin ang KASLR at pagkatapos ay inabuso ang parehong use-after-free upang i-overwrite ang isang callback at patakbuhin ang mga command bilang root. Hindi binanggit ng CVE record o ng kernel fix ang MPTCP; ang link ay nagmula sa Anthropic write-up. Umiiral ang underlying bug sa ordinaryong IPv4 TCP connection setup, kaya ang mga serbisyo na hindi gumagamit ng MPTCP ay hindi awtomatikong ligtas. Ang MPTCP configuration ay nagbigay lamang ng maaasahang landas para sa buong root exploit na ipinakita.
Ang praktikal na kahihinatnan ay ang anumang Linux host na tumatanggap ng IPv4 TCP connections ay nananatiling nakalantad hanggang sa ma-update ang kernel nito. Ang pinakamataas na priority surface para sa attack na napatunayan na ay anumang proseso na nagbubukas ng MPTCP listener. Ito ang detalye na ginagawang agad na nauugnay ang default behaviour ng mga kamakailang Go runtimes.
Bakit Ang Go Services Ang Praktikal na Exposure
Simula sa Go 1.24, pinapagana ng standard library ang Multipath TCP bilang default para sa mga listener sa Linux kapag sinusuportahan ito ng kernel. Nalalapat lamang sa server side ang pagbabago. Patuloy na gumagamit ng ordinaryong TCP ang mga Dialer maliban kung tahasang na-configure kung hindi. Ang resulta ay ang isang karaniwang tawag tulad ng `net.Listen("tcp", …)` ay lumilikha ng isang MPTCP listening socket nang walang anumang MPTCP-related code na lumilitaw sa application. Karamihan sa mga Go HTTP servers, gRPC services, reverse proxies at custom listeners na binuo gamit ang Go 1.24 o mas bago ay samakatuwid ay naglalantad ng eksaktong configuration na ginamit ng model ng Anthropic upang makakuha ng remote root.
Ang default ay kinokontrol ng `multipathtcp` GODEBUG setting, na nakatakda sa listeners-only sa Go 1.24. Maaaring i-override ito ng mga operator sa dalawang paraan. Ang pagtatakda ng environment variable na `GODEBUG=multipathtcp=0` ay nagdi-disable ng MPTCP para sa parehong listeners at dialers sa runtime. Ang paglalagay ng `godebug multipathtcp=0` sa `go.mod` file ng main module (o paggamit ng `//go:debug` directive) ay nagtatakda ng parehong behaviour sa build time. Ang mga explicit calls sa `SetMultipathTCP` sa isang `ListenConfig` o `Dialer` ay nag-o-override sa GODEBUG value, kaya dapat i-audit nang hiwalay ang mga site na iyon. Inilarawan ng Go security team ang programme-by-programme disabling bilang isang marupok na mitigation: isang natitirang MPTCP listener ay sapat na upang muling ipakilala ang napatunayang attack path, at ang underlying kernel bug ay hindi limitado sa MPTCP.
Madaling gawin ang detection. Ang command na `ss -Mltnp` (o `ss -lnMp`) ay naglilista ng MPTCP listeners kasama ang mga proseso na nagmamay-ari nito. Sa isang tipikal na Go service, ipinapakita ng output ang parehong ordinaryong TCP listener na ipinapakita ng mga tool tulad ng `ss -tlnp` at ang kaukulang MPTCP socket. Pagkatapos ilapat ang `GODEBUG=multipathtcp=0` at i-restart ang proseso, dapat mawala ang MPTCP entry. Sa system-wide, ang `sysctl net.mptcp.enabled=0` ay pumipigil sa paglikha ng bagong MPTCP sockets, bagama’t nananatili ang mga existing listeners hanggang sa ma-restart ang kanilang mga proseso. Tinatanggal ng mga hakbang na ito ang configuration na napatunayang maaaring i-exploita. Hindi nila inaayos ang use-after-free sa kernel, kaya nananatili silang interim measures hanggang sa ma-install ang isang patched kernel at ma-reboot ang host.
Pribado ang Exploit. Hindi ang Mapa
Nag-publish ang Anthropic’s Frontier Red Team ng isang high-level account ng isang gumaganang remote root exploit para sa CVE-2026-98432 ngunit itinago ang exploit code, ang eksaktong kernel version at configuration na ginamit sa testing, at anumang ready-to-run proof of concept. Ang lumabas ay isang malinaw na paglalarawan ng matagumpay na landas: isang MPTCP listener bilang entry point, paulit-ulit na panalo sa IPv4 TCP handshake race upang mag-leak ng kernel pointer at talunin ang KASLR, sinundan ng paggamit ng parehong use-after-free upang i-overwrite ang isang callback pointer at isagawa ang isang arbitrary shell command bilang root. Binanggit ng write-up na ang isang nabigong race ay nag-a-abort lamang sa indibidwal na connection attempt sa halip na i-crash ang system, na nagpapahintulot sa attacker na subukang muli nang walang limitasyon. Sa naiulat na laboratory run, ang address leak ay tumagal ng humigit-kumulang 48 minuto at ang command execution ay karagdagang lima.
Sapat na ang paglalarawang iyon bilang mapa para sa iba upang simulan ang trabaho. Ilang taon na ang nakalipas, ang pagpunta sa ganitong account tungo sa isang maaasahang remote root exploit ay nangangailangan ng dalubhasang kernel expertise at mahabang manual iteration. Ngayon, ang parehong text ay maaaring ibigay sa mga capable open-weight models tulad ng Qwen na tumatakbo sa madaling makuha na GPU clusters. Hindi gumagawa ang mga modelong ito ng isang tapos na exploit sa unang pagtatangka, ngunit lubhang binabawasan nila ang halaga ng exploration, debugging at refinement. Maaari na ngayong patakbuhin ng maraming independent groups ang paghahanap na iyon nang parallel, na nagpapababa sa hadlang na dating naglilimita sa ganitong uri ng trabaho sa maliit na bilang ng mga researcher.
Nanatiling limitado ang public material hanggang ngayon. Ipinakita ng research toolkits ang kakayahang i-trigger ang race at makakuha ng memory leak, ngunit wala pang nag-claim na nire-reproduce ang buong KASLR bypass at root payload stages na inilarawan ng Anthropic. Walang naiulat na in-the-wild exploitation at hindi lumilitaw ang isyu sa CISA’s Known Exploited Vulnerabilities catalogue. Samakatuwid, ang makatotohanang inaasahan ay hindi isang agarang baha ng public exploits, kundi isang makabuluhang pinaikling panahon sa pagitan ng pag-publish ng mapa at paglitaw ng mga independent working versions. Para sa mga operator na nagpapatakbo ng Go services na patuloy na naglalantad ng MPTCP listeners, ang panahong iyon ang yugto kung saan pinakamahalaga ang interim mitigations.
Ang Katotohanan sa Kubernetes at Service Mesh
Nasa Linux kernel na tumatakbo sa node ang kahinaan. Ito ay na-trigger sa panahon ng IPv4 TCP handshake, bago pa man maabot ng anumang packet ang isang container, sidecar o application. Samakatuwid, ang container images, pod security contexts at service-mesh configurations ay hindi makakasara sa agwat. Ang isang patched kernel sa node (sinundan ng reboot, o isang vendor live patch kung mayroon) ay nananatiling tiyak na pag-aayos. Hanggang sa maipasok iyon sa lugar, ang bawat pod na naka-schedule sa node ay mana ng exposure ng underlying host.
Maraming Kubernetes control-plane components, operators at custom controllers ay nakasulat sa Go. Kapag ang mga binary na iyon ay binuo gamit ang Go 1.24 o mas bago, mana nila ang MPTCP listener default maliban kung tahasang na-disable. Magkatulad ang pag-uugali ng mga workload na nakasulat sa kamakailang Go. Hindi pinapagana ng Envoy, ang data-plane proxy na ginagamit ng karamihan sa service meshes, ang MPTCP bilang default. Ang suporta nito ay isang explicit listener option na dapat i-on sa configuration. Dahil dito, bihirang maging source ng napatunayang attack surface ang mesh mismo, samantalang ang mga Go services na nasa likod o sa tabi ng mesh ay madalas na iyon.
Ang network policies, mutual TLS at sidecar interception ay gumagana pagkatapos na tanggapin at maproseso na ng kernel ang TCP handshake. Hindi nila mapipigilan ang isang use-after-free na nangyayari sa loob ng handshake na iyon. Ang isang attacker na makakaabot sa isang listening port sa node ay maaaring subukan ang race anuman kung ang kalaunan na trapiko ay mai-encrypt o mai-awtorisahan ng mesh. Ang praktikal na implikasyon para sa platform teams ay nananatiling mahalaga ang mesh controls para sa maraming iba pang mga banta ngunit hindi ito kapalit para sa node-kernel patching o para sa interim step ng pagtanggal ng MPTCP listeners mula sa Go components. Sa mga environment na patuloy na nagpapatakbo ng sariling clusters sa Ubuntu o RHEL, ang node kernel timeline ay nananatiling responsibilidad ng operator.
Mga Interim Actions Habang Naghihintay sa Kernel
Ang unang praktikal na hakbang ay isang imbentaryo. Sa bawat node, patakbuhin ang `ss -Mltnp` (o `ss -lnMp`) upang ilista ang bawat MPTCP listener at ang proseso na nagmamay-ari nito. I-cross-reference ang mga prosesong iyon sa mga kilalang Go binaries. Para sa anumang Go service na binuo gamit ang 1.24 o mas bago, kumpirmahin kung aktibo pa rin ang MPTCP default sa pamamagitan ng pagsisiyasat sa environment o sa `go.mod` file na ginamit sa build time. Mabilis nitong pinaghihiwalay ang configuration na ipinakita ng Anthropic mula sa ordinaryong TCP listeners na nananatiling subject lamang sa mas malawak na use-after-free.
Kung maaaring i-restart ang isang Go service, i-disable ang default. Itakda ang `GODEBUG=multipathtcp=0` sa process environment o idagdag ang `godebug multipathtcp=0` sa `go.mod` ng main module at i-rebuild. Pagkatapos ng restart, muling patakbuhin ang `ss` command upang kumpirmahin na nawala ang MPTCP socket. Sa mga host kung saan hindi talaga ginagamit ang MPTCP, ang `sysctl -w net.mptcp.enabled=0` ay pumipigil sa paglikha ng bagong MPTCP sockets. Patuloy ang mga existing listeners hanggang sa ma-restart ang kanilang mga proseso, kaya hindi sapat ang sysctl lamang. Tinatanggal ng mga pagbabagong ito ang napatunayang root path nang hindi naghihintay ng distribution kernel.
Ang karagdagang hardening ay maaaring magbawas sa tsansang magtagumpay ang mga races habang nananatili ang unpatched kernel. Ang pag-filter ng incoming packets na may dalang IPv4 options (Record Route o Timestamp) sa host firewall o sa network edge ay naglilimita sa isa sa mga kondisyon na ginamit ng kernel CVE team sa pag-score nito. Ang pag-monitor para sa paulit-ulit na nabigong handshakes o hindi inaasahang kernel log entries ay nagbibigay ng maagang senyales, bagama’t idinisenyo ang attack upang maiwasan ang pag-crash ng system. Kung nag-aalok ang isang vendor ng live patch para sa partikular na CVE, ilapat ito. Wala sa mga hakbang na ito ang nag-aayos ng use-after-free mismo.
Lahat ng hakbang sa itaas ay interim. Binabawasan o tinatanggal nila ang configuration na napatunayang nagbibigay ng remote root, at maaaring magpalubha sa iba pang mga pagtatangka sa pag-exploita. Hindi nila inaalis ang underlying kernel bug. Isang napalampas na MPTCP listener, isang explicit `SetMultipathTCP(true)` call, o isang future refinement ng attack na hindi na nangangailangan ng MPTCP ay maaaring muling buksan ang exposure. Ang tanging matibay na lunas ay isang patched kernel na naka-install at tumatakbo sa node. Hanggang sa maibigay ng Ubuntu at RHEL ang mga package na iyon, ang inventory at disablement actions ay nananatiling pinakamataas na leverage controls na magagamit ng mga operator.
Ano ang Ibig Sabihin Nito para sa Platform Teams
Nagbibigay ang CVE-2026-98432 ng konkretong halimbawa ng residual responsibility na nananatili kapag ang isang organisasyon ay nagpapatakbo ng sariling Kubernetes clusters. Ang service-mesh policy, network controls at container hardening ay tumutugon sa maraming application-level threats, ngunit iniiwan nila ang node kernel timeline sa mga kamay ng operator. Hindi pa naglabas ang Ubuntu at RHEL ng fixed packages para sa isyung ito, habang nagawa na ito ng Debian at ilang iba pang distribusyon. Samakatuwid, ang mga team na ang mga node ay nasa dating distribusyon ay nahaharap sa mas mahabang window ng exposure kaysa sa mga may base images o managed platforms na mayroon na ang upstream fix. Para sa mga bangko, insurers at iba pang regulated operators na nag-standardize sa Ubuntu o RHEL para sa compliance o support reasons, ang window na iyon ay isang operational fact sa halip na isang abstract risk.
Binibigyang-diin din ng episode ang cumulative effect ng silent defaults sa modernong runtimes. Ang desisyon ng Go na paganahin ang MPTCP sa mga listeners ay ginawa para sa performance at future-proofing reasons at na-document. Sa pagsasagawa, ito ay nagbunga ng isang malawak na na-deploy na configuration na tumugma sa isang napatunayang remote root path nang walang anumang explicit request mula sa application owners. Mayroong katulad na defaults sa iba pang stacks. Ang mga platform teams na itinuturing ang language at runtime behaviour bilang isang implementation detail sa loob ng container ay maaaring makaligtaan ang host-level exposure na makikita lamang kapag na-publish na ang isang kernel vulnerability. Ang isang inventory process na kinabibilangan ng parehong node kernel version at ang effective socket options ng long-running services ay nagbabawas sa sorpresa na iyon.
Sa wakas, ang kumbinasyon ng isang public technical map at malawak na magagamit na open-weight models ay nagpapaikli sa panahon kung saan sapat ang interim controls. Ang mga organisasyon na naglipat na ng node-kernel patching sa isang predictable cadence, o kumokonsumo ng kernels mula sa mga distribusyon na may mas mabilis na security response, ay sumisipsip sa ganitong uri ng isyu nang may mas kaunting pagkagambala. Ang mga patuloy na naghihintay sa Ubuntu o RHEL packages ay dapat tratuhin ang Go MPTCP default bilang isang agarang, reversible control habang inihahanda ang kernel update. Ang mas malawak na aral ay ang commodity Kubernetes ay hindi inaalis ang pangangailangang magmay-ari sa host operating system lifecycle. Ito ay muling inililipat lamang ang mga punto kung saan nagiging nakikita ang pagmamay-ari na iyon.
Konklusyon at Mga Susunod na Hakbang
Walang duda ang priority order. Ang isang patched kernel sa bawat node ang tanging panukalang nagsasara sa use-after-free. Hanggang sa maibigay ng Ubuntu at RHEL ang mga package na iyon, ang pinakamataas na leverage interim control ay ang pagtanggal ng MPTCP listeners mula sa Go services at anumang iba pang proseso na nagbubukas nito. Tinatanggal ng hakbang na iyon ang configuration na ginamit ng model ng Anthropic upang makakuha ng remote root. Hindi nito inaayos ang kernel bug at hindi nito pinoprotektahan laban sa bawat posibleng future refinement ng attack, ngunit ito ay makabuluhang nagbabawas sa surface na napatunayan na.
Mura ang mga agarang pagsusuri. Sa bawat node, ilista ang MPTCP listeners gamit ang `ss -Mltnp`, tukuyin ang anumang Go 1.24 o mas bagong binaries, at ilapat ang `GODEBUG=multipathtcp=0` (o ang katumbas na `godebug` directive) na sinundan ng restart. Kung hindi ginagamit ang MPTCP, itakda ang `net.mptcp.enabled=0` at kumpirmahin na walang natitirang listeners. I-record ang kasalukuyang kernel version at ang advisory status ng distribusyon upang maipasok ang kalaunan na package nang walang karagdagang discovery work. Maaaring makumpleto ang mga aksyong ito sa loob ng ilang oras sa karamihan ng mga fleet at bumili ng oras habang inihahanda ang vendor kernels.
Para sa mga team na nagpapatakbo ng Go workloads sa Kubernetes, ang episode ay isang paalala na nananatiling responsibilidad ng operator ang node-kernel currency kahit pagkatapos na maipasok ang isang service mesh. Patuloy na mahalaga ang mesh controls para sa maraming iba pang mga banta. Hindi sila kapalit para sa kernel update o para sa short-term na pagtanggal ng napatunayang MPTCP surface. Ang mga organisasyon na itinuturing ang host operating system lifecycle bilang isang first-class platform concern ay sumisipsip sa ganitong uri ng isyu nang may mas kaunting pagkagambala. Ang mga patuloy na itinuturing itong isang external dependency ay patuloy na matutuklasan, pagkatapos ng publication, na ang window para sa tahimik na remediation ay lumiit na. Ang praktikal na susunod na hakbang ay patakbuhin ang inventory ngayon at ilagay ang Ubuntu at RHEL kernel packages sa critical path sa sandaling lumitaw ang mga ito.
Mga Sanggunian
The Hacker News, “Linux Kernel TCP Flaw With 9.8 CVSS Score Affects Ubuntu, Red Hat and Other Distributions”, 29 Oktubre 2026.
Anthropic Frontier Red Team research disclosure (na-re-reference sa maraming contemporaneous reports), 27 Oktubre 2026.
Go security team notice sa golang-announce / oss-security tungkol sa CVE-2026-98432 at MPTCP defaults, 29 Oktubre 2026.
Linux kernel CVE record para sa CVE-2026-98432 (kernel.org CNA).
Ubuntu CVE tracker at Red Hat CVE pages para sa CVE-2026-98432 (status noong unang bahagi ng Nobyembre 2026).
Distribution advisories mula sa Debian, Oracle Linux, Amazon Linux at SUSE para sa fixed packages.