CVE-2026-98432: cek kernel Linux dan mitigasi celah TCP

Jawaban langsung: CVE-2026-98432 adalah celah use-after-free di jalur handshake TCP IPv4 kernel Linux 4.4 ke atas. Tim kernel memberi skor CVSS 9.8, dan Ubuntu kini memberi prioritas Critical. Per 7 November 2026, patch sudah rilis untuk RHEL 8, 9, 10 dengan kernel-rt, dan Ubuntu 26.10, tetapi belum untuk Ubuntu LTS. Hari ini, update dan reboot server yang sudah punya patch, lalu pasang mitigasi sementara di server Ubuntu LTS.

Pembaruan 7 November 2026: Ubuntu kini menandai patch Ubuntu 26.10 sebagai released di kernel 7.3.0-10.10, jadi update dan reboot server itu. Rilis LTS belum punya patch, dan status 20.04, 18.04, dan 16.04 naik dari "needed" ke "pending".

Pembaruan 6 November 2026: Red Hat kini mencatat patch kernel-rt RHEL 9 di RHSA-2026:93412 dari 1 November, jadi update dan reboot menggantikan langkah 4 di server itu. Red Hat juga merilis patch RHEL 8.6 AUS dan EUS Long-Life pada 4 November di RHSA-2026:94996.

Pembaruan 4 November 2026: Pada 3 November, Ubuntu menaikkan prioritas dari High ke Critical dan menyiapkan patch HWE 7.0 untuk 24.04, tetapi patch Ubuntu belum rilis. Red Hat merilis patch untuk RHEL EUS, AUS, TUS, dan E4S pada 2 dan 3 November, dan skrip langkah 2 kini mengenali kernel itu.

Pembaruan 3 November 2026: Red Hat merilis patch kernel untuk NVIDIA for RHEL 10 pada 2 November 2026 di RHSA-2026:93775, yaitu kernel 6.12.0-265.31.el10nv. Skrip di langkah 2 kini membandingkan kernel el10nv dengan versi itu.

Pembaruan 2 November 2026: Red Hat merilis patch kernel pada 1 November 2026 untuk RHEL 8 (RHSA-2026:93414), RHEL 9 (RHSA-2026:93412), dan RHEL 10 (RHSA-2026:93413). Kernel-rt RHEL 9 dan Ubuntu belum punya patch, jadi langkah 4 tetap berlaku untuk server itu.

Pembaruan 31 Oktober 2026, 08.10 WIB: Amazon Linux merilis patch untuk semua kernel Amazon Linux 2 dan Amazon Linux 2023, dengan tanggal 30 Oktober. Red Hat menaikkan skor ke 9.8 (Critical) dan menerbitkan buletin RHSB-2026-016 dengan mitigasi nftables, tetapi patch RHEL belum ada.

Peneliti Anthropic melaporkan celah ini. Menurut laporan Anthropic 27 Oktober, model Claude menulis PoC yang menjalankan perintah sebagai root dari jarak jauh, tanpa kredensial, di server dengan listener MPTCP. Program Go 1.24 ke atas membuat listener MPTCP secara default.

Kondisi utama: Debian, SUSE, Amazon Linux, RHEL 8, 9, 10, dan Ubuntu 26.10 sudah punya kernel dengan patch, jadi Anda update lalu reboot. Ubuntu LTS belum punya, jadi Anda pasang mitigasi di langkah 4. Batas: Mitigasi hanya mengurangi paparan. Artikel ini tidak memuat kode eksploit atau urutan serangan.

Kami membaca catatan CVE tim kernel, halaman CVE Ubuntu, tracker Debian, halaman CVE Red Hat, SUSE, Amazon Linux, laporan Anthropic 27 Oktober, dan peringatan Go Security Team pada 31 Oktober 2026, sekitar pukul 01.00 WIB. Perintah di langkah 1, 2, 4, dan 5 kami jalankan di container podman dengan image resmi golang, Ubuntu 24.04, Debian 12 dan 13, AlmaLinux 9, dan Fedora 44, dan di 1 host uji Fedora 44, pada tanggal yang sama. Server uji tidak memuat data pelanggan.

Masalah: patch upstream sudah ada, tetapi Ubuntu LTS belum merilis patch

Patch upstream masuk pada 5 Oktober 2026, tetapi per 7 November 2026 Ubuntu baru merilis kernel dengan patch untuk 26.10, belum untuk rilis LTS.

Menurut commit perbaikan e3f33b0a1d89, Eric Dumazet menulis perbaikan pada 1 Oktober 2026 dari laporan peneliti Anthropic. Tim kernel menerbitkan CVE pada 15 Oktober dan mencatat versi stabil yang aman.

Pada 27 Oktober, Anthropic mengumumkan PoC root dari jarak jauh. Dua hari kemudian, peringatan Go Security Team menyebarkan peringatan untuk semua program Go. Pada 30 Oktober, Amazon Linux merilis patch untuk semua kernel Amazon Linux 2 dan 2023.

Saat artikel ini terbit, status di halaman CVE Ubuntu untuk 22.04, 24.04, 26.04, dan 26.10 adalah "pending". Artinya patch sudah disiapkan, tetapi paket belum rilis. Ubuntu 20.04 dan lebih lama saat itu berstatus "needed" tanpa versi.

Saat artikel ini terbit, halaman CVE Red Hat menulis RHEL 8, 9, dan 10 terdampak, tanpa patch dan tanpa mitigasi yang memenuhi kriterianya. Pada 30 Oktober, buletin RHSB-2026-016 memberi label Critical, skor 9.8, dan 1 aturan nftables sebagai mitigasi. Pada 1 November, Red Hat merilis patch kernel untuk RHEL 8, 9, dan 10.

Pada 2 November, Red Hat merilis patch kernel untuk NVIDIA for RHEL 10 di RHSA-2026:93775. Saat itu halaman CVE Red Hat masih menandai kernel-rt RHEL 9 terdampak.

Pada 2 sampai 4 November, Red Hat merilis patch untuk rilis minor dengan dukungan panjang: RHEL 8.4, 8.6, 8.8, 9.2, 9.4, 9.6, dan 10.0. Pada 3 November, Ubuntu menaikkan prioritas ke Critical dan menyiapkan patch HWE 7.0 untuk 24.04, tetapi patch Ubuntu belum rilis.

Per 6 November, halaman CVE Red Hat tidak lagi menandai kernel-rt RHEL 9 terdampak. Errata RHSA-2026:93412 dari 1 November memuat paket kernel-rt 5.14.0-687.64.1.el9_8.

