2026/10/28

Node2Shell (CVE-2026-111497): sistem mana yang berisiko dan apa yang harus dilakukan sekarang

Sistem mana yang benar-benar terdampak CVE-2026-111497 di Brotli, seberapa mendesak tiap kasus, serta langkah patch, rebuild, restart, dan mitigasi.

Diperbarui 27 Oktober 2026

CVE-2026-111497, yang dijuluki “Node2Shell” atau “HTTP2Shell”, adalah bug korupsi memori pada dekompresor Brotli. Brotli adalah kompresi br yang digunakan di seluruh web. Bug ini terdapat pada library Brotli milik Google versi 1.0.3 hingga 1.2.0 [1]. Node.js menyertakan library tersebut, dan proyek Node.js menilai masalah ini berkategori High untuk lini 22.x, 24.x, dan 26.x [2]. Decoder yang sama juga ada di dalam paket Python, library sistem Linux, aplikasi desktop, dan tool pengembang, sehingga eksposur sebenarnya jauh lebih luas daripada sekadar “server Node.js”.

Artikel ini ditujukan bagi tim yang perlu segera memutuskan apakah mereka terdampak dan apa yang harus dilakukan lebih dulu.

Intinya: Jika ada sistem Anda yang mendekompresi data Brotli dari pihak yang tidak Anda kendalikan (klien di internet, situs web eksternal, pengirim webhook, file yang diunggah), perlakukan ini sebagai hal mendesak. Lakukan patch, rebuild, dan restart, dan sementara itu blokir br.

Apa yang dilakukan kerentanan ini

Decoder salah menangani “block switch” yang cacat (malformed) dalam stream terkompresi. Decoder menganggap error tersebut sebagai “saya butuh input tambahan”, bukan “data ini tidak valid”, lalu terus menambahkan byte ke buffer internal kecil berukuran tetap hingga menulis melewati batas akhirnya [2]. Penyerang yang dapat membuat aplikasi Anda mendekompresi stream Brotli yang dirancang khusus dapat merusak memori proses. Hal ini dapat menyebabkan:

Crash (denial of service). Ini adalah hasil yang paling andal dicapai.
Kebocoran memori proses. Respons atau log dapat mengekspos potongan secret, token, atau data pengguna lain.
Kemungkinan eksekusi kode jarak jauh. Node.js mencantumkan RCE sebagai dampak yang mungkin terjadi [2]. Proof of concept publik pertama hanya berhasil mengeksekusi kode pada build yang sengaja dilemahkan, tetapi sejak itu peneliti melaporkan eksekusi kode yang belum andal pada build Node.js 24.22.0 resmi yang tidak dimodifikasi [3].

Tidak diperlukan autentikasi: penyerang hanya perlu mengirimkan byte yang sampai ke decoder. Itulah sebabnya skor CVSS 4.0-nya adalah 9.2 (Critical) [1]. Karena itu, pertanyaan kunci untuk setiap sistem bukanlah “apakah kita memakai Brotli?” melainkan “dapatkah pihak yang tidak tepercaya membuat kita mendekompresi Brotli?”

Kasus penggunaan umum dan risikonya

Kasus 1: API yang terekspos ke internet dan menerima body request terkompresi (prioritas tertinggi)

Sebagian server API Node.js, BFF, API gateway, dan endpoint unggah mendekompresi body request yang dikirim dengan Content-Encoding: br. Sebagian lainnya melakukan hal yang sama melalui middleware. Risiko: klien anonim mana pun di internet dapat mengirim body yang dirancang khusus. Dampaknya berkisar dari membuat layanan crash berulang kali, yang merupakan DoS berbiaya murah, hingga membocorkan memori dari proses yang menyimpan data sesi dan API key. Urgensi: darurat. Lakukan patch hari ini, dan blokir body request br di edge sampai patch selesai.

Kasus 2: Layanan yang mengambil konten dari luar (prioritas tinggi)

