Laporan Keamanan Minggu Ini: 3.754 CVE Baru, 1.766 Masuk Daftar KEV

Sepanjang tujuh hari terakhir, National Vulnerability Database (NVD) menerima 3.754 kerentanan baru. Pada periode yang sama, katalog Known Exploited Vulnerabilities (KEV) milik CISA kini memuat 1.766 entri yang sudah terbukti dieksploitasi di lapangan. Angka pertama mengukur arus pelaporan, angka kedua mengukur ancaman nyata. Dua entri KEV terbaru bahkan menunjuk produk yang sama, Ivanti Connect Secure, dan keduanya ditambahkan pada tanggal yang sama, 30 Oktober 2026.

TL;DR

• NVD mencatat 3.754 CVE baru dalam tujuh hari terakhir, data ditarik 1 November 2026 pukul 06.40 WIB.
• Katalog KEV CISA berisi 1.766 entri, versi katalog 30 Oktober 2026 pukul 17.02 UTC.
• Dua dari tiga entri KEV terbaru menyasar Ivanti Connect Secure, keduanya tertanggal 30 Oktober 2026.
• Entri ketiga menyasar GitLab Community Edition dan Enterprise Edition, tertanggal 29 Oktober 2026.

Kenapa Dua Angka Ini Tidak Boleh Dibaca dengan Cara yang Sama

NVD adalah arsip, bukan alarm. Setiap laporan kerentanan yang masuk diberi pengenal CVE, dianalisis, lalu diberi skor keparahan. Angka 3.754 dalam sepekan adalah ukuran besarnya arus kerja industri keamanan, bukan ukuran berapa banyak sistem yang benar-benar diserang pekan ini. Sebagian besar kerentanan itu menuntut akses lokal, konfigurasi yang tidak lazim, atau rantai eksploitasi yang rumit. Sebagian lain bahkan belum punya bukti eksploitasi sama sekali.

Katalog KEV bekerja dengan logika terbalik. CISA hanya memasukkan kerentanan yang punya bukti eksploitasi aktif di dunia nyata. Karena itu daftarnya jauh lebih pendek, tetapi bobot tiap entrinya jauh lebih berat. Ketika sebuah CVE masuk KEV, pertanyaannya bukan lagi "apakah ini berbahaya", melainkan "berapa lama lagi sistem kita tetap terbuka". Selisih antara dua daftar inilah yang menentukan prioritas: 3.754 laporan untuk dibaca, 1.766 entri untuk ditindaklanjuti.

Kesalahan paling umum di tim operasional adalah menyamakan keduanya. Ada yang mengukur keberhasilan pemeliharaan dari jumlah CVE yang berhasil ditutup, padahal yang menentukan risiko adalah berapa entri KEV yang menyentuh aset mereka. Ada juga yang mengabaikan NVD sepenuhnya karena "belum tentu dieksploitasi", padahal kerentanan hari ini bisa berpindah status menjadi KEV dalam hitungan hari begitu exploit publik beredar.

Angka Pekan Ini dalam Satu Tabel

Indikator	Nilai	Sumber	Tanggal acuan
Kerentanan baru NVD (7 hari terakhir)	3.754	NVD	2026-11-01 06.40 WIB
Total entri katalog KEV CISA	1.766	CISA KEV	2026-10-30 17.02 UTC
KEV terbaru: Ivanti Connect Secure	CVE-2026-118527	CISA KEV	2026-10-30
KEV terbaru: Ivanti Connect Secure	CVE-2026-111357	CISA KEV	2026-10-30
KEV terbaru: GitLab CE dan EE	CVE-2026-97229	CISA KEV	2026-10-29

Perbandingan dengan Laporan Terakhir di Arsip

Laporan keamanan mingguan terakhir yang tersimpan di arsip toolkuy dirilis 2 Oktober 2026 dengan angka 3.636 CVE baru dan 1.731 entri KEV. Selisih terhadap angka hari ini bisa dilihat di tabel berikut. Perlu dicatat, ini perbandingan antar dua titik pengambilan data yang berjarak sebulan, bukan perbandingan pekan ke pekan, karena arsip mingguan di antaranya tidak tersedia.