Per 7 November, halaman CVE Ubuntu menandai 26.10 "released" di kernel 7.3.0-10.10. Ubuntu 20.04, 18.04, dan 16.04 naik ke "pending", dan 16.04 menargetkan 4.4.0-293.327. Rilis itu sudah lewat dukungan standar, jadi patch datang lewat Ubuntu Pro.

Linimasa 2016 sampai 7 November 2026: Linux 4.4, patch upstream, CVE terbit, PoC Anthropic, peringatan Go, patch Amazon, mitigasi Red Hat, patch RHEL, dan patch Ubuntu 26.10. — Titik abu-abu: kode, patch, dan rilis. Titik merah: bukti root dan status tanpa patch. Titik teal: patch RHEL dan Ubuntu 26.10. Jarak dari patch upstream ke pengumuman PoC adalah 22 hari. Sumber: commit Linux, catatan CVE, Amazon Linux, Anthropic, Go Security Team, oss-security, Ubuntu, dan Red Hat.

Celah kernel bulan ini sudah 2 kali muncul di blog kami. Baca juga celah kernel PwnEscape dari VM ke host. Bedanya, CVE-2026-98432 bisa dipicu dari jaringan, bukan hanya dari VM di host yang sama.

Cara kerja: kernel membaca opsi IP dari memori yang sudah dibebaskan

Kernel memindahkan opsi IP dari koneksi yang sedang dibuka ke socket baru tanpa menyalinnya, lalu CPU lain bisa membaca opsi itu sesudah memorinya dibebaskan.

Bagian ini memakai ringkasan resmi. Tujuannya membantu Anda memilih langkah yang tepat, bukan menjelaskan cara menyerang.

Ringkasan dari catatan CVE

Menurut catatan CVE tim kernel, fungsi tcp_v4_syn_recv_sock() memberi opsi IP milik request socket kepada socket anak tanpa salinan. CPU lain masih bisa memakai opsi itu untuk mengirim SYN-ACK. Bila socket anak dibebaskan lebih dulu, kernel membaca memori yang sudah bebas di ip_options_build().

Ada jalur kedua lewat migrasi request socket. Jalur itu aktif bila net.ipv4.tcp_migrate_req=1 atau ada program BPF BPF_SK_REUSEPORT_SELECT_OR_MIGRATE. Perbaikan mengganti kfree() dengan kfree_rcu() di 2 fungsi. IPv6 tidak terdampak isu pertama.

Skenario CVSS dari tim kernel menulis bahwa data pemicu datang dari opsi header IPv4 Record Route atau Timestamp di paket SYN. Semua itu terjadi saat handshake, sebelum aplikasi meminta login.

Skor dari setiap lembaga

Skor berbeda per sumber, jadi tulis skor bersama sumbernya. Perbedaannya ada di 1 metrik: kompleksitas serangan.

Sumber	Skor	Kompleksitas serangan	Label
Tim kernel (CNA)	CVSS 3.1 9.8	Rendah (AC:L)	Critical
Ubuntu	CVSS 3 9.8	Rendah	Prioritas Critical (naik dari High pada 3 November)
Red Hat	CVSS 3.1 9.8 (naik dari 8.1 pada 30 Oktober)	Rendah (AC:L)	Critical
SUSE	CVSS 3.1 8.1, CVSS 4.0 9.2	Tinggi	Important
Amazon Linux	CVSS 3.1 8.1	Tinggi	Important

NVD belum memberi skor sendiri dan masih berstatus Received. SUSE dan Amazon menilai race ini sulit dipicu. Tim kernel menilai penyerang bisa mengulang percobaan tanpa batas, dan Red Hat kini juga memberi kompleksitas rendah.

Kartu merah CVE-2026-98432, use-after-free di handshake TCP IPv4, kartu amber PoC root Anthropic, skor 8.1 sampai 9.8, dan kotak teal: patch kernel, lalu reboot. — (1) Kartu merah: jenis celah dan ringkasan resmi. (2) Kartu amber: bukti dari Anthropic. (3) Baris skor: setiap lembaga memberi skor sendiri. (4) Kotak teal: hanya kernel baru dan reboot yang menutup celah. Sumber: catatan CVE tim kernel, Anthropic, Ubuntu, Red Hat, SUSE, Amazon Linux, dan CISA KEV.

Status eksploitasi per 31 Oktober 2026

CISA KEV belum memuat CVE ini di katalog 30 Oktober 2026. Kami tidak menemukan laporan serangan liar dari sumber primer. PoC Anthropic belum publik, dan Anthropic menulis bahwa detail eksploit tidak dirilis.

Analisa Rama Digital: PoC yang bekerja dari lembaga riset besar mengubah prioritas. Kelompok lain bisa membangun ulang eksploit dari patch publik. Untuk celah Node2Shell di decoder Brotli, jarak dari patch ke percobaan serangan pertama adalah 5 hari.

Siapa yang paling berisiko

Server yang menerima koneksi TCP dari internet lewat IPv4 paling berisiko, terutama server dengan listener MPTCP dari program Go 1.24 ke atas.

Tabel ini merangkum catatan CVE tim kernel, laporan Anthropic 27 Oktober, peringatan Go Security Team, dan halaman CVE Red Hat.

Kondisi server	Risiko	Alasan
Port publik dengan listener MPTCP, contoh API, proxy, atau tool self-hosted dari Go 1.24+	Tertinggi	Jalur yang dipakai PoC Anthropic
Port TCP publik lewat IPv4: web, SSH, API, database	Tinggi	Celah ada di handshake, sebelum login. Tim Go menulis bahwa bug tidak khusus MPTCP
Host Docker atau Kubernetes	Tinggi	Semua container memakai kernel host
VM di cloud atau VPS	Sama dengan server biasa	VM punya kernel sendiri. Patch di host penyedia tidak menambal VM Anda
`net.ipv4.tcp_migrate_req=1` atau program BPF migrate	Tambahan	Jalur kedua di catatan CVE
Hanya menerima IPv6, kernel di bawah 4.4, RHEL 6 dan 7	Rendah atau tidak terdampak	Catatan CVE dan Red Hat

Enam kartu risiko: listener MPTCP dan port TCP IPv4 publik merah, container, VM, dan migrasi request amber, lalu IPv6 saja dan kernel lama abu-abu, dengan perintah ss -HlnMp. — Kartu merah: server menerima koneksi dari internet. Kartu amber: tempat kernel yang sama dipakai atau jalur kedua aktif. Kartu abu-abu: risiko rendah. Kotak bawah: perintah untuk melihat listener MPTCP. Sumber: catatan CVE tim kernel, Anthropic, Go Security Team, dan Red Hat.