Konsumen webhook, crawler dan scraper, layanan pratinjau tautan dan RSS, integrasi pembayaran atau SaaS, serta AI agent yang menjelajah web semuanya membuat request HTTP keluar. Banyak HTTP client mengirim Accept-Encoding: br dan mendekompresi respons secara otomatis. Di Python, urllib3 dan requests melakukannya setiap kali paket Brotli atau brotlicffi terpasang, bahkan jika kode Anda tidak pernah meng-import-nya. aiohttp juga demikian, dan httpx melakukannya bila dipasang dengan extra brotli [4]. Risiko: server jarak jauh yang berbahaya, telah disusupi, atau dipalsukan dapat menyerang backend Anda melalui responsnya. Penyerang sama sekali tidak perlu menjangkau jaringan Anda: Andalah yang memanggil mereka. Urgensi: tinggi. Dahulukan patch di mana pun tujuan request tidak sepenuhnya tepercaya.

Kasus 3: Aplikasi desktop, AI coding agent, dan CLI dengan runtime tertanam

Aplikasi Electron, CLI berbasis Bun atau Node, dan tool AI untuk pengembang membawa salinan runtime sendiri. Memperbarui paket node sistem tidak memperbaikinya. Memperbarui aplikasi di disk juga tidak memperbaiki salinan yang sudah berjalan: proses yang berjalan lama tetap menyimpan runtime lama di memori sampai di-restart. Risiko: tool ini sering menyimpan kredensial dan mengambil konten eksternal, sehingga menggabungkan Kasus 2 dengan proses yang memiliki hak akses tinggi. Urgensi: tinggi untuk tool yang mengambil konten tidak tepercaya. Perbarui, lalu benar-benar restart. Kami telah membahas jebakan “sudah diperbarui tetapi masih menjalankan kode lama” secara rinci dalam artikel HTTP2Shell: mengapa memperbarui binary tidak memulihkan proses yang sedang berjalan.

Kasus 4: Container image dan artefak CI/CD

Image yang di-build FROM node:22, node:24, atau node:26 sebelum perbaikan tersedia masih berisi runtime yang rentan, meskipun host sudah di-patch. Hal yang sama berlaku untuk Python wheel yang dibundel dan dependensi yang di-vendor. Risiko: kode yang rentan akan muncul kembali pada setiap deploy dan setiap peristiwa autoscaling sampai image di-build ulang. Urgensi: tinggi untuk image yang menjalankan Kasus 1 dan 2. Lakukan rebuild, bukan sekadar restart.

Kasus 5: Library sistem Linux, font, dan pemrosesan gambar

Distribusi menyertakan decoder sebagai shared library, misalnya libbrotli1 di Ubuntu/Debian. Library ini digunakan oleh curl dan libcurl saat kompresi diaktifkan, oleh FreeType untuk web font WOFF2, dan secara tidak langsung oleh tool gambar dan dokumen seperti Pillow. Risiko: sistem yang me-render font atau dokumen unggahan pengguna, atau yang mengambil konten eksternal dengan curl --compressed, dapat dijangkau oleh data Brotli yang tidak tepercaya. Server yang tidak pernah memasukkan data eksternal ke library ini memiliki eksposur praktis yang rendah. Urgensi: sedang pada sebagian besar kasus, tetapi tinggi untuk layanan rendering dokumen atau pemrosesan unggahan. Ubuntu telah merilis paket brotli yang sudah diperbaiki untuk 22.04, 24.04, 26.04, dan 26.10 [1]. Untuk RHEL, Oracle Linux, dan distribusi lain, periksa advisory vendor Anda untuk paket brotli alih-alih mengasumsikan statusnya.

Kasus 6: Sistem khusus internal dengan input tepercaya (prioritas lebih rendah)

Sebagian layanan hanya mendekompresi Brotli dari data yang Anda hasilkan sendiri, seperti cache internal atau artefak build Anda sendiri. Risikonya lebih rendah, tetapi bukan nol: penyerang yang sudah memiliki pijakan dapat memanfaatkan bug ini untuk bergerak lebih jauh. Urgensi: patch pada siklus rutin berikutnya.

Apa yang harus dilakukan: langkah respons

Langkah 1: Temukan di mana Brotli didekode (hari ini)

