Pada 6 Agustus 2026, Tencent Zhuque Lab mempublikasikan riset mengenai sebuah kerentanan serius pada Linux kernel yang mereka beri nama SCTPhantom. Celah ini dilacak sebagai CVE-2026-64564 dan berada pada implementasi SCTP Dynamic Address Reconfiguration, khususnya jalur ASCONF (Association Configuration Change). Dalam riset tersebut, Tencent menyatakan bug dapat berkembang dari use-after-free menjadi local privilege escalation hingga memperoleh akses root, bahkan container-to-host escape pada sistem uji tertentu [1].
Kasus ini menarik karena persoalannya bukan hanya tingkat dampak, melainkan juga usia bug. Menurut Tencent, rangkaian kondisi rentan tersebut telah lengkap sejak Linux 2.6.25 melalui commit 42e30bf3463c pada Desember 2007. Dengan publikasi riset pada Agustus 2026, umur bug itu kira-kira mencapai 18 tahun [1]. Ini menunjukkan satu pelajaran penting: pada sistem sebesar Linux kernel, cacat kecil dalam pengelolaan siklus hidup objek dapat bertahan sangat lama jika berada di jalur kode yang jarang diperiksa atau hanya aktif pada kombinasi state tertentu.
Secara praktis, SCTPhantom juga menegaskan bahwa keamanan Linux modern tidak dapat dinilai hanya dari permukaan. Bug yang tampak sempit, berada pada fitur jaringan yang tidak umum, dapat berubah menjadi kerentanan bernilai tinggi ketika penyerang mampu memanipulasi memori kernel secara presisi. Karena Linux kernel berada pada lapisan privilege tertinggi, keberhasilan eksploitasi tidak lagi terbatas pada crash, tetapi dapat merambat ke pengambilalihan kredensial, bypass mitigasi, dan runtuhnya isolasi container [1].
Untuk memahami akar masalahnya, terlebih dahulu perlu dipahami apa itu SCTP. SCTP adalah singkatan dari Stream Control Transmission Protocol, yaitu protokol transport berbasis IP yang secara kelas berada di area yang mirip dengan TCP dan UDP. Dokumentasi resmi Linux mendeskripsikannya sebagai protokol message-oriented, reliable, mendukung congestion control, multihoming yang transparan, serta beberapa aliran pesan terurut dalam satu asosiasi komunikasi [2].
Berbeda dari TCP yang lazim dipahami sebagai koneksi antara dua endpoint utama, SCTP dirancang agar satu asosiasi dapat melibatkan beberapa alamat IP. Kemampuan ini lazim disebut multihoming. Dalam praktiknya, sebuah server bisa memiliki beberapa alamat IP dan klien juga bisa memiliki lebih dari satu jalur. Jika salah satu jalur gagal, asosiasi masih dapat beralih ke jalur lain tanpa harus kehilangan seluruh sesi komunikasi [2]. Karakteristik ini membuat SCTP relevan untuk sistem yang menuntut ketersediaan tinggi, termasuk sebagian infrastruktur telekomunikasi.
Kerentanan SCTPhantom tidak berada pada keseluruhan SCTP, melainkan pada fitur spesifik bernama Dynamic Address Reconfiguration. Fitur ini memungkinkan alamat IP yang menjadi bagian dari sebuah asosiasi SCTP ditambah, dihapus, atau diubah ketika komunikasi masih berlangsung. Standar perilaku tersebut didefinisikan dalam RFC 5061, yang menjelaskan mekanisme untuk menambah, menghapus, dan mengubah alamat pada asosiasi SCTP melalui ASCONF chunk [5]. Dokumentasi keamanan kernel Linux juga menjelaskan bahwa ketika fitur ini aktif, perubahan alamat ditangani menggunakan parameter SCTP tertentu dan ASCONF [3].
Di sinilah SCTPhantom muncul. Menurut Tencent, akar masalah teknisnya terkait inkonsistensi identitas antara alamat sumber paket IPv4 dan Address Parameter ASCONF yang dipakai kernel untuk memilih transport SCTP. Tencent menjelaskan urutan rentan berupa [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0]. Dalam skenario tersebut, transport SCTP yang sedang dipilih dapat dihapus, tetapi association masih mempertahankan pointer lama pada primary_path dan active_path. Saat operasi socket berikutnya memakai pointer tersebut, terjadilah dereferensi terhadap pointer usang, yaitu kondisi use-after-free di kernel [1].
Secara konseptual, bayangkan sebuah association SCTP memiliki beberapa objek transport. Salah satu transport dipilih sebagai jalur aktif. Lalu datang permintaan ASCONF yang menyebabkan transport itu dihapus. Memori objek transport kemudian dikembalikan ke allocator kernel. Masalahnya, bagian lain dari association masih menyimpan referensi ke lokasi memori lama. Pointer itu belum dihapus atau diperbarui, padahal objek yang dirujuk sudah tidak valid lagi. Ketika pointer stale tersebut dipakai kembali, kernel membaca atau memproses memori yang seharusnya sudah bebas digunakan untuk objek lain [1].
Inilah definisi sederhana dari use-after-free. Pada perangkat lunak native seperti kernel, sebuah objek dibuat, lalu dibebaskan, tetapi pointer terhadap objek itu masih digunakan kemudian. Risiko utamanya adalah area memori yang sama bisa diisi oleh objek lain. Jika pengisian ulang itu dapat dipengaruhi penyerang, kernel dapat tertipu untuk memperlakukan data baru sebagai objek lama. Dari sudut pandang eksploitasi, ini adalah pintu masuk yang sangat berharga karena bug tidak lagi sebatas kesalahan logika, tetapi telah berubah menjadi korupsi memori.
Namun penting untuk membedakan antara fakta dan interpretasi. Fakta yang didukung riset adalah adanya transport use-after-free di jalur SCTP ASCONF dan keberhasilan Tencent mengembangkannya menjadi root serta container escape pada sistem uji tertentu [1]. Analisis yang dapat ditarik dari fakta itu adalah bahwa nilai bug menjadi sangat tinggi bukan semata karena keberadaan UAF, melainkan karena UAF tersebut dapat dipadukan dengan teknik eksploitasi kernel modern. Jadi, bahaya sesungguhnya lahir dari kombinasi bug inti dan kemampuan membangun exploit chain.
Tencent memaparkan rantai eksploitasi yang berkembang dari UAF transport SCTP menjadi beberapa primitive penting. Secara garis besar, rangkaiannya meliputi upaya merebut kembali slot memori yang telah dibebaskan, memperoleh kebocoran halaman direct-map, membangun primitive pembacaan kernel 4-byte yang dapat diulang, memulihkan KASLR melalui informasi berbasis IDT, menyusun controlled kernel object graph, lalu memanggil commit_creds() untuk memperoleh root [1]. Bagi pembaca non-spesialis, poin paling penting di sini adalah bahwa UAF tidak otomatis berarti root, tetapi pada kasus ini Tencent menunjukkan bahwa eskalasi tersebut memang dapat dicapai.
Tahap pertama biasanya adalah heap reclaim. Ketika kernel memanggil pembebasan objek transport, slot memori itu kembali ke allocator. Jika penyerang mampu mendorong kernel membuat objek lain dengan ukuran dan karakteristik alokasi yang cocok, ada peluang besar slot yang sama akan dipakai kembali. Begitu itu terjadi, pointer lama pada association masih menunjuk ke lokasi yang sama, tetapi isi lokasinya sudah berubah. Dengan kata lain, kernel masih percaya bahwa ia sedang berinteraksi dengan objek transport SCTP, padahal yang sebenarnya dibaca adalah objek pengganti yang penempatannya telah diarahkan penyerang [1].
Tahap berikutnya adalah membocorkan alamat kernel. Linux modern memakai KASLR, Kernel Address Space Layout Randomization, agar alamat runtime kernel tidak mudah diprediksi. Tujuan mitigasi ini sederhana: meski penyerang menemukan bug, ia tetap kesulitan memanggil fungsi sensitif atau menulis ke struktur penting karena tidak tahu alamat tepatnya. Akan tetapi, ketika UAF berhasil dipaksa membaca data yang mengandung pointer kernel, mitigasi itu mulai tergerus. Tencent menjelaskan bahwa eksploit mereka dapat berkembang hingga mendapatkan primitive kebocoran dan pembacaan memori kernel yang berguna untuk memulihkan tata letak alamat runtime [1].
Setelah alamat tertentu bocor, penyerang dapat menghitung KASLR slide, yaitu selisih antara alamat runtime dan tata letak yang diharapkan dari build kernel. Dari sana, alamat fungsi kernel lain dapat dihitung secara lebih akurat. Dalam konteks eksploitasi privilege escalation Linux, fungsi seperti commit_creds() dan struktur kredensial proses menjadi target yang sangat penting. Tencent menyebut bahwa mereka berhasil menggunakan primitive yang dibangun untuk berujung pada pemanggilan commit_creds() guna memperoleh akses root [1].
Pada tahap ini, efeknya tidak lagi abstrak. Linux menyimpan identitas proses, seperti UID, GID, dan kapabilitas, di struktur kredensial kernel. Proses milik pengguna biasa umumnya berjalan dengan UID nonnol, sedangkan root memiliki UID 0. Begitu struktur kredensial dapat dimanipulasi atau diganti dengan kredensial yang berprivilege, hasil akhirnya adalah eskalasi hak akses penuh pada sistem. Karena bug ini berada di kernel, keberhasilan tersebut berarti batas antara user biasa dan administrator praktis runtuh [1].
Bagian yang paling mengkhawatirkan adalah implikasinya terhadap container. Container seperti Docker tidak membawa kernel sendiri, melainkan berbagi kernel host. Ini berbeda dengan VM, yang memiliki kernel tamu tersendiri di atas lapisan hypervisor. Konsekuensinya jelas: jika penyerang telah berada di dalam container dan berhasil mengeksploitasi kerentanan kernel host, isolasi container bisa jebol. Dalam istilah yang lebih tepat, bug kernel menjadi jalur dari ruang proses tenant ke privilege host [1].
Tencent menyatakan bahwa rantai eksploitasi mereka dapat berakhir dengan call_usermodehelper_exec() sehingga aksi dijalankan di initial namespaces host. Mereka juga menulis bahwa pada skenario uji container, profil seccomp default tetap dipertahankan dan tidak diberikan CAP_NET_ADMIN maupun CAP_SYS_ADMIN; hasilnya, enam dari delapan percobaan mencapai host root, sedangkan dua sisanya gagal tanpa memicu kernel panic [1]. Ini adalah klaim yang sangat signifikan, tetapi harus dibaca dengan hati-hati: fakta tersebut berlaku pada sistem uji mereka, bukan bukti bahwa semua container Linux otomatis dapat di-escape.
Batasan ini penting karena eksposur nyata sangat bergantung pada konfigurasi. Tencent sendiri menekankan faktor-faktor seperti ketersediaan SCTP, akses ke raw atau packet socket, kebijakan user namespace, seccomp, capabilities, dan kebijakan LSM seperti AppArmor atau SELinux [1]. Oleh sebab itu, artikel yang akurat tidak boleh menyederhanakan masalah menjadi “Docker rentan” atau “semua container dapat ditembus”. Kerentanannya berada pada Linux kernel; platform container hanya ikut relevan karena berbagi kernel host yang sama.
Dalam konteks operasional, implikasi terbesar terasa pada lingkungan multi-tenant. Server yang menjalankan banyak container pelanggan, CI/CD runner, platform PaaS, atau sandbox developer sering menjadikan container sebagai batas utama antarbeban kerja. Model ini efisien, tetapi kelemahannya adalah semua tenant tetap bertumpu pada satu kernel host. Jika boundary itu berhasil ditembus, dampaknya dapat melampaui satu aplikasi. Karena itulah, untuk workload yang benar-benar tidak terpercaya, container sebaiknya tidak dianggap sebagai batas keamanan absolut.
Menariknya, akar bug yang sangat tua ini tampaknya dapat diperbaiki melalui perubahan yang secara konsep relatif kecil. Riset Tencent menyebut bug telah diperbaiki upstream melalui commit mainline 9b2854f86f0b [1]. Walaupun detail patch kernel tidak perlu disederhanakan berlebihan, pelajaran umum yang dapat diambil adalah bahwa eksploit yang rumit tidak selalu berasal dari kesalahan kode yang panjang. Sering kali, sumbernya hanyalah validasi siklus hidup objek yang terlewat: objek yang masih dipakai tidak boleh dihapus, atau pointer yang menyimpan referensinya wajib segera diperbarui.
Admin sistem juga perlu memahami satu hal yang sering disalahpahami: apakah fitur terkait aktif secara default. Dokumentasi sysctl kernel Linux menyatakan bahwa net.sctp.addip_enable, pengendali fitur ADD-IP atau Dynamic Address Reconfiguration menurut RFC 5061, memiliki nilai 0 untuk disabled dan 1 untuk enabled, dengan default 0 [4]. Parameter net.sctp.addip_noauth_enable juga memiliki default 0 [4]. Artinya, pada dokumentasi kernel, fitur rentan ini tidak serta-merta aktif secara default.
Namun fakta itu tidak boleh ditafsirkan sebagai alasan untuk menunda patch. Pertama, konfigurasi aktual bisa berbeda antarhost. Kedua, modul SCTP sendiri mungkin tetap tersedia atau dimuat. Ketiga, vendor distribusi dapat membawa konfigurasi, backport, atau penyesuaian yang tidak identik dengan mainline. Keempat, mitigasi konfigurasi hanya mengurangi permukaan serangan, bukan menghapus bug di kernel. Karena itu, pendekatan yang benar tetap menempatkan pembaruan kernel sebagai solusi utama, sedangkan mematikan fitur atau modul diperlakukan sebagai defense in depth [1][4].
Untuk pemeriksaan awal, administrator dapat memverifikasi versi kernel aktif dengan uname -r atau uname -a, lalu mengidentifikasi distribusi dengan cat /etc/os-release. Tetapi ada catatan penting: status aman atau rentan tidak boleh ditentukan hanya dengan membandingkan nomor versi terhadap cabang mainline. Tencent sendiri mengingatkan bahwa vendor kernel kerap melakukan backport, sehingga kernel enterprise dengan nomor versi lama bisa saja sudah memuat patch keamanan yang setara [1]. Dengan kata lain, yang lebih penting adalah advisory resmi vendor distribusi.
Jika ingin menilai relevansi SCTP pada host, admin dapat memeriksa apakah modulnya dimuat melalui lsmod | grep sctp dan melihat informasi modul dengan modinfo sctp. Bila server tidak mempunyai kebutuhan SCTP, keberadaan modul tersebut layak dievaluasi. Untuk konfigurasi fitur Dynamic Address Reconfiguration, pemeriksaan dapat dilakukan dengan sysctl net.sctp.addip_enable dan sysctl net.sctp.addip_noauth_enable. Sesuai dokumentasi kernel, bila tidak diperlukan, keduanya sebaiknya tetap bernilai 0 [4].
RFC 5061 dan dokumentasi kernel juga mendukung alasan keamanan di balik pengaturan tersebut. RFC 5061 mendefinisikan perubahan alamat SCTP melalui ASCONF [5], sedangkan dokumentasi keamanan Linux menjelaskan bahwa dukungan Dynamic Address Reconfiguration memakai parameter khusus dan bahwa perubahan itu berhubungan dengan ASCONF chunk [3]. Dokumentasi sysctl menegaskan bahwa mode tanpa autentikasi seharusnya tidak menjadi pilihan umum; ADD-IP idealnya dilindungi autentikasi agar host yang tidak sah tidak dapat melakukan pembajakan terhadap association, dan mode tanpa autentikasi terutama ditujukan untuk interoperabilitas dengan implementasi lama pada lingkungan tertutup [4].
Dari sisi remediasi, prioritas pertama adalah memperbarui kernel dari repository resmi distribusi dan melakukan reboot. Ini poin penting karena pada Linux, menginstal paket kernel baru tidak otomatis berarti kernel baru sudah berjalan. Host tetap akan memakai kernel lama sampai reboot dilakukan. Setelah itu, verifikasi ulang dengan uname -r. Tencent juga menyebut sejumlah versi perbaikan pada beberapa cabang upstream, tetapi untuk operasional sehari-hari lebih aman mengandalkan pernyataan vendor distro masing-masing daripada menebak status aman dari nomor versi mentah [1].
Langkah berikutnya adalah mengurangi permukaan serangan. Jika SCTP tidak digunakan, admin dapat mempertimbangkan untuk melepas modul dengan modprobe -r sctp dan melakukan blacklist modul, tetapi hanya setelah memastikan tidak ada aplikasi atau infrastruktur yang membutuhkannya. Ini sangat penting pada sistem telekomunikasi atau jaringan tertentu, karena SCTP dapat menjadi komponen yang sah dan memang diperlukan [2]. Jadi, keputusan mematikan modul bukan kebijakan universal, melainkan keputusan berbasis kebutuhan operasional.
Selain itu, pertahankan net.sctp.addip_enable=0 dan net.sctp.addip_noauth_enable=0 bila tidak ada kebutuhan khusus terhadap Dynamic Address Reconfiguration. Pengaturan ini dapat dijalankan sementara lewat sysctl -w dan dibuat persisten lewat konfigurasi sysctl. Meski demikian, sekali lagi perlu ditekankan bahwa ini hanyalah lapisan tambahan. Jika vendor sudah merilis perbaikan untuk CVE-2026-64564, patch kernel tetap menjadi tindakan utama [1][4].
Untuk lingkungan container, pengerasan standar tetap relevan. Hindari menjalankan container dengan --privileged kecuali benar-benar diperlukan. Jangan memberikan capability seperti CAP_SYS_ADMIN atau CAP_NET_ADMIN tanpa alasan yang jelas. Pertahankan profil seccomp default atau gunakan profil yang lebih ketat, dan jangan menonaktifkannya sembarangan. LSM seperti AppArmor atau SELinux juga patut dijaga tetap aktif karena dokumentasi kernel menjelaskan SCTP memiliki hook integrasi dengan LSM [3]. Lapisan-lapisan ini mungkin tidak menjamin keselamatan terhadap semua exploit kernel, tetapi dapat mempersempit kondisi yang diperlukan penyerang.
Pada penyedia hosting atau PaaS self-hosted seperti lingkungan yang dibangun di atas Docker, Dokploy, atau Coolify, ada satu pemahaman yang harus dijaga tetap jelas. SCTPhantom bukan kerentanan Dokploy, bukan pula kerentanan Docker. Masalahnya berada pada Linux kernel. Namun karena platform-platform tersebut bergantung pada kernel host yang sama, kerentanan kernel tetap memiliki dampak langsung pada seluruh lapisan layanan. Jika model bisnis memungkinkan pengguna menjalankan kode arbitrer milik mereka sendiri pada host yang sama, maka ancaman yang relevan bukan lagi sekadar kerusakan aplikasi, melainkan potensi runtuhnya isolasi antar-tenant.
Dalam skenario seperti itu, pendekatan keamanan yang lebih matang adalah membangun boundary tambahan. Untuk workload milik sendiri yang relatif tepercaya, model container pada satu host mungkin memadai. Tetapi untuk hostile multi-tenant workload, pertimbangan seperti VM, microVM, atau isolasi berbasis hypervisor menjadi lebih masuk akal. Alasannya sederhana: bila exploit kernel terjadi di guest, masih ada boundary berikutnya yang harus ditembus. Ini adalah prinsip defense in depth yang kembali terbukti relevan oleh kasus SCTPhantom.
Riset Tencent juga menarik karena menyinggung penggunaan Corvus AI dalam proses penelitian [1]. Fakta ini menunjukkan perubahan penting dalam dunia keamanan: AI tidak lagi semata dipakai untuk menulis kode atau membantu dokumentasi, tetapi mulai masuk ke alur kerja riset kerentanan yang lebih maju, seperti membaca source code kernel, membangun hipotesis, menyusun PoC, menganalisis crash, dan mengulangi eksperimen. Meski rincian kontribusi AI pada setiap tahap tidak dijelaskan secara lengkap dalam bahan yang tersedia di sini, sinyal umumnya jelas: biaya pencarian bug dan eksplorasi exploit berpotensi turun seiring meningkatnya otomasi.
Namun pada titik ini, perlu disampaikan keterbatasan secara jujur. Daftar versi yang telah diperbaiki dan detail eksploitasi yang sangat spesifik terutama bersumber dari artikel teknis Tencent [1]. Bahan yang tersedia di sini tidak menyertakan advisory vendor dari semua distribusi Linux besar secara seragam. Karena itu, tidak tepat jika artikel ini menyatakan distro tertentu pasti aman atau pasti rentan tanpa tautan advisori resmi masing-masing. Sikap yang paling akurat adalah mendorong pembaca mengecek vendor kernel atau distribusi yang mereka gunakan.
Jika diringkas, pelajaran teknis dari SCTPhantom cukup tegas. Pertama, bug jaringan yang terlihat niche dapat berubah menjadi kerentanan kernel bernilai tinggi ketika terletak pada jalur pengelolaan objek yang salah. Kedua, exploit modern sangat bergantung pada penggabungan beberapa primitive kecil: heap reclaim, kebocoran pointer, pembacaan memori, pemulihan KASLR, lalu manipulasi kredensial. Ketiga, keberadaan container tidak menghapus risiko kernel; ia hanya menambahkan satu lapisan isolasi yang tetap bergantung pada kesehatan kernel host. Keempat, konfigurasi default yang tampak aman bukan pengganti patch, terutama pada sistem produksi dengan permukaan serangan yang dinamis.
Bagi administrator Linux, prioritas mitigasi praktis dapat dirangkum sebagai berikut:
- Perbarui kernel dari repository resmi distribusi dan lakukan reboot.
- Cek advisory resmi vendor untuk CVE-2026-64564; jangan menilai status hanya dari nomor versi kernel.
- Periksa apakah modul SCTP dimuat dan apakah benar-benar dibutuhkan.
- Pertahankan net.sctp.addip_enable=0 bila Dynamic Address Reconfiguration tidak diperlukan.
- Pertahankan net.sctp.addip_noauth_enable=0.
- Hindari container privileged dan capability berlebihan.
- Aktifkan serta pertahankan seccomp, AppArmor, atau SELinux.
- Untuk multi-tenant yang menjalankan kode tidak terpercaya, pertimbangkan VM atau microVM sebagai boundary tambahan.
- Verifikasi bahwa kernel yang sudah diperbarui benar-benar aktif setelah reboot.
Pada akhirnya, SCTPhantom adalah contoh jelas bagaimana kesalahan kecil dalam object lifecycle kernel dapat berkembang dari dangling pointer menjadi use-after-free, lalu naik menjadi kebocoran memori, bypass KASLR, manipulasi kernel, eskalasi hak akses, hingga potensi container escape [1]. Umur bug yang diduga mencapai sekitar 18 tahun memperlihatkan betapa sulitnya mengaudit seluruh ruang keadaan dari kode kernel yang besar dan kompleks. Bagi operator cloud, hosting, Kubernetes, CI/CD runner, dan platform yang mengeksekusi aplikasi pihak ketiga, pesan utamanya sangat tegas: container bukan pengganti patch kernel, dan bukan pula batas keamanan absolut.
Kesimpulan praktisnya sederhana: patch kernel host secepatnya, reboot, kurangi permukaan serangan, nonaktifkan fitur SCTP terkait bila tidak dibutuhkan, dan bangun isolasi berlapis untuk workload yang tidak terpercaya. Untuk lingkungan berbasis container, memutakhirkan image aplikasi saja tidak cukup bila kerentanannya berada pada kernel host yang sama-sama dipakai oleh semua container. Dalam kasus seperti SCTPhantom, prioritas pertama tetap host kernel, bukan kosmetik di lapisan atas.
Sumber referensi:
- [1] Tencent Zhuque Lab, “SCTPhantom: An 18-Year-Old SCTP ASCONF Transport Use-After-Free” — https://matrix.tencent.com/en/2026/08/06/sctphantom-CVE-2026-64564
- [2] Linux Kernel Documentation, “SCTP” — https://cdn.kernel.org/doc/html/latest/networking/sctp.html
- [3] Linux Kernel Documentation, “SCTP” Security Documentation — https://www.kernel.org/doc/html/v6.8/security/SCTP.html
- [4] Linux Kernel Documentation, “IP Sysctl” — https://www.kernel.org/doc/html/latest/networking/ip-sysctl.html
- [5] RFC 5061, “Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration” — https://www.rfc-editor.org/info/rfc5061/