Listener [::] atau * biasanya juga menerima koneksi IPv4. Jadi hitung listener itu sebagai listener IPv4 saat Anda membaca hasil langkah 1.

Status patch per distro

Pakai tabel distro, bukan nomor kernel upstream, karena distro menambal kernel lama tanpa mengubah nomor versi utama.

Rilis	Status 7 November 2026	Versi atau catatan
Debian 12 (bookworm)	Patch tersedia	linux 6.1.190-1, linux-6.12 6.12.113-1~deb12u1
Debian 13 (trixie)	Patch tersedia	linux 6.12.113-1
SUSE SLES 15 SP4, SP5, SP6 LTSS, SLES 16.0	Patch tersedia	SP7 masih dikerjakan
Amazon Linux 2023	Patch tersedia	Kernel 6.1 bawaan (ALAS2023-2026-3365), kernel6.12, kernel6.18
Amazon Linux 2	Patch tersedia	Kernel inti (ALAS2-2026-4065) dan kernel Extra 5.4, 5.10, 5.15
RHEL 8	Patch tersedia	kernel 4.18.0-553.182.1.el8_10 (RHSA-2026:93414), kernel-rt (RHSA-2026:93415)
RHEL 9	Patch tersedia	kernel dan kernel-rt 5.14.0-687.64.1.el9_8 (RHSA-2026:93412)
RHEL 10	Patch tersedia	kernel 6.12.0-211.72.1.el10_2 (RHSA-2026:93413)
NVIDIA for RHEL 10	Patch tersedia	kernel 6.12.0-265.31.el10nv (RHSA-2026:93775)
RHEL 8.4 dan 8.6 AUS dan EUS Long-Life, 8.8 TUS dan E4S	Patch tersedia	kernel 4.18.0-305.218.1.el8_4 (RHSA-2026:94623), 4.18.0-372.227.1.el8_6 (RHSA-2026:94996), 4.18.0-477.178.1.el8_8 (RHSA-2026:94303)
RHEL 9.2 E4S, 9.4 E4S, 9.6 EUS	Patch tersedia	kernel 5.14.0-284.202.1.el9_2 (RHSA-2026:94477, kernel-rt RHSA-2026:94558), 5.14.0-427.161.1.el9_4 (RHSA-2026:94109), 5.14.0-570.154.1.el9_6 (RHSA-2026:94438)
RHEL 10.0 EUS	Patch tersedia	kernel 6.12.0-55.117.1.el10_0 (RHSA-2026:94508)
Ubuntu 26.10	Patch tersedia	kernel 7.3.0-10.10, status released per 7 November
Ubuntu 22.04 LTS	Disiapkan, belum rilis	5.15.0-203.213 (lowlatency 5.15.0-198.208), HWE 6.8.0-149.149~22.04.1
Ubuntu 24.04 LTS	Disiapkan, belum rilis	6.8.0-149.149, HWE 7.0.0-43.43~24.04.1. HWE 6.17 belum ada rencana
Ubuntu 26.04 LTS	Disiapkan, belum rilis	7.0.0-43.43
Ubuntu 20.04, 18.04, 16.04	Disiapkan, belum rilis	Lewat Ubuntu Pro. 16.04: 4.4.0-293.327. HWE 20.04: 5.15.0-203.213~20.04.1. Kernel 20.04 dan 18.04 tanpa versi. HWE 18.04 dan 16.04 belum ada rencana
RHEL 6 dan 7	Tidak terdampak	Menurut Red Hat

Tabel status patch per distro: Debian, SUSE, Amazon Linux, RHEL 8 sampai 10, dan Ubuntu 26.10 teal, Ubuntu LTS amber karena patch belum rilis, dan 2 baris HWE Ubuntu merah. — Teal: patch sudah ada. Amber: patch disiapkan, belum rilis. Merah: belum ada patch. Kotak kanan: versi stabil upstream yang aman. Nomor kernel distro tidak sama dengan nomor upstream. Sumber: Ubuntu, Debian, Red Hat, SUSE, Amazon Linux, dan catatan CVE tim kernel.

Data tabel berasal dari halaman CVE Ubuntu, tracker Debian, halaman CVE Red Hat, SUSE, dan Amazon Linux. Untuk kernel upstream atau distro yang mengikuti nomor upstream seperti Fedora dan Arch, versi stabil aman menurut catatan CVE tim kernel adalah 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, dan 7.3.

Prasyarat sebelum mulai

Akses SSH dengan hak sudo ke setiap server Linux dan host container.
Daftar semua server yang menerima koneksi dari internet, termasuk VPS, host Docker, dan node Kubernetes.
Paket iproute2 (perintah ss) dan nftables. Bila perintah nft belum ada, jalankan sudo apt install nftables atau sudo dnf install nftables.
Jadwal reboot singkat untuk setiap server.
Akses konsol cadangan dari penyedia server, bila aturan firewall memutus SSH.

Langkah 1: Cek paparan, yaitu listener TCP, listener MPTCP, dan 2 pengaturan kernel

Simpan skrip ini sebagai cek-paparan.sh. Skrip membaca 2 pengaturan kernel, daftar port TCP yang terbuka ke jaringan, dan daftar listener MPTCP.

# Paparan CVE-2026-98432: 2 pengaturan kernel, listener TCP, dan listener MPTCP.
echo "net.mptcp.enabled        = $(sysctl -n net.mptcp.enabled 2>/dev/null || echo tidak-ada)"
echo "net.ipv4.tcp_migrate_req = $(sysctl -n net.ipv4.tcp_migrate_req)"
echo "Listener TCP yang terbuka ke jaringan:"
ss -Hltnp | awk '$4 !~ /^(127\.|\[::1\]|\[::ffff:127\.)/ {print "  " $4, $6}' | sort -u
echo "Listener MPTCP (prioritas pertama):"
ss -HlnMp | awk '{print "  " $4, $6}' | sort -u | grep . || echo "  tidak ada"

Jalankan skrip di host. Untuk container Docker, baca listener di network namespace setiap container.

sudo bash cek-paparan.sh       # host, sudo agar nama proses tampil
# Container Docker: baca listener MPTCP di network namespace container.
sudo nsenter -t $(docker inspect -f '{{.State.Pid}}' nama-container) -n ss -HlnMp