Indikator	2 Oktober 2026	1 November 2026	Selisih
CVE baru per tujuh hari	3.636	3.754	+118 atau +3,2 persen
Total entri katalog KEV	1.731	1.766	+35 entri

Dua hal bisa dibaca dari tabel itu. Pertama, laju pelaporan CVE relatif datar: 3.636 menjadi 3.754 hanya bergerak 3,2 persen dalam sebulan. Kedua, katalog KEV bertambah 35 entri dalam periode yang sama. Angka kedua itulah yang lebih penting, karena setiap penambahan berarti ada celah baru yang sudah dipakai penyerang sungguhan, dan 35 celah baru dalam sebulan berarti tim yang menambal sesuai jadwal triwulanan hampir pasti tertinggal.

Apa Bedanya CVE di NVD dan Entri di Katalog KEV?

CVE adalah pengenal unik untuk satu kerentanan, sedangkan KEV adalah daftar kurasi yang hanya memuat kerentanan dengan bukti eksploitasi aktif. Sebuah CVE bisa punya skor tinggi tetapi tidak pernah masuk KEV, dan sebaliknya ada entri KEV dengan skor menengah yang jauh lebih mendesak karena sudah dipakai di lapangan. Karena itu, dua daftar ini harus dibaca sebagai dua pertanyaan berbeda: NVD menjawab "apa yang baru ditemukan", KEV menjawab "apa yang sudah dipakai menyerang".

Bagi organisasi, konsekuensinya praktis. Katalog KEV bisa dipakai langsung sebagai sumber tiket prioritas tanpa perlu debat internal soal tingkat keparahan. NVD lebih tepat dipakai sebagai bahan pemantauan tren dan perencanaan pemeliharaan rutin. Angka 1.766 entri KEV juga bukan berarti 1.766 kerentanan baru menyerang perusahaan Anda. Yang perlu dicocokkan adalah irisan antara isi katalog dan inventaris perangkat yang benar-benar dipakai.

Tiga Entri KEV Terbaru: Mana yang Harus Ditambal Duluan?

Dua dari tiga entri terbaru menyasar Ivanti Connect Secure dan ditambahkan pada 30 Oktober 2026, jadi perangkat itulah yang paling mendesak untuk diperiksa lebih dulu. Entri ketiga menyasar GitLab Community Edition dan Enterprise Edition, tertanggal 29 Oktober 2026, dan relevan bagi tim yang menjalankan server Git internal.

CVE-2026-118527 pada Ivanti Connect Secure (ditambahkan 30 Oktober 2026). Ivanti Connect Secure adalah gerbang VPN yang berdiri tepat di tepi jaringan dan menerima koneksi dari internet tanpa kredensial lebih dulu. Posisi itu membuat setiap celah di lapisan ini bernilai tinggi bagi penyerang: kompromi pada perangkat tepi berarti pijakan awal yang sah secara jaringan, bukan lalu lintas yang mencurigakan. Organisasi yang memakai perangkat ini sebaiknya memperlakukan entri tersebut sebagai pekerjaan hari ini, bukan item backlog.

CVE-2026-111357 pada Ivanti Connect Secure (ditambahkan 30 Oktober 2026). Entri kedua pada produk yang sama di tanggal yang sama menunjukkan pola yang layak diperhatikan: dua celah berbeda pada satu perangkat tepi dalam satu gelombang pembaruan. Kalau satu perangkat punya dua entri KEV sekaligus, asumsinya harus dibalik, yaitu menganggap perangkat itu sudah menjadi target pemindaian otomatis dan belum tentu masih bersih. Pemeriksaan integritas konfigurasi setelah penambalan jadi langkah yang sama pentingnya dengan penambalan itu sendiri.

CVE-2026-97229 pada GitLab Community Edition dan Enterprise Edition (ditambahkan 29 Oktober 2026). GitLab menyentuh dua sisi sekaligus: ia menyimpan kode sumber, dan ia menjalankan pipeline CI yang biasanya memegang kredensial deployment. Server Git yang belum ditambal bukan hanya berisiko kehilangan kode, tetapi juga berisiko membocorkan token, kunci registry, dan akses ke lingkungan produksi. Bagi tim yang menjalankan GitLab self-hosted, urutan yang aman adalah menambal lebih dulu, lalu merotasi kredensial yang pernah dipakai pipeline di mesin tersebut.

