CVE-2026-111497 adalah buffer overflow pada decoder Brotli di berkas c/dec/decode.c yang memengaruhi versi 1.0.3 sampai 1.2.0 di semua platform. NVD mencatat skor CVSS 4.0 sebesar 9.2 dengan tingkat keparahan kritis, dan perbaikannya sudah tersedia di versi 1.0.10, 1.1.1, serta 1.2.1. CVE ini dipublikasikan 22 Oktober 2026.
TL;DR
- Semua versi Brotli dari 1.0.3 sampai 1.2.0 terpengaruh, tanpa memandang sistem operasi.
- Perbaikan ada di 1.0.10, 1.1.1, atau 1.2.1, pilih sesuai jalur mayor yang dipakai.
- Dampaknya bukan hanya crash: memori bisa terbaca, dan eksekusi kode tidak dikecualikan.
- Yang perlu diaudit bukan hanya server, tetapi juga library yang membundel Brotli di dalam aplikasi.
Apa itu CVE-2026-111497 dan seberapa serius?
Ini adalah kerentanan buffer overflow pada decoder Brotli, komponen yang bertugas mengubah data terkompresi kembali menjadi data asli. Deskripsi resminya menyebut penyerang remote tanpa autentikasi dapat merusak state decoder di memori yang berdekatan, membocorkan isi memori sensitif, menyebabkan denial of service, atau berpotensi mengeksekusi kode arbitrer lewat stream Brotli yang dibuat khusus.
Skornya 9.2 pada CVSS 4.0. Vektornya adalah jaringan, kompleksitas rendah, tanpa hak istimewa, dan tanpa interaksi pengguna, dengan dampak tinggi pada kerahasiaan, integritas, dan ketersediaan. Spesifikasi formatnya sendiri dijelaskan di RFC 7932. Satu catatan penting soal status: NVD masih menandai CVE ini sebagai Awaiting Analysis per 24 Oktober 2026, artinya skor tersebut berasal dari koordinator CVE, bukan dari analisis ulang NVD.
Kombinasi tanpa autentikasi dan tanpa interaksi pengguna itulah yang membuatnya berbahaya. Penyerang hanya perlu mengirim payload terkompresi ke titik masuk mana pun yang melakukan dekompresi, misalnya permintaan HTTP dengan header content-encoding br. Tidak ada langkah tambahan yang harus dibujuk, tidak ada berkas yang harus dibuka korban.
Yang membuat jangkauannya melebar adalah sifat Brotli sebagai library, bukan layanan. Ia dibundel ke dalam server web, klien HTTP, alat build, sampai aplikasi desktop. Memperbarui satu server tidak menutup jalur lain, dan justru komponen yang dibundel itulah yang paling sering luput dari pemindaian.
Versi Brotli mana yang aman?
Versi 1.0.10, 1.1.1, dan 1.2.1 adalah versi yang sudah diperbaiki, masing-masing untuk jalur mayor 1.0, 1.1, dan 1.2. Semua versi dari 1.0.3 sampai 1.2.0, termasuk 1.2.0 itu sendiri, masih rentan.
Perhatikan tiga jalur perbaikan itu. Kalau sistem masih di jalur 1.0, naik ke 1.0.10 tanpa harus melompat ke 1.1 atau 1.2. Kalau sudah di 1.1.0, cukup ke 1.1.1. Kalau sudah di 1.2.0, naik ke 1.2.1. Pilihan ini penting untuk lingkungan yang memakai pin versi ketat, karena melompat antar mayor membawa perubahan ABI yang belum tentu siap.
Versi di bawah 1.0.3 tidak dicantumkan dalam rentang terdampak pada data CVE. Itu bukan alasan untuk mempertahankannya. Versi sangat lama biasanya sudah tidak menerima perbaikan apa pun, dan tidak adanya entri di rentang terdampak hanya berarti tidak ada yang memverifikasinya.
| Jalur versi | Status | Versi minimum yang aman |
|---|---|---|
| 1.0.3 sampai 1.0.9 | Rentan | 1.0.10 |
| 1.1.0 | Rentan | 1.1.1 |
| 1.2.0 | Rentan | 1.2.1 |
| 1.0.10, 1.1.1, 1.2.1 | Aman menurut data CVE | Sudah versi perbaikan |
Bagaimana cara memeriksa versi Brotli yang dipakai aplikasi?
Cara paling andal adalah membaca daftar dependensi terkunci, bukan mengandalkan versi yang tertulis di dokumentasi. Di proyek Node.js, cari entri brotli di berkas lock. Di sistem Debian dan Ubuntu, gunakan apt list --installed dengan pola nama paket brotli. Untuk kode yang memakai library pihak ketiga, periksa apakah Brotli dikompilasi langsung sebagai static library.
Kasus static library adalah yang paling sulit. Kalau Brotli di-link saat proses build dan bukan saat runtime, memperbarui paket Brotli di sistem tidak akan mengubah apa pun pada biner yang sudah jadi. Biner itu membawa salinan kode lama di dalamnya. Satu-satunya jalan adalah membangun ulang aplikasi dengan versi Brotli yang sudah diperbaiki.
Cara cepat memeriksa biner adalah mencari simbol versi di dalamnya. Kalau biner memuat string versi Brotli, nilainya bisa dibaca langsung. Kalau tidak, cara yang lebih pasti adalah memeriksa berkas lock dan konfigurasi build, karena di sanalah versi sebenarnya ditentukan.
Untuk lingkungan produksi, urutan auditnya: inventaris paket sistem, inventaris dependensi aplikasi, lalu inventaris komponen yang dibundel di dalam kontainer atau biner. Tiga lapisan ini berbeda, dan temuan biasanya ada di lapisan ketiga. Daftar versi terdampak serta perbaikannya bisa dikonfirmasi di basis data NVD dan catatan rilis repositori Brotli.
Apakah eksploitasi butuh interaksi pengguna?
Tidak. Vektor CVSS 4.0 untuk CVE ini mencatat UI sebagai N, artinya user interaction none. Penyerang cukup mengirim data yang akan didekompresi oleh target, tanpa perlu korban menekan apa pun.
Ini yang membedakan kelas bug decoder dengan bug aplikasi biasa. Pada bug aplikasi, sering kali ada langkah yang bisa dijadikan titik pemeriksaan, misalnya pengguna harus membuka dokumen atau mengonfirmasi dialog. Pada bug decoder, data masuk ke jalur otomatis: server menerima permintaan, decoder berjalan, dan kerusakan memori terjadi sebelum ada logika bisnis yang sempat memeriksanya.
Ada satu syarat pada vektor tersebut, yaitu AT atau attack requirements bernilai P atau present. Artinya keberhasilan eksploitasi bergantung pada kondisi tertentu di lingkungan target. Itu menurunkan sedikit risiko praktis, tetapi tidak mengubah kebutuhan untuk menambal. Persyaratan itu bisa terpenuhi tanpa disadari oleh konfigurasi library yang sudah ada.
Perlu juga dicatat bahwa status analisis CVE ini masih menunggu tinjauan lanjutan. Skor dan vektor berasal dari koordinator CVE, dan angka bisa berubah setelah analisis kedua selesai. Untuk perencanaan penambalan, itu tidak mengubah urutan prioritas: sembilan koma dua dengan dampak tinggi di tiga sisi sudah cukup untuk masuk daftar teratas.
Apa dampak praktisnya untuk layanan yang memakai kompresi Brotli?
Dampaknya adalah kebutuhan penambalan berlapis, dan bukan hanya di server web. Kalau layanan menerima body terkompresi dari klien atau dari layanan lain, jalur masuknya bukan hanya respons yang dikirim ke pengguna.
Banyak tim memfokuskan kompresi pada sisi keluar, karena itu yang terlihat di dasbor performa. Padahal dekompresi juga berjalan di sisi masuk ketika ada klien yang mengirim body terkompresi, dan di sisi internal ketika antar layanan bertukar data terkompresi. Setiap tempat yang memanggil decoder adalah permukaan yang perlu dihitung.
Langkah mitigasi sementara yang wajar, sebelum penambalan selesai: batasi ukuran body terkompresi yang diterima, batasi ukuran hasil dekompresi, dan tolak permintaan dengan rasio kompresi yang tidak masuk akal. Tiga batas ini tidak menambal bug, tetapi mempersempit ruang gerak payload yang bisa dikirim penyerang, dan itu sering cukup untuk menahan eksploitasi otomatis di tahap awal.
Untuk layanan publik, hitung juga ketergantungan tidak langsung. Server web modern jarang menangani kompresi sendiri, tetapi menyerahkannya ke komponen lain. Kalau komponen itu memakai Brotli versi lama, memutakhirkan server web saja tidak menyelesaikan apa pun.
Mengapa library HTTP ikut disorot dalam kasus ini?
Karena Brotli hampir selalu dipakai sebagai lapisan di dalam library HTTP, bukan sebagai program terpisah. Ketika sebuah library klien atau server menyertakan decoder Brotli untuk mendukung content-encoding br, versi decoder itulah yang menentukan apakah jalur tersebut rentan.
Pola ini berulang di ekosistem. Library HTTP yang ingin hemat dependensi sering membundel implementasi kompresi sendiri, lalu lupa memperbaruinya ketika ada perbaikan keamanan. Pemilik aplikasi melihat library HTTP versi terbaru di berkas dependensi dan menyimpulkan semuanya aman, padahal komponen di dalamnya bisa tertinggal beberapa tahun.
Karena itu, pertanyaan yang tepat bukan hanya versi library HTTP apa yang dipakai, tetapi versi decoder apa yang ikut dikompilasi ke dalamnya. Untuk proyek yang membangun dari sumber, jawabannya ada di berkas konfigurasi build dan lock file. Untuk proyek yang memakai paket siap pakai, jawabannya ada di catatan rilis paket tersebut, dan tidak semua pemelihara mencantumkannya.
Kalau jawaban itu tidak tersedia, ada dua pilihan yang jujur. Pertama, perlakukan paket tersebut sebagai belum terverifikasi dan tambahkan pembatasan ukuran body sebagai lapisan pengaman. Kedua, ganti ke jalur yang memakai library sistem, sehingga pembaruan keamanan bisa masuk lewat mekanisme paket yang sudah ada. Pilihan kedua lebih rapi untuk jangka panjang, tetapi menuntut pengujian ulang karena perilaku kompresi bisa berbeda sedikit.
Satu langkah yang sering dilewatkan: catat versi sebelum dan sesudah penambalan di tiket perubahan. Tanpa catatan itu, audit enam bulan kemudian tidak bisa membuktikan apakah sistem sudah keluar dari rentang terdampak atau belum. Untuk CVE dengan rentang selebar 1.0.3 sampai 1.2.0, bukti versi jauh lebih berguna daripada ingatan siapa pun yang menambal hari ini.
Untuk layanan yang tidak bisa segera naik versi, pembatasan di lapisan proxy tetap berguna sebagai penahan sementara. Tetapi penahan itu harus diberi tanggal kedaluwarsa. Mitigasi yang dibiarkan berjalan tanpa tenggat berubah menjadi konfigurasi permanen, dan konfigurasi permanen yang lahir dari keadaan darurat biasanya tidak pernah ditinjau lagi.
FAQ
Apakah CVE-2026-111497 memengaruhi semua sistem operasi?
Ya. Deskripsi resminya menyebut semua platform, karena bug berada di kode decoder yang portabel. Yang membedakan risiko antar sistem bukan sistem operasinya, melainkan versi Brotli dan cara komponen itu dibundel ke dalam aplikasi.
Apakah cukup memperbarui paket sistem?
Belum tentu. Kalau Brotli dikompilasi sebagai static library saat build, versi lama ikut tertanam di biner. Paket sistem yang baru tidak mengubah biner tersebut, sehingga aplikasi perlu dibangun ulang.
Ke versi mana sebaiknya naik dari 1.2.0?
Ke 1.2.1. Rentang terdampak pada data CVE adalah 1.0.3 sampai 1.2.0, dan perbaikannya disebutkan untuk tiga jalur, yaitu 1.0.10, 1.1.1, dan 1.2.1 sesuai jalur mayor yang sedang dipakai.
Seberapa mendesak kerentanan ini?
Skor CVSS 4.0 dari koordinator CVE adalah 9.2 dengan tingkat kritis, dan eksploitasinya tidak butuh hak istimewa maupun interaksi pengguna. Treat sebagai prioritas penambalan tinggi untuk setiap komponen yang bisa dijangkau jaringan.
Apakah ada bukti eksploitasi di lapangan?
Belum ada data publik yang dikutip basis data NVD soal eksploitasi aktif, dan status CVE masih Awaiting Analysis. Ketidakhadiran bukti itu bukan jaminan aman, karena waktu dari publikasi ke eksploitasi untuk kelas bug ini cenderung singkat.
💬 Komentar (0)
Belum ada komentar. Jadilah yang pertama! 💬