Terminal: skrip cek paparan mencetak net.mptcp.enabled 1, tcp_migrate_req 0, 2 listener TCP di port 8080 dan 8081, dan hanya port 8080 sebagai listener MPTCP. — Port 8080 adalah server Go dengan pengaturan default. Port 8081 adalah server Go yang sama dengan GODEBUG=multipathtcp=0. Uji memakai image resmi golang. Sumber: uji Rama Digital di container podman, 31 Oktober 2026.

Cek hasil: Setiap listener MPTCP adalah prioritas pertama di langkah 4. Nilai net.ipv4.tcp_migrate_req harus 0. Server tanpa port terbuka ke jaringan tetap butuh patch, tetapi bisa menunggu jadwal reboot berikutnya.

Langkah 2: Cek kernel yang berjalan dan status patch distro

Simpan skrip ini sebagai cek-kernel.sh. Skrip membaca distro dan kernel yang berjalan, lalu membandingkan dengan status patch per 7 November 2026.

# Status CVE-2026-98432 untuk kernel yang berjalan. Data 7 November 2026.
krel=${KREL:-$(uname -r)}; kver=${KVER:-$(uname -v)}; . /etc/os-release
os=$ID; case $ID in ubuntu|debian|rhel|rocky|almalinux|centos) ;; *) for x in $ID_LIKE; do case $x in ubuntu|debian|rhel) os=$x; break;; esac; done;; esac
lt() { [ "$1" != "$2" ] && [ "$(printf '%s\n' "$1" "$2" | sort -V | head -1)" = "$1" ]; }
case $os in
  ubuntu)
    abi=${krel%-*}; flav=${krel##*-}; rel=${UBUNTU_CODENAME:-$VERSION_CODENAME}; st=pending
    case $rel/${abi%-*}/$flav in
      stonking/7.3.0/*) fix=10 st=released;; jammy/5.15.0/lowlatency|focal/5.15.0/lowlatency) fix=198;;
      jammy/5.15.0/*|focal/5.15.0/*) fix=203;; jammy/6.8.0/*|noble/6.8.0/*) fix=149;; resolute/7.0.0/*|noble/7.0.0/*) fix=43;;
      xenial/4.4.0/*) fix=293;; focal/5.4.0/*|bionic/4.15.0/*) fix=p;; noble/6.17.0/*|focal/*|bionic/*|xenial/*) fix=0;; *) fix=;; esac
    if [ -z "$fix" ] || { [ "$flav" != generic ] && [ "$flav" != lowlatency ]; }; then echo "$krel: cek tabel Ubuntu untuk kernel ini."
    elif [ "$fix" = 0 ]; then echo "$krel: RENTAN. Ubuntu belum menyiapkan patch untuk kernel ini. Pasang langkah 4."
    elif [ "$fix" = p ]; then echo "$krel: RENTAN. Patch Ubuntu disiapkan, versi belum ada. Pasang langkah 4."
    elif [ "${abi##*-}" -ge "$fix" ]; then echo "$krel: memuat patch Ubuntu (ABI ${abi%-*}-$fix)."
    elif [ "$st" = released ]; then echo "$krel: RENTAN. Update ke ABI ${abi%-*}-$fix, lalu reboot."
    else echo "$krel: RENTAN. Patch Ubuntu disiapkan di ABI ${abi%-*}-$fix, belum rilis. Pasang langkah 4."; fi ;;
  debian)
    cur=$(echo "$kver" | grep -oE 'Debian [^ ]+' | cut -d' ' -f2)
    case $cur in 6.1.*) fix=6.1.190-1;; 6.12.*~deb12*) fix=6.12.113-1~deb12u1;; 6.12.*) fix=6.12.113-1;; 7.2.*) fix=7.2.10-1;; *) fix=;; esac
    if [ -z "$fix" ]; then echo "$cur: cek tracker Debian."
    elif dpkg --compare-versions "$cur" lt "$fix"; then echo "$cur: RENTAN. Update ke $fix, lalu reboot."
    else echo "$cur: memuat patch (minimum $fix)."; fi ;;
  rhel|rocky|almalinux|centos)
    kv=$(echo "$krel" | sed -E 's/\.(x86_64|aarch64|ppc64le|s390x).*$//')
    case $ID/${VERSION_ID%%.*}/$krel in
      */6/*|*/7/*) fix=-;; centos/*) fix=;;
      */*/*el10nv*) fix=6.12.0-265.31.el10nv rhsa=RHSA-2026:93775;;
      */8/*rt*) fix=4.18.0-553.182.1.rt7.523.el8_10 rhsa=RHSA-2026:93415;;
      */8/*el8_4*) fix=4.18.0-305.218.1.el8_4 rhsa=RHSA-2026:94623;; */8/*el8_6*) fix=4.18.0-372.227.1.el8_6 rhsa=RHSA-2026:94996;;
      */8/*el8_8*) fix=4.18.0-477.178.1.el8_8 rhsa=RHSA-2026:94303;;
      */8/*) fix=4.18.0-553.182.1.el8_10 rhsa=RHSA-2026:93414;;
      */9/*rt*el9_2*) fix=5.14.0-284.202.1.rt14.487.el9_2 rhsa=RHSA-2026:94558;;
      */9/*el9_2*) fix=5.14.0-284.202.1.el9_2 rhsa=RHSA-2026:94477;; */9/*el9_4*) fix=5.14.0-427.161.1.el9_4 rhsa=RHSA-2026:94109;;
      */9/*el9_6*) fix=5.14.0-570.154.1.el9_6 rhsa=RHSA-2026:94438;; */9/*) fix=5.14.0-687.64.1.el9_8 rhsa=RHSA-2026:93412;;
      */10/*el10_0*) fix=6.12.0-55.117.1.el10_0 rhsa=RHSA-2026:94508;; */10/*) fix=6.12.0-211.72.1.el10_2 rhsa=RHSA-2026:93413;; *) fix=;; esac
    if [ "$fix" = - ]; then echo "$krel: tidak terdampak menurut Red Hat."
    elif [ -z "$fix" ]; then echo "$krel: cek advisory distro untuk kernel ini."
    elif lt "$kv" "$fix"; then echo "$krel: RENTAN. Update ke $fix ($rhsa), lalu reboot."
    else echo "$krel: memuat patch (minimum $fix, $rhsa)."; fi ;;
  ol|amzn|sles|opensuse*) echo "$krel: cek advisory $NAME untuk CVE-2026-98432." ;;
  *)
    base=${krel%%-*}
    case ${base%.*} in 5.10) fix=5.10.272;; 5.15) fix=5.15.223;; 6.1) fix=6.1.190;; 6.6) fix=6.6.159;; 6.12) fix=6.12.113;; 6.18) fix=6.18.56;; 7.2) fix=7.2.10;; *) fix=;; esac
    if lt "$base" 4.4; then echo "$base: tidak terdampak."
    elif [ -n "$fix" ]; then if lt "$base" "$fix"; then echo "$base: RENTAN. Update ke $fix, lalu reboot."; else echo "$base: memuat patch (minimum $fix)."; fi
    elif lt "$base" 7.3; then echo "$base: cabang tanpa patch stabil. Pindah ke cabang LTS."
    else echo "$base: memuat patch (7.3 ke atas)."; fi ;;
esac

Jalankan bash cek-kernel.sh di setiap server dan host container. Di tangkapan uji 2 November 2026, kami mengisi KREL dan KVER untuk meniru output uname dari server lain.

Terminal: cek kernel mencetak RENTAN untuk Ubuntu 6.8.0-148, HWE 6.17, Debian 6.1.176-1, dan AlmaLinux 9, lalu memuat patch untuk Debian 6.12.113-1 dan Fedora 7.2.11. — KREL dan KVER meniru output uname dari server lain di container resmi tiap distro. Baris terakhir memakai kernel asli mesin uji. Sumber: uji Rama Digital di container podman, 2 November 2026.

Status Ubuntu bisa berubah setiap hari. Jalankan perintah ini untuk membaca status terbaru dari Ubuntu.

curl -s https://ubuntu.com/security/cves/CVE-2026-98432.json \
  | jq -r '.packages[] | select(.name=="linux") | .statuses[] | "\(.release_codename) \(.status) \(.description)"'

Pada 7 November 2026 pukul 08.14 WIB, perintah itu mencetak output ini. Baris "released" berarti Anda bisa memasang patch sekarang.

stonking released 7.3.0-10.10
jammy pending 5.15.0-203.213
noble pending 6.8.0-149.149
focal pending
xenial pending 4.4.0-293.327
resolute pending 7.0.0-43.43
trusty not-affected 3.11.0-12.19
upstream released 7.3~rc7, 6.8.y, 6.17.y, 7.0.y
bionic pending

Cek hasil: Hasil "memuat patch" berarti server aman dari celah ini. Hasil "RENTAN. Update ke" berarti patch sudah ada, jadi lanjut ke langkah 3. Hasil "RENTAN. Pasang langkah 4" berarti distro belum punya patch.

Langkah 3: Update kernel, lalu reboot

Update paket kernel dari distro Anda, lalu reboot, karena kernel baru aktif hanya sesudah reboot.

# Debian 12 dan 13
sudo apt update && sudo apt full-upgrade
# SUSE Linux Enterprise
sudo zypper patch
# Amazon Linux 2023, semua kernel
sudo dnf upgrade --releasever=latest
# Amazon Linux 2
sudo yum update kernel
# RHEL 8, 9, 10, lalu Rocky dan AlmaLinux saat paket mereka rilis
sudo dnf upgrade kernel
# Ubuntu 26.10 sekarang, rilis Ubuntu lain saat status menjadi released
sudo apt update && sudo apt full-upgrade
# Semua distro: kernel baru aktif hanya sesudah reboot
sudo reboot

Untuk Amazon Linux 2023, Amazon Linux mencatat patch di kernel 6.1 bawaan (ALAS2023-2026-3365), kernel6.12 (ALAS2023-2026-3335), dan kernel6.18 (ALAS2023-2026-3251). Untuk Amazon Linux 2, patch ada di kernel inti (ALAS2-2026-4065) dan kernel Extra 5.4, 5.10, dan 5.15. Untuk SUSE, SUSE mencatat patch di SLES 15 SP4 sampai SP6 LTSS dan SLES 16.0.

Untuk Ubuntu 26.10, Ubuntu mencatat patch di kernel 7.3.0-10.10. Rilis Ubuntu LTS belum punya patch, jadi pakai langkah 4 sampai status menjadi released.

Untuk RHEL, Red Hat mencatat patch di kernel 4.18.0-553.182.1.el8_10 (RHEL 8), 5.14.0-687.64.1.el9_8 (RHEL 9), 6.12.0-211.72.1.el10_2 (RHEL 10), dan 6.12.0-265.31.el10nv (NVIDIA for RHEL 10). Kernel-rt RHEL 8 ada di RHSA-2026:93415, dan kernel-rt RHEL 9.2 E4S ada di RHSA-2026:94558. Untuk RHEL 9.4, 9.6, 9.8, dan 10, kernel-rt ada di errata yang sama dengan kernel, dengan versi yang sama. Untuk RHEL EUS, AUS, TUS, dan E4S, pakai versi di tabel status per distro. Rocky Linux dan AlmaLinux membangun ulang paket Red Hat, jadi cek advisory distro Anda.

Sesudah reboot, cek bahwa kernel baru benar berjalan.

uname -r
bash cek-kernel.sh
[ -f /var/run/reboot-required ] && echo "Reboot belum dijalankan."   # Debian dan Ubuntu
sudo needs-restarting -r                                              # RHEL, Rocky, AlmaLinux

Tangga 7 baris: cek paparan, cek kernel, update lalu reboot, 3 langkah berlabel bukan patch (MPTCP, migrasi request, IPv4 beropsi header), lalu cek tanda. — (1) sampai (3) Kotak teal: urutan perbaikan. (4a) sampai (4c): langkah sementara bila distro belum punya patch. Label merah mengingatkan bahwa langkah itu tidak menutup celah. Sumber: Go Security Team, oss-security, catatan CVE tim kernel, dan analisa Rama Digital.

Reboot host container memutus semua container di host itu. Reboot node Kubernetes satu per satu dengan kubectl drain. Untuk VPS, Anda sendiri yang update kernel, karena penyedia hanya menambal host fisik.

Cek hasil: cek-kernel.sh mencetak "memuat patch", dan perintah reboot-required tidak mencetak apa pun.

Langkah 4: Pasang mitigasi sementara bila distro belum punya patch

Langkah ini untuk Ubuntu LTS dan distro lain tanpa patch per 7 November 2026. Mitigasi mengurangi paparan, tetapi tidak menutup celah.

Analisa Rama Digital: Kami menyusun 3 langkah dari sumber primer. Kondisi: server belum bisa update kernel. Batas: setiap langkah menutup 1 jalur saja.

4a dan 4b. Matikan MPTCP dan migrasi request

diskusi oss-security 30 Oktober menyarankan net.mptcp.enabled=0 untuk seluruh sistem. peringatan Go Security Team menyarankan GODEBUG=multipathtcp=0 untuk program Go. Nilai default net.ipv4.tcp_migrate_req adalah 0, jadi pastikan nilai itu tetap 0.

# 1. Matikan MPTCP dan migrasi request, sekarang dan sesudah reboot.
sudo sysctl -w net.mptcp.enabled=0 net.ipv4.tcp_migrate_req=0
printf 'net.mptcp.enabled = 0\nnet.ipv4.tcp_migrate_req = 0\n' | sudo tee /etc/sysctl.d/90-cve-2026-98432.conf
# 2. Restart layanan yang tadi punya listener MPTCP, lalu ulangi langkah 1.
sudo systemctl restart nama-layanan

Terminal: ss -HlnM menampilkan listener MPTCP port 8080. Sesudah sysctl net.mptcp.enabled=0 dan restart server Go, daftar MPTCP kosong dan port 8080 tetap ada sebagai TCP. — Server Go kembali memakai TCP biasa tanpa perubahan kode. Baris terakhir: network namespace baru kembali ke nilai 1, jadi setiap container butuh pengaturan sendiri. Sumber: uji Rama Digital di container podman, 31 Oktober 2026.

Pengaturan net.mptcp.enabled berlaku per network namespace. Container dengan network sendiri tidak ikut pengaturan host. Pasang pengaturan di setiap container, atau matikan MPTCP di program Go.

# docker run
docker run --sysctl net.mptcp.enabled=0 ...
# docker-compose.yml
services:
  api:
    sysctls:
      net.mptcp.enabled: 0
# Program Go tanpa akses sysctl: matikan MPTCP per program
GODEBUG=multipathtcp=0 ./app
# atau tulis di go.mod modul utama, lalu build ulang
godebug multipathtcp=0

Batas: aplikasi yang memang butuh MPTCP berhenti memakai MPTCP. Program Go kembali ke TCP biasa tanpa error, menurut uji kami. Tim Go menulis bahwa bug tidak khusus MPTCP, jadi langkah 4a dan 4b saja tidak menutup semua jalur.

4c. Buang paket IPv4 dengan opsi header di nftables

Catatan CVE menulis bahwa data pemicu datang dari opsi header IPv4 di paket SYN. Aturan ini membuang semua paket IPv4 masuk yang membawa opsi header, yaitu header lebih panjang dari 20 byte.

Red Hat memberi aturan resmi yang mirip di buletin RHSB-2026-016: ip protocol tcp ip hdrlength > 5 counter drop di hook input. Bedanya, aturan di bawah membuang semua paket IPv4 beropsi di hook prerouting. Red Hat juga menulis bahwa aturan itu mengurangi paparan, tetapi tidak mencegah celah sepenuhnya.

Simpan aturan ini sebagai cve-2026-98432.nft.

table inet cve98432 {
  chain pre {
    type filter hook prerouting priority raw; policy accept;
    ip hdrlength != 5 counter drop comment "IPv4 dengan opsi header"
  }
}

Simpan unit ini sebagai cve-2026-98432-nft.service, agar aturan aktif lagi sesudah reboot.

[Unit]
Description=Buang paket IPv4 dengan opsi header (CVE-2026-98432)
Wants=network-pre.target
Before=network-pre.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/nft -f /etc/cve-2026-98432.nft
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Pasang aturan dan unit, lalu cek chain-nya.

sudo cp cve-2026-98432.nft /etc/cve-2026-98432.nft
sudo cp cve-2026-98432-nft.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable --now cve-2026-98432-nft
sudo nft list chain inet cve98432 pre

Terminal: sebelum aturan nft, ping -R dibalas. Sesudah aturan, ping biasa 2 dari 2 dibalas, ping -R 0 dari 2, curl HTTP 200, dan counter mencatat 2 paket dibuang. — Uji memakai ping -R, yaitu ICMP dengan opsi header Record Route. Uji tidak mengirim paket pemicu celah. Lalu lintas web biasa tetap lewat. Sumber: uji Rama Digital di container podman, 31 Oktober 2026.

Aturan memakai hook prerouting, jadi aturan juga menahan paket untuk container sebelum paket masuk ke network namespace container. Aturan hidup di tabel sendiri, jadi aturan tidak mengubah aturan ufw, firewalld, atau Docker.

Batas: aturan ini bukan patch. Aturan juga membuang ping -R, traceroute dengan opsi IP, dan aplikasi lama yang memakai opsi IP. Web, SSH, dan API biasa tidak memakai opsi IP, dan uji curl kami tetap mendapat HTTP 200. Pasang dulu di 1 server, lalu cek layanan Anda.

Cek hasil: cek-paparan.sh menulis "tidak ada" di daftar MPTCP, tcp_migrate_req 0, dan nft list chain inet cve98432 pre menampilkan aturan dengan counter.

Langkah 5: Periksa tanda server sudah disentuh

Serangan yang gagal sering membuat kernel crash atau reboot, sedangkan serangan yang berhasil memberi akses root tanpa jejak yang jelas.

Simpan skrip ini sebagai cek-tanda.sh dan jalankan dengan sudo.

# Tanda CVE-2026-98432 sejak CVE terbit pada 15 Oktober 2026.
n=$(nft list chain inet cve98432 pre 2>/dev/null | grep -oE 'packets [0-9]+' | cut -d' ' -f2)
echo "Pesan kernel mencurigakan : $(journalctl -k --since 2026-10-15 | grep -ciE 'use-after-free|KASAN|skb_under_panic|ip_options_build|general protection fault|Oops')"
echo "Boot sejak 15 Oktober     : $(journalctl --list-boots --no-pager | awk '$4 ~ /^20/ && $4 >= "2026-10-15"' | wc -l)"
echo "Paket beropsi IP dibuang  : ${n:-0}"
echo "Akun dengan UID 0         : $(awk -F: '$3 == 0 {print $1}' /etc/passwd | xargs)"

Lalu baca pesan kernel, crash dump, dan kunci SSH root.

sudo bash cek-tanda.sh
sudo journalctl -k --since 2026-10-15 | grep -iE 'use-after-free|KASAN|skb_under_panic|ip_options_build|Oops' | tail -20
ls -lt /var/crash /var/lib/systemd/coredump 2>/dev/null | head
sudo ls -l /root/.ssh/authorized_keys

Terminal: skrip cek tanda mencetak 0 pesan kernel mencurigakan, jumlah boot sejak 15 Oktober, 0 paket beropsi IP di host, dan hanya root sebagai akun UID 0. — Counter 0 di host berarti aturan langkah 4 belum terpasang di host itu. Di container uji, counter mencatat paket ping -R dari langkah 4. Sumber: uji Rama Digital di container podman, 31 Oktober 2026.

Dua kolom tanda: di kernel dan host, dan di jaringan dan akun, lalu kotak merah: isolasi server, simpan log, ganti secret, dan bangun ulang dari image bersih. — Kolom amber: pesan kernel, reboot tanpa jadwal, dan crash dump. Kolom merah: paket beropsi IP, proses root asing, akun UID 0 baru, dan kunci SSH baru. Sumber: skenario CVSS di catatan CVE tim kernel dan analisa Rama Digital.

Skenario CVSS dari tim kernel menyebut 2 akibat yang terlihat: skb_under_panic dan Oops di ip_options_build(). Kernel yang panic biasanya reboot sendiri, jadi boot yang tidak Anda jadwalkan sejak 15 Oktober butuh pemeriksaan.

Cek hasil: 0 pesan kernel mencurigakan, semua boot cocok dengan jadwal Anda, dan hanya root sebagai akun UID 0. Counter nftables yang naik berarti ada paket beropsi IP yang datang, jadi simpan log dan cek pesan kernel. Bila ada tanda serangan, isolasi server dan simpan log. Lalu ganti semua secret di server itu dan bangun ulang dari image bersih.

Contoh: 1 malam respons untuk 4 server

Simulasi ini memakai data dummy. Nama server, waktu, dan hasil bukan data pelanggan.

Waktu (WIB)	Server dummy	Yang dicek	Hasil	Tindakan
21.00	vps-toko (Ubuntu 24.04, 6.8.0-148, API Go 1.25 di port 443)	Langkah 1 dan 2	Listener MPTCP :443, RENTAN	Langkah 4a sampai 4c, restart API
21.40	db-utama (Debian 12, 6.1.176-1)	Langkah 2	RENTAN, patch ada	apt full-upgrade, reboot 22.00
22.20	erp-lama (RHEL 9)	Langkah 2	RENTAN, patch ada	dnf upgrade kernel, reboot 22.40
22.50	docker-host (Ubuntu 22.04, 3 container Go)	Langkah 1 per container	2 listener MPTCP	sysctls di compose, langkah 4c di host
23.30	Semua server	Langkah 5	0 pesan kernel, boot sesuai jadwal	Catat, ulangi langkah 2 setiap pagi

Pelajaran dari simulasi: host Docker butuh pengaturan MPTCP di setiap container, bukan hanya di host. Server Ubuntu tetap butuh reboot saat patch rilis, walau mitigasi sudah terpasang.

Siapa yang memasang patch

Tanggung jawab patch kernel berbeda per cara hosting, jadi tabel ini membantu Anda tahu siapa yang harus bergerak hari ini.

Cara hosting	Pemegang patch	Yang Anda kerjakan
VPS atau server sendiri	Tim IT Anda	Langkah 1 sampai 5
Kubernetes terkelola (node pool)	Penyedia membuat image node, Anda upgrade node	Cek pengumuman penyedia, upgrade node pool, lalu langkah 5
Shared hosting atau PaaS	Penyedia	Minta bukti versi kernel tertulis
Aplikasi yang dikelola vendor di server Anda	Tim IT Anda untuk kernel, vendor untuk aplikasi	Langkah 1 sampai 5, lalu minta vendor cek listener MPTCP

Rekomendasi Rama Digital: bila server Anda memegang token pembayaran, token WhatsApp, atau API key model AI, perlakukan setiap tanda di langkah 5 sebagai insiden. Untuk server MCP, baca juga hak akses, approval, dan audit log server MCP.

Checklist hari ini

Buat daftar semua server Linux dan host container yang menerima koneksi dari internet. Pemilik: tim DevOps. Bukti: daftar host.
Cek paparan dengan langkah 1. Pemilik: admin server. Bukti: output skrip per host dan per container.
Cek kernel dengan langkah 2. Pemilik: admin server. Bukti: output skrip per host.
Update dan reboot server Debian, SUSE, Amazon Linux, RHEL 8, 9, 10, dan Ubuntu 26.10. Pemilik: admin server. Bukti: output langkah 2 sesudah reboot.
Pasang langkah 4 di server Ubuntu LTS. Pemilik: admin server. Bukti: output langkah 1 dan counter nftables.
Periksa tanda dengan langkah 5. Pemilik: admin server. Bukti: output perintah, disimpan bersama log.
Cek status Ubuntu setiap pagi. Saat patch rilis, jalankan langkah 3 dan hapus aturan sementara bila tidak dibutuhkan lagi.

Tanya jawab

Server saya tidak memakai MPTCP. Apakah server saya aman?

Belum tentu. Celah ada di jalur TCP IPv4 biasa. PoC Anthropic memakai MPTCP, tetapi tim Go menulis bahwa bug tidak khusus MPTCP. Patch kernel tetap perlu.

Ubuntu LTS belum merilis patch. Apa yang saya lakukan sekarang?

Pasang langkah 4a sampai 4c. Lalu cek status Ubuntu setiap hari dengan perintah di langkah 2. Saat status berubah menjadi released, jalankan langkah 3.

Image container saya sudah update. Apakah container saya terlindungi?

Tidak. Container memakai kernel host, dan update image tidak mengubah kernel. Patch dan reboot host, lalu pasang pengaturan MPTCP di setiap container.

Apakah update paket kernel tanpa reboot menutup celah?

Tidak. Kernel lama tetap berjalan sampai reboot. Cek uname -r sesudah reboot, lalu jalankan cek-kernel.sh lagi.

Skor SUSE dan Amazon 8.1, tetapi skor tim kernel 9.8. Mana yang benar?

Keduanya sama kecuali di kompleksitas serangan. SUSE dan Amazon menilai race sulit dipicu. Tim kernel menilai penyerang bisa terus mencoba, Red Hat naik ke 9.8 pada 30 Oktober, dan Anthropic melaporkan PoC yang bekerja.

Apakah aturan nftables di langkah 4c merusak website saya?

Aturan hanya membuang paket IPv4 dengan opsi header. Di uji kami, HTTP biasa tetap mendapat 200 dan hanya ping -R yang dibuang. Pasang dulu di 1 server, lalu cek layanan Anda.

Apakah VPS di penyedia cloud ditambal otomatis?

Tidak. VPS punya kernel sendiri, dan kernel itu tanggung jawab Anda. Penyedia hanya menambal host fisik. Jalankan langkah 2 di dalam setiap VPS.

Bagaimana saya tahu server sudah dibobol?

Cari pesan kernel, reboot tanpa jadwal, akun UID 0 baru, dan kunci SSH baru dengan langkah 5. Log yang bersih tidak membuktikan server aman.

Langkah berikutnya

Batas yang tetap berlaku: mitigasi di langkah 4 tidak menutup celah, dan patch tidak menghapus akses yang mungkin sudah tertanam. Bila server Anda menunjukkan tanda di langkah 5, atau Anda butuh bantuan memeriksa server dan secret, pakai Vibe Code Rescue untuk audit dan stabilisasi. Untuk 1 kendala yang mendesak hari ini, jadwalkan sesi 30 menit.

Sumber

catatan CVE tim kernel: ringkasan celah, versi terdampak, versi stabil aman, dan skenario CVSS.
commit perbaikan e3f33b0a1d89: penulis, tanggal, dan pelapor perbaikan.
NVD: status Received tanpa skor NVD.
halaman CVE Ubuntu: prioritas Critical (sebelumnya High), status patch per rilis Ubuntu, dan patch 26.10 per 7 November 2026.
tracker Debian: versi kernel Debian dengan patch.
halaman CVE Red Hat: skor 9.8 (sebelumnya 8.1), label Critical, dan status RHEL.
buletin RHSB-2026-016: mitigasi resmi Red Hat dengan aturan nftables, 30 Oktober 2026.
RHSA-2026:93414, RHSA-2026:93412, dan RHSA-2026:93413: patch kernel RHEL 8, 9, dan 10, 1 November 2026.
RHSA-2026:93775: patch kernel NVIDIA for RHEL 10, 2 November 2026.
RHSA-2026:94623, RHSA-2026:94996, RHSA-2026:94303, RHSA-2026:94477, RHSA-2026:94558, RHSA-2026:94109, RHSA-2026:94438, dan RHSA-2026:94508: patch kernel RHEL EUS, AUS, TUS, dan E4S, 2 sampai 4 November 2026.
SUSE: skor 8.1 dan 9.2, dan status produk SUSE.
Amazon Linux: skor 8.1 dan status paket kernel Amazon Linux.
laporan Anthropic 27 Oktober: PoC root dari jarak jauh di server dengan listener MPTCP.
peringatan Go Security Team: MPTCP default di Go 1.24 ke atas dan GODEBUG.
diskusi oss-security 30 Oktober: pengaturan net.mptcp.enabled untuk seluruh sistem.
CISA KEV: CVE-2026-98432 belum masuk katalog per 30 Oktober 2026.

CVE-2026-98432: Celah TCP Kernel Linux Skor 9.8, Patch Ubuntu LTS Belum Rilis, Cara Cek dan Mitigasi Hari Ini

Ringkasan cepat

Masalah: patch upstream sudah ada, tetapi Ubuntu LTS belum merilis patch

Cara kerja: kernel membaca opsi IP dari memori yang sudah dibebaskan

Ringkasan dari catatan CVE

Skor dari setiap lembaga

Status eksploitasi per 31 Oktober 2026

Siapa yang paling berisiko

Status patch per distro

Prasyarat sebelum mulai

Langkah 1: Cek paparan, yaitu listener TCP, listener MPTCP, dan 2 pengaturan kernel

Langkah 2: Cek kernel yang berjalan dan status patch distro

Langkah 3: Update kernel, lalu reboot

Langkah 4: Pasang mitigasi sementara bila distro belum punya patch

4a dan 4b. Matikan MPTCP dan migrasi request

4c. Buang paket IPv4 dengan opsi header di nftables

Langkah 5: Periksa tanda server sudah disentuh

Contoh: 1 malam respons untuk 4 server

Siapa yang memasang patch

Checklist hari ini

Tanya jawab

Server saya tidak memakai MPTCP. Apakah server saya aman?

Ubuntu LTS belum merilis patch. Apa yang saya lakukan sekarang?

Image container saya sudah update. Apakah container saya terlindungi?

Apakah update paket kernel tanpa reboot menutup celah?

Skor SUSE dan Amazon 8.1, tetapi skor tim kernel 9.8. Mana yang benar?

Apakah aturan nftables di langkah 4c merusak website saya?

Apakah VPS di penyedia cloud ditambal otomatis?

Bagaimana saya tahu server sudah dibobol?

Langkah berikutnya

Sumber

Daftar isi

Pilih waktu bersama tim.

Jadwal tersimpan.

Ringkasan cepat

Masalah: patch upstream sudah ada, tetapi Ubuntu LTS belum merilis patch

Cara kerja: kernel membaca opsi IP dari memori yang sudah dibebaskan

Ringkasan dari catatan CVE

Skor dari setiap lembaga

Status eksploitasi per 31 Oktober 2026

Siapa yang paling berisiko

Status patch per distro

Prasyarat sebelum mulai

Langkah 1: Cek paparan, yaitu listener TCP, listener MPTCP, dan 2 pengaturan kernel

Langkah 2: Cek kernel yang berjalan dan status patch distro

Langkah 3: Update kernel, lalu reboot

Langkah 4: Pasang mitigasi sementara bila distro belum punya patch

4a dan 4b. Matikan MPTCP dan migrasi request

4c. Buang paket IPv4 dengan opsi header di nftables

Langkah 5: Periksa tanda server sudah disentuh

Contoh: 1 malam respons untuk 4 server

Siapa yang memasang patch

Checklist hari ini

Tanya jawab

Server saya tidak memakai MPTCP. Apakah server saya aman?

Ubuntu LTS belum merilis patch. Apa yang saya lakukan sekarang?

Image container saya sudah update. Apakah container saya terlindungi?

Apakah update paket kernel tanpa reboot menutup celah?

Skor SUSE dan Amazon 8.1, tetapi skor tim kernel 9.8. Mana yang benar?

Apakah aturan nftables di langkah 4c merusak website saya?

Apakah VPS di penyedia cloud ditambal otomatis?

Bagaimana saya tahu server sudah dibobol?

Langkah berikutnya

Sumber

Artikel yang mungkin Anda suka

CVE-2026-99999 (PwnEscape): Celah Kernel Linux dari VM ke Host, dan Cara Mengecek Server Anda

CVE-2026-119977 WordPress: Celah Saat Update Core Sudah Dipakai Menyerang, Update ke 7.1.4

CVE-2026-77876 Control Web Panel (CWP): 10 Celah, Skor Tertinggi 9.8, Update ke 1.30 Hari Ini