Pola dari ketiganya cukup jelas: perangkat tepi jaringan dan server pengembangan internal sama-sama jadi sasaran. Keduanya sering luput dari jadwal pemeliharaan karena dianggap "infrastruktur pendukung", padahal justru di situ kredensial dan jalur masuk berbagi tempat.

Bagaimana Menyusun Urutan Patching untuk Tim Kecil?

Mulailah dari irisan antara katalog KEV dan inventaris aset, bukan dari skor keparahan tertinggi. Cara ini memotong pekerjaan dari ribuan laporan menjadi daftar pendek yang benar-benar menyentuh sistem yang dipakai. Setelah irisan itu didapat, urutkan berdasarkan eksposur: aset yang menghadap internet lebih dulu, aset internal menyusul.

Langkah yang bisa dijalankan berurutan:

1. Tarik feed KEV resmi CISA secara berkala, minimal sekali sehari, ke basis data internal.
2. Cocokkan kolom produk dan vendor pada feed dengan inventaris aset, termasuk perangkat tepi yang sering tidak tercatat.
3. Tandai setiap kecocokan sebagai tiket prioritas tinggi otomatis, tanpa menunggu rapat mingguan.
4. Pasang tambalan pada jendela pemeliharaan terdekat, lalu verifikasi versi yang benar-benar berjalan, bukan hanya status "sudah dijadwalkan".
5. Rotasi kredensial yang tersimpan di perangkat terdampak, khususnya untuk server yang memegang token deployment.
6. Simpan catatan waktu tambalan dan waktu verifikasi, karena dua angka itu yang diminta auditor saat insiden.

Pipeline semacam ini butuh tempat tinggal yang tidak berbagi sumber daya dengan layanan produksi. Pekerjaan terjadwal yang menembak API NVD dan CISA setiap beberapa jam sebaiknya tidak jalan di mesin yang melayani pengguna. VPS terpisah seperti Alibaba Cloud ECS bisa dipakai untuk menampung cron pengumpul feed, basis data pencocokan aset, dan staging pengujian tambalan sebelum menyentuh server utama. Prinsipnya sederhana: mesin yang menguji tambalan justru yang paling mungkin di-reboot, jadi jangan taruh di tempat yang sama dengan produksi.

Peran Model Bahasa dalam Triase

Beban terberat dalam menangani ribuan laporan CVE bukan pemasangan tambalannya, melainkan membaca deskripsi dan menentukan mana yang relevan. Model bahasa cukup membantu untuk pekerjaan itu: meringkas deskripsi CVE, mengelompokkan produk terdampak, dan menyusun daftar prioritas harian dari feed yang panjang. Dengan begitu, analis hanya membaca entri yang menyentuh aset organisasi.

Batasannya harus tegas. Ringkasan otomatis tidak boleh menjadi dasar keputusan tambalan tanpa rujukan ke entri aslinya, karena kesalahan klasifikasi pada satu CVE bisa berarti satu server produksi terlewat. Untuk volume teks besar seperti ini, layanan inferensi berbasis token seperti paket token AI Alibaba Cloud bisa dipakai agar biaya pemrosesan tetap terukur, sementara keputusan akhir tetap di tangan manusia yang memegang inventaris.

Keterbatasan Data

Beberapa hal perlu dicatat agar angka dalam laporan ini tidak ditafsirkan berlebihan.

1. Jendela waktu berbeda. Angka 3.754 adalah jumlah kerentanan yang tercatat NVD dalam tujuh hari terakhir. Angka 1.766 adalah total akumulatif seluruh entri KEV sampai versi katalog 30 Oktober 2026. Keduanya tidak bisa dijumlahkan atau dibandingkan langsung.
2. Penundaan publikasi. Ada jeda antara saat kerentanan dilaporkan, dianalisis, diberi skor, dan dipublikasikan. Kerentanan yang baru ditemukan bisa belum muncul di NVD saat data ditarik, sehingga angka sebenarnya berpotensi lebih tinggi.
3. KEV hanya memuat yang terbukti dieksploitasi. Banyak kerentanan berbahaya tidak pernah masuk KEV karena tidak ada bukti eksploitasi publik, bukan karena tidak berbahaya. Tidak adanya entri di KEV bukan jaminan aman.
4. Perbandingan antar bulan. Angka pembanding berasal dari laporan 2 Oktober 2026, sehingga selisih yang ditampilkan mencakup sebulan, bukan satu pekan. Arsip mingguan di antara kedua tanggal tersebut tidak tersedia.
5. Tidak ada skor keparahan. Brief data hari ini tidak menyertakan skor CVSS untuk tiga entri KEV terbaru, jadi laporan ini tidak mencantumkan angka CVSS. Skor resmi perlu dicek langsung di halaman detail NVD masing-masing CVE sebelum dipakai dalam keputusan internal.

