Dalam tujuh hari terakhir, National Vulnerability Database (NVD) mencatat 3.662 kerentanan perangkat lunak baru, sementara katalog Known Exploited Vulnerabilities (KEV) milik CISA kini memuat 1.734 entri yang sudah terbukti dieksploitasi di lapangan. Dua angka ini penting bagi tim yang mengelola server produksi, karena keduanya mengukur hal berbeda: NVD menunjukkan besarnya arus laporan, KEV menunjukkan mana yang benar-benar dipakai penyerang. Laporan ini merangkum angka terverifikasi pekan ini, tiga entri KEV terbaru, dan cara menyusun prioritas tambalan.
TL;DR
- NVD mencatat 3.662 kerentanan baru dalam tujuh hari terakhir, diambil per 2026-10-07.
- Katalog KEV CISA kini berisi 1.734 entri yang sudah terbukti dieksploitasi, rilis data 2026-10-04.
- Tiga entri KEV terbaru menyasar Citrix NetScaler (CVE-2026-88779) dan Zammad (CVE-2026-102490 serta CVE-2026-102489).
- Urutan prioritas yang sehat: tambal dulu produk yang muncul di KEV, sisanya mengikuti jadwal pemeliharaan rutin.
Ringkasan Angka Pekan Ini
| Indikator | Nilai | Sumber | Tanggal data |
|---|---|---|---|
| Kerentanan baru NVD (7 hari terakhir) | 3.662 | NVD | 2026-10-07 |
| Total entri katalog KEV CISA | 1.734 | CISA KEV | 2026-10-04 |
| KEV terbaru: Citrix NetScaler | CVE-2026-88779 | CISA KEV | 2026-10-04 |
| KEV terbaru: Zammad | CVE-2026-102490 | CISA KEV | 2026-10-02 |
| KEV terbaru: Zammad | CVE-2026-102489 | CISA KEV | 2026-10-02 |
Apa Perbedaan NVD dan Daftar KEV CISA?
NVD adalah arsip terbuka yang mendokumentasikan setiap kerentanan yang dilaporkan, diberi skor, dan dipublikasikan, sedangkan KEV adalah daftar pendek yang hanya memuat kerentanan dengan bukti eksploitasi nyata di lapangan. Keduanya diterbitkan lembaga resmi Amerika Serikat, yaitu NIST untuk NVD dan CISA untuk KEV, serta bisa diakses bebas tanpa biaya.
Perbedaan paling praktis ada di ukurannya. Angka 3.662 dalam sepekan adalah ukuran arus informasi, bukan ukuran ancaman. Sebaliknya, 1.734 entri KEV berarti ada 1.734 celah yang sudah pernah dipakai penyerang, dan hampir semuanya masih bisa dipakai ulang selama tambalan belum terpasang. Karena itu, tim yang membaca kedua daftar ini dengan benar tidak akan tenggelam mengejar ribuan laporan baru setiap pekan. Mereka memakai NVD untuk pemantauan menyeluruh, dan KEV untuk menentukan mana yang harus dikerjakan lebih dulu.
Yang perlu diingat, skor tinggi di NVD tetap layak diperhatikan. Kerentanan yang hari ini belum dieksploitasi bisa berpindah status menjadi KEV dalam hitungan hari begitu exploit publik beredar. Jadi NVD berfungsi sebagai radar, sementara KEV berfungsi sebagai sirene. Identitas setiap kerentanan sendiri dikelola lewat CVE Program, yang memberi nomor unik seperti CVE-2026-88779 agar rujukan antar sistem tetap konsisten.
Kerentanan Apa Saja yang Baru Masuk Daftar KEV Pekan Ini?
Tiga entri terbaru pada katalog KEV CISA menunjukkan pola sasaran yang cukup konsisten, mulai dari perangkat tepi jaringan sampai aplikasi layanan pelanggan. Berikut rinciannya.
1. CVE-2026-88779 pada Citrix NetScaler (ditambahkan 2026-10-04). NetScaler adalah gerbang aplikasi dan penyeimbang beban yang lazim dipakai organisasi untuk mengatur lalu lintas masuk. Karena posisinya tepat di tepi jaringan dan menangani koneksi eksternal dalam jumlah besar, celah pada perangkat semacam ini punya nilai strategis tinggi bagi penyerang. Organisasi yang menjalankan NetScaler sebaiknya memperlakukan entri ini sebagai prioritas pemasangan tambalan, bukan item backlog yang menunggu senggang.
2. CVE-2026-102490 pada Zammad (ditambahkan 2026-10-02). Zammad adalah perangkat lunak helpdesk dan layanan pelanggan yang menyimpan tiket, percakapan, dan data pelanggan. Kompromi pada sistem ini berarti penyerang berpotensi membaca isi percakapan internal maupun data pelanggan yang tersimpan di dalamnya. Dampaknya bukan hanya teknis, tetapi juga menyangkut kerahasiaan data dan kepatuhan.
3. CVE-2026-102489 pada Zammad (ditambahkan 2026-10-02). Entri kedua pada hari yang sama menegaskan bahwa satu produk bisa menyumbang lebih dari satu celah dalam waktu berdekatan. Untuk tim yang memakai Zammad, dua entri ini sebaiknya ditangani dalam satu jendela pemeliharaan, bukan dipisah, supaya versi yang berjalan langsung bersih dari keduanya.
Pola dari ketiganya cukup jelas. Perangkat tepi jaringan dan aplikasi layanan pelanggan sama-sama jadi sasaran. Tidak ada satu titik yang bisa diabaikan tanpa membuka celah di titik lain.
Bagaimana Cara Menyusun Prioritas Tambalan yang Benar?
Prioritas tambalan yang benar berangkat dari inventaris aset, bukan dari daftar kerentanan. Langkah pertama adalah mengetahui produk dan versi apa saja yang benar-benar berjalan di lingkungan organisasi, lalu mencocokkannya dengan daftar KEV. Tanpa inventaris yang rapi, tim akan kesulitan menilai apakah sebuah CVE relevan atau tidak.
Setelah inventaris tersedia, alur kerja yang sehat sebaiknya berjalan otomatis, bukan manual. Beberapa langkah yang bisa diterapkan tim kecil sekalipun:
- Tarik feed NVD dan KEV secara berkala ke basis data internal, lalu simpan tanggal pengambilannya.
- Cocokkan daftar kerentanan dengan inventaris aset yang benar-benar dipakai, bukan seluruh katalog.
- Tandai aset yang muncul di KEV sebagai tiket prioritas tinggi secara otomatis.
- Jalankan pemasangan tambalan pada jendela pemeliharaan yang sudah disepakati.
- Catat setiap langkah beserta tanggalnya agar bisa diaudit saat insiden terjadi.
Untuk menjalankan pipeline semacam ini, banyak tim menempatkan worker penarik data di server virtual privat (VPS) yang terpisah dari server aplikasi utama. Tujuannya sederhana: pekerjaan terjadwal yang menembak API eksternal setiap beberapa jam sebaiknya tidak berbagi sumber daya dengan layanan yang melayani pengguna. Infrastruktur cloud seperti Alibaba Cloud ECS bisa dipakai untuk menampung cron pengumpul data, basis data pencocokan aset, dan antrean tiket tanpa mengganggu mesin produksi.
Salah satu hambatan terbesar dalam menangani ribuan laporan CVE adalah membaca deskripsinya satu per satu. Model bahasa kini cukup matang untuk meringkas deskripsi CVE, memetakan produk terdampak ke inventaris internal, dan menyusun ringkasan prioritas harian untuk tim. Untuk keperluan ini, layanan inferensi berbasis token seperti Alibaba Cloud AI Service dapat dipakai memproses teks CVE dalam jumlah besar dengan biaya yang terkendali. Yang perlu dijaga adalah verifikasi: setiap ringkasan otomatis tetap harus bisa dilacak kembali ke entri aslinya di NVD atau CISA, sehingga tidak ada keputusan tambalan yang berdiri di atas teks tanpa rujukan.
Tim yang sudah punya pipeline keamanan bisa menautkan langkah ini dengan pembahasan sebelumnya di toolkuy, misalnya catatan tentang OpenBao v2.7 dan kriptografi post-kuantum serta laporan Lightwell dan 400+ kerentanan pustaka Java. Keduanya menunjukkan sisi lain dari persoalan yang sama: kerentanan tidak hanya datang dari kode yang kita tulis sendiri, tetapi juga dari pustaka pihak ketiga yang kita pakai.
Keterbatasan Data
Beberapa hal perlu dicatat agar angka dalam laporan ini tidak ditafsirkan berlebihan.
- Jendela waktu berbeda. Angka 3.662 adalah jumlah kerentanan yang tercatat NVD dalam tujuh hari terakhir, sedangkan 1.734 adalah total akumulatif seluruh entri KEV CISA sampai tanggal rilis data. Keduanya tidak bisa dijumlahkan atau dibandingkan langsung karena mengukur rentang waktu yang berbeda.
- Penundaan publikasi. Setiap kerentanan punya jeda antara saat dilaporkan, dianalisis, diberi skor, dan dipublikasikan. Kerentanan yang baru ditemukan mungkin belum muncul di NVD saat data ini ditarik, sehingga angka sebenarnya bisa lebih tinggi dari yang tercatat.
- KEV hanya mencerminkan yang terbukti dieksploitasi. Banyak kerentanan berbahaya tidak pernah masuk KEV karena tidak ada bukti eksploitasi publik, bukan karena tidak berbahaya. Ketiadaan entri di KEV bukan jaminan aman.
- Kegagalan sumber. Pada proses pengambilan data kali ini, sumber World Bank mengalami timeout sehingga tidak disertakan. Karena itu, laporan ini hanya memakai sumber yang berhasil diverifikasi, yaitu NVD dan CISA KEV. Tidak ada angka dari sumber yang gagal yang dikarang atau diperkirakan.
FAQ
Apakah semua CVE di NVD berbahaya?
Tidak. NVD memuat semua kerentanan yang dilaporkan, termasuk yang dampaknya kecil dan sulit dieksploitasi. Yang menentukan urgensi bukan sekadar ada tidaknya entri, tetapi apakah kerentanan itu sudah terbukti dipakai di lapangan seperti pada daftar KEV.
Mengapa daftar KEV jauh lebih pendek dari NVD?
Karena KEV hanya memuat kerentanan yang punya bukti eksploitasi nyata, bukan seluruh laporan yang masuk. CISA sengaja menjaga daftar ini tetap ringkas agar tim operasional bisa mengejarnya tanpa kehabisan tenaga.
Apakah produk saya aman kalau tidak ada di KEV?
Belum tentu. Ketiadaan entri hanya berarti belum ada bukti eksploitasi publik pada saat data ditarik. Kerentanan tetap bisa muncul di KEV beberapa hari kemudian, terutama setelah exploit beredar.
Seberapa cepat tambalan harus dipasang?
Untuk entri KEV, sebaiknya secepat jadwal pemeliharaan terdekat, idealnya dalam hitungan hari, bukan minggu. Semakin lama jendela terbuka, semakin besar kemungkinan pemindai otomatis menemukan sistem yang belum ditambal.
Sumber
Angka dan entri dalam laporan ini merujuk langsung pada sumber resmi berikut, diakses pada 2026-10-07:
💬 Komentar (0)
Belum ada komentar. Jadilah yang pertama! 💬