Node.js: periksa node -v di setiap host, serta di setiap container image dan CI runner. Cari di kode dan konfigurasi brotliDecompress, createBrotliDecompress, dan middleware body parsing yang mendekompresi br.
Runtime tertanam: data aplikasi Electron, CLI Bun/Node, dan AI agent yang digunakan, lalu catat versi runtime yang tertanam di masing-masing, bukan hanya versi aplikasinya.
Python: jalankan pip show Brotli brotlicffi di setiap environment dan image. Cari httpx[brotli] dan dependensi transitif di lockfile dan SBOM.
Paket OS: dpkg -l | grep brotli atau rpm -qa | grep brotli, lalu lihat proses mana yang benar-benar memuat library tersebut.
Prioritaskan berdasarkan kasus di atas: apa pun yang dapat dijangkau input tidak tepercaya (Kasus 1, 2, 3, dan 5 dengan unggahan) didahulukan.

Langkah 2: Patch komponen yang terdampak

Node.js: upgrade ke 22.23.4, 24.22.1, atau 26.12.1 atau yang lebih baru [2].
Python: Brotli>=1.2.1 atau brotlicffi>=1.2.1.0. Buat ulang lockfile [4].
Brotli upstream / kode C yang di-vendor: 1.0.10, 1.1.1, atau 1.2.1, tergantung branch-nya [1].
Paket OS: terapkan pembaruan keamanan dari distribusi Anda untuk brotli / libbrotli.
Aplikasi desktop dan agent: perbarui ke rilis vendor yang menyatakan sudah menyertakan runtime yang diperbaiki. Jika vendor belum memublikasikan apa pun, anggap aplikasi tersebut belum terverifikasi, bukan aman.

Langkah 3: Rebuild, redeploy, dan restart

Build ulang container image dari base image yang sudah di-patch, lalu deploy ulang. Me-restart image lama tidak membantu.
Restart setiap proses berjalan lama yang memuat library rentan: layanan Node, worker, sesi agent, dan apa pun yang di-link ke library sistem. Untuk job stateful dan AI agent, lakukan drain atau serahkan pekerjaan terlebih dahulu agar event dalam antrean atau persetujuan tidak hilang.

Langkah 4: Mitigasi selagi melakukan patch

Inbound: tolak body request yang Content-Encoding-nya mengandung br di reverse proxy, load balancer, atau WAF, sebelum decoder mana pun menerimanya.
Outbound: menghapus br dari Accept-Encoding saja tidak cukup, karena server berbahaya tetap bisa mengirim br. Tolak juga, atau jangan dekode, respons yang datang dengan Content-Encoding: br [4].
Fallback untuk Python: jika upgrade harus ditunda, uninstall Brotli dan brotlicffi agar client berhenti mendekode br. Uji terlebih dahulu, karena sebagian server tetap akan mengirim br.

Langkah 5: Verifikasi, dan pantau tanda-tanda eksploitasi

Pastikan versi runtime dari dalam proses atau container yang sedang berjalan, bukan hanya dari package manager.
Pindai ulang image dan SBOM untuk memastikan tidak ada salinan lama yang masih ikut tertarik secara transitif.
Tinjau log terbaru untuk mencari crash tanpa penyebab jelas, segmentation fault, atau restart loop pada layanan yang menangani br. Sekumpulan crash dari satu sumber patut diselidiki sebagai percobaan serangan.
Jika layanan dengan eksposur tinggi crash secara tak terduga sebelum di-patch, pertimbangkan untuk merotasi secret yang dipegang proses tersebut, karena kebocoran memori tidak dapat dikesampingkan.

Ringkasan

Situasi	Risiko	Tindakan
API publik mendekode body request `br`	Kritis	Patch sekarang; blokir `br` di edge
Backend mengambil URL, webhook, atau halaman web eksternal	Tinggi	Patch sekarang; tolak respons `br`
Aplikasi Electron, AI agent, atau CLI dengan runtime tertanam	Tinggi	Perbarui dan restart setiap instance yang berjalan
Container image dan artefak CI lama	Tinggi	Build ulang dari base image yang sudah di-patch, lalu deploy ulang
Library sistem yang dipakai untuk unggahan, font, atau `curl --compressed`	Sedang–Tinggi	Terapkan pembaruan OS; restart layanan yang memuatnya
Hanya data internal yang tepercaya	Rendah–Sedang	Patch pada siklus berikutnya

Mem-patch paket hanyalah separuh pekerjaan. Eksposur baru benar-benar hilang ketika tidak ada lagi proses yang berjalan, image, atau runtime tertanam yang masih dapat mendekode Brotli tidak tepercaya dengan kode lama.