Kesimpulan

Pekan ini menempatkan 3.754 kerentanan baru di NVD dan 1.766 entri di katalog KEV CISA. Yang paling layak dikerjakan lebih dulu bukan membaca seluruh daftar, melainkan mencocokkan katalog KEV dengan inventaris aset, dimulai dari Ivanti Connect Secure yang menerima dua entri baru sekaligus pada 30 Oktober 2026, lalu GitLab CE dan EE yang menyentuh jalur pipeline dan kredensial deployment. Tambalan yang cepat pada dua titik itu memberi pengurangan risiko jauh lebih besar daripada mengejar ratusan CVE berskor tinggi yang belum pernah dipakai menyerang.

Sumber

Angka dan entri dalam laporan ini merujuk pada sumber resmi berikut, diakses 1 November 2026 pukul 06.40 WIB:

• NVD Dashboard untuk hitungan kerentanan baru tujuh hari terakhir.
• CISA Known Exploited Vulnerabilities Catalog untuk total entri dan tanggal penambahan.
• Feed JSON resmi katalog KEV sebagai sumber data mentah yang ditarik pipeline.
• Detail CVE-2026-118527 di NVD, CVE-2026-111357, dan CVE-2026-97229.
• GitLab Security Releases untuk jalur pembaruan resmi GitLab.
• Ivanti Security Advisories untuk pengumuman produk Ivanti Connect Secure.
• Spesifikasi CVSS v4.0 FIRST sebagai rujukan cara membaca skor keparahan.

Laporan mingguan sebelumnya yang dipakai sebagai pembanding: laporan 2 Oktober 2026.

FAQ

Apakah 3.754 CVE berarti ada 3.754 serangan baru pekan ini?

Bukan. Angka itu adalah jumlah kerentanan yang tercatat di NVD dalam tujuh hari, bukan jumlah serangan. Sebagian besar belum punya bukti eksploitasi. Yang menunjukkan serangan nyata adalah katalog KEV, dan di sana tercatat 1.766 entri akumulatif sampai 30 Oktober 2026.

Kenapa Ivanti Connect Secure muncul dua kali di entri KEV terbaru?

Karena dua celah berbeda pada produk yang sama ditambahkan pada tanggal yang sama, 30 Oktober 2026, yaitu CVE-2026-118527 dan CVE-2026-111357. Bagi pemakai perangkat itu, artinya pemeriksaan harus mencakup dua jalur masuk sekaligus, bukan satu tambalan tunggal.

Apakah GitLab self-hosted wajib langsung ditambal?

Sangat disarankan begitu masuk KEV, seperti CVE-2026-97229 pada 29 Oktober 2026. Server Git biasanya memegang kredensial pipeline dan akses deployment, sehingga kompromi di sana berdampak ke lingkungan produksi. Setelah menambal, rotasi token yang pernah dipakai pipeline adalah langkah lanjutan yang wajib.

Berapa lama jendela aman sebelum CVE baru dieksploitasi?

Tidak ada angka tunggal yang bisa dipakai, dan laporan ini tidak mengarangnya. Indikator yang bisa dipegang adalah status KEV: begitu sebuah CVE masuk daftar itu, eksploitasi sudah terbukti terjadi. Sebelum masuk KEV, kecepatan bergantung pada industri, popularitas produk, dan ketersediaan exploit publik.

Dari mana angka total 1.766 entri KEV diambil?

Dari feed JSON resmi katalog KEV CISA yang ditarik pipeline pada 1 November 2026 pukul 06.40 WIB. Versi katalog yang terbaca bertanggal 30 Oktober 2026 pukul 17.02 UTC, sehingga setiap penambahan setelah waktu itu belum tercermin dalam laporan ini.