Kenapa MPTCP Default di Go 1.24 Bikin Host Linux Kebobolan CVE-2026-98432

Waktu tim riset Anthropic mendemokan Claude bisa merakit exploit remote root lewat TCP mentah, reaksi awal kebanyakan engineer infra biasanya santai. Gue sendiri sempat mengira ini isu minor yang dampaknya terbatas.

Celah keamanannya tercatat sebagai CVE-2026-98432 dengan skor Common Vulnerability Scoring System (CVSS) 9.8. Target serangannya spesifik ke listener Multipath TCP (MPTCP).

Nasihat awalnya terdengar sederhana. Kalau armada server lo cuma menjalankan web server TCP biasa, lo nggak bakal menyentuh subflow MPTCP. Jadi lo merasa cukup menunggu patch kernel resmi dari distro Linux.

Lalu Go Security Team merilis buletin resmi tanggal 30 Oktober kemarin.

Mulai versi Go 1.24, runtime Go ternyata diam-diam menyalakan MPTCP di semua socket listen TCP selama kernel Linux mengizinkannya. Kalau lo memasang Caddy di depan aplikasi produksi seperti Dagango.com, atau deploy microservice Go di distro modern, server lo sudah membuka jalur MPTCP berbulan-bulan.

Lo mendadak masuk ke celah berbahaya di kernel tanpa pernah mengubah satu baris pun file konfigurasi.

Di Balik Race Condition Kernel

Celah asli di kernel Linux ini ada di alur pemrosesan handshake TCP IPv4.

Saat client memulai koneksi, kernel mengalokasikan request socket sementara untuk mencatat status half-open. Kernel membaca opsi IPv4 (ireq_opt) dari paket TCP SYN agar bisa dikirim balik di respon SYN-ACK.

Pada TCP standar, penutupan socket mengikuti siklus ketat. MPTCP mengubah dinamika ini karena mengizinkan satu koneksi logis mengikat banyak subflow lewat berbagai interface jaringan.

Saat socket berpindah atau ditutup mendadak, kernel membebaskan buffer opsi lewat pemanggilan standar:

kfree(ireq->opt);

Fungsi kfree() inilah yang memicu celah Use-After-Free (UAF). Saat satu core Central Processing Unit (CPU) membebaskan memori opsi, core lain ternyata masih membaca alamat yang sama untuk merakit paket SYN-ACK keluar.

Maintainer kernel upstream, Eric Dumazet, menambal masalah ini cuma dengan empat baris kode di net/ipv4/af_inet.c dan net/ipv4/tcp_ipv4.c.

Solusinya mengganti pembebasan instan tadi dengan mekanisme Read-Copy-Update (RCU):

kfree_rcu(ireq->opt, rcu);

Lewat pemanggilan kfree_rcu(), kernel menjamin buffer memori tetap valid sampai seluruh operasi baca di core lain selesai melewati masa grace period.

Kenapa Exploit Berbasis AI Mengubah Peta Ancaman

Bug balapan memori di network stack kernel biasanya susah dieksploitasi lewat jaringan fisik. Balapan yang meleset biasanya langsung memicu kernel panic dan menyalakan alarm monitoring.

Peneliti Anthropic, Xinyang Ge, membuktikan celah ini mematahkan anggapan itu.

Model riset internal mereka menemukan karakteristik operasional unik dari celah ini:

• Percobaan balapan memori yang gagal sama sekali nggak bikin kernel panik.
• Paket yang gagal bersaing di memori cuma dibuang atau dibalas dengan TCP reset biasa.
• Mesin penyerang cuma gagal menyambung, sedangkan server target tetap hidup normal.

Perilaku ini memberi penyerang kesempatan mencoba tanpa batas.

Script exploit bisa menyemprotkan ribuan handshake palsu berisi opsi IPv4 manipulasi. Karena kegagalan nggak merusak sistem operasi, penyerang leluasa menebak struktur memori sampai balapan berhasil dimenangkan.

Begitu buffer terisi data penyerang, mereka mendapat akses root penuh tanpa autentikasi.

Di forum Hacker News, topik ini menembus 438 poin dan 204 komentar dalam hitungan jam. Komunitas infra langsung sadar ini bukan sekadar bug di atas kertas, melainkan exploit remote root yang stabil di socket publik.

Jebakan Default di Level Runtime Bahasa

Banyak tim infrastruktur mengira mereka kebal karena nggak pernah menyalakan MPTCP di kode aplikasi mereka.

Masalahnya, Go 1.24 mengambil keputusan itu tanpa permisi.

Saat aplikasi lo memanggil net.Listen("tcp", ":443"), runtime Go langsung mengecek apakah kernel Linux di host mengaktifkan dukungan MPTCP. Jika kernel mengizinkan, Go meminta socket MPTCP ke kernel daripada socket standar IPPROTO_TCP.

Di server produksi, keputusan ini menciptakan pergeseran arsitektur yang tersembunyi:

• Developer menulis kode HTTP server Go biasa.
• Paket net bawaan Go meminta socket IPPROTO_MPTCP ke kernel Linux.
• Kernel Linux langsung membuka state machine subflow MPTCP untuk paket luar.
• Host lo langsung rentan terhadap manipulasi memori sebelum aplikasi sempat membaca request.

Secara teori, lo bisa mematikan fitur ini per aplikasi lewat environment variable:

export GODEBUG=multipathtcp=0

Tapi mengandalkan variabel GODEBUG di puluhan container dan unit systemd jelas rapuh. Kalau ada satu service baru lupa dipasangi variabel ini saat deploy, seluruh host kembali terbuka.

Menurut gue, kebijakan keamanan harus ditegakkan di level sistem operasi dan firewall, bukan diserahkan ke variabel aplikasi.

Keterlambatan Distro Bikin Server Tetap Terbuka

Maintainer kernel Linux upstream bergerak cepat merilis kernel stabil yang sudah ditambal antara 11 dan 15 Oktober kemarin:

• 5.10.272
• 6.1.190
• 6.6.159
• 6.12.113
• 7.2.10

Distro enterprise punya cerita berbeda.

Sampai 31 Oktober, pelacak keamanan Ubuntu masih mencatat seluruh rilis Long-Term Support (LTS) aktif (termasuk 22.04, 24.04, dan 26.04) berstatus "Vulnerable" dengan proses patch yang masih berjalan. Red Hat menaikkan status masalah ini ke level Critical di buletin RHSB-2026-016, tapi paket resminya belum merata.

Host Ubuntu menyalakan fitur MPTCP secara default sejak awal instalasi:

$ sysctl net.mptcp.enabled
net.mptcp.enabled = 1

Kalau armada server lo memakai Ubuntu dan menjalankan binary hasil compile Go 1.24, mesin lo saat ini dalam posisi terbuka.

Cara Audit dan Mitigasi di Host Hari Ini

Lo nggak perlu menunggu rilis paket kernel dari distro. Lo bisa memeriksa sekaligus mengamankan server sekarang juga.

Pertama, periksa apakah ada proses di host yang sedang membuka socket MPTCP aktif:

ss -Mlnp

Kalau perintah itu menampilkan baris socket, service lo aktif terpapar ke jaringan luar lewat MPTCP.

Untuk menutup celah ini seketika tanpa perlu reboot mesin, jalankan dua langkah mitigasi berikut.

1. Matikan MPTCP Kernel Secara Global

Matikan dukungan MPTCP di level kernel untuk seluruh interface jaringan:

sudo sysctl -w net.mptcp.enabled=0
echo "net.mptcp.enabled = 0" | sudo tee /etc/sysctl.d/99-disable-mptcp.conf

Nilai sysctl ini mencegah pembuatan socket MPTCP baru di sistem operasi.

Namun, socket yang sudah terlanjur dibuat di memori kernel tetap berjalan. Lo wajib me-restart service Go, reverse proxy Caddy, dan container daemon agar socket lama benar-benar ditutup.

2. Drop Paket SYN yang Membawa Opsi IPv4 via nftables

Payload exploit jarak jauh ini memanfaatkan opsi IPv4 saat handshake pertama untuk mengontrol memori kernel yang bebas.

Lalu lintas web normal di internet modern hampir nggak pernah memakai opsi IPv4. Panjang header IPv4 standar selalu 20 byte, yang berarti nilainya 5 dalam hitungan kata 32-bit. Jika panjang header lebih dari 5, paket tersebut dipastikan membawa opsi tambahan.

Lo bisa membuang paket mencurigakan ini langsung di chain prerouting sebelum subsistem connection tracking mengalokasikan memori:

table inet filter {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        tcp flags syn ip hdrlength gt 5 counter drop
    }
}

Aturan firewall ini menolak paket exploit di level kartu jaringan sebelum sempat disentuh oleh logika handshake TCP.

Catatan Penutup

Runtime bahasa pemrograman sebaiknya nggak mengambil keputusan arsitektur sepihak yang memperluas attack surface kernel.

Niat Go memodernisasi protokol transport memang masuk akal. Tapi memaksa setiap HTTP listener masuk ke subsistem kernel yang rumit terbukti membuka celah di ribuan server produksi.

Jalankan perintah ss -Mlnp di server lo hari ini. Matikan net.mptcp.enabled di level host, blokir paket SYN dengan opsi tambahan di perimeter, dan jangan pernah berasumsi bahwa pemanggilan net.Listen() biasa hanya menyentuh TCP standar.