Pada 30 September 2026, pukul 4 sore waktu Riyadh, Cisco menerbitkan advisori keamanan untuk CVE-2026-76504 di Cisco Catalyst SD-WAN Manager, sistem yang digunakan perusahaan dengan banyak cabang untuk menjalankan seluruh jaringan cabangnya dari satu layar. Skor keparahannya 9.8 dari 10, eksploitasi tidak memerlukan akun maupun kata sandi, Cisco menyatakan mengetahui adanya eksploitasi aktif selama September, dan tidak ada solusi sementara. Pada hari yang sama, Otoritas Keamanan Siber Nasional Arab Saudi (NCA) mengeluarkan peringatan 2026-7889 dengan tingkat keparahan Kritis, meminta organisasi meninjau advisori tersebut dan menerapkan pembaruan.

Pertanyaan kuncinya bukan teknis: siapa yang menambal?

Dua minggu lalu kami menulis tentang celah yang dieksploitasi di perangkat Cisco lain, yaitu perangkat yang mengatur identitas dan akses, dan di sana kami membahas dasar-dasar manajemen kerentanan. Kali ini pertanyaan terpentingnya bukan soal teknis. Bisa jadi Anda sama sekali tidak menjalankan jaringan cabang Anda sendiri: operator telekomunikasi atau perusahaan TI mungkin menjalankannya untuk Anda berdasarkan kontrak layanan terkelola. Jika demikian, siapa yang memperbarui sistem malam ini, siapa yang memeriksa apakah ada yang masuk sebelum pembaruan, dan apa kata kontrak Anda jika keduanya tidak terjadi?

Apa yang sebenarnya diterbitkan Cisco

Berita ini baru berumur beberapa jam, jadi fakta-fakta berikut berasal langsung dari advisori Cisco dan peringatan NCA, bukan dari liputan media:

  • Produk: Cisco Catalyst SD-WAN Manager, sebelumnya dikenal sebagai vManage. Advisori menyatakan produk ini terdampak bagaimana pun konfigurasinya.
  • Penyebab: penanganan enkode URI yang tidak tepat dalam permintaan HTTP memungkinkan permintaan yang dirancang khusus melewati aturan autentikasi yang dimaksudkan untuk melindungi endpoint API tertentu, sehingga penyerang menjangkau API dengan hak akses pengguna admin.
  • Prasyarat: tidak ada. Penyerang jarak jauh tanpa autentikasi, dan skor dasar CVSS 9.8.
  • Status: dieksploitasi secara aktif. Cisco PSIRT menyatakan mengetahui eksploitasi tersebut pada September 2026, dan celah ini ditemukan saat menyelesaikan kasus dukungan Cisco Technical Assistance Center.
  • Solusi sementara: tidak ada. Perbaikannya adalah memperbarui ke rilis yang sudah diperbaiki.
  • Peringatan lokal: peringatan NCA 2026-7889, tertanggal 30 September 2026. Peringatan ini mencantumkan 14 sektor sasaran, praktis semuanya, mulai dari perdagangan dan investasi, keuangan dan ekonomi serta kesehatan hingga pendidikan, transportasi, dan manufaktur.

Rilis yang sudah diperbaiki, menurut advisori:

Jalur rilis saat iniRilis perbaikan pertama
Lebih lama dari 20.9Migrasi ke rilis yang sudah diperbaiki
20.920.9.10.1
20.1220.12.8.2
20.1520.15.6.1
20.1820.18.4.1
26.126.1.2.1
26.226.2.1

Perhatikan baris pertama. Siapa pun yang menggunakan rilis lebih lama dari 20.9 tidak sedang menghadapi pembaruan kecil, melainkan perpindahan ke jalur rilis lain. Itu memerlukan perencanaan, dan tidak bisa ditunda.

Mengapa sistem ini secara khusus

Jaringan SD-WAN menghubungkan cabang, gudang, dan kantor pusat melalui koneksi apa pun yang tersedia, dan semuanya dikelola dari satu sistem pusat. Di sanalah kebijakan ditulis: lalu lintas mana yang melewati jalur mana, cabang mana yang bisa menjangkau sistem mana, dan pengaturan apa yang dikirim ke router di setiap lokasi. Satu perubahan di pusat menjangkau setiap cabang. Itulah tujuannya.

Fitur yang sama itulah bahayanya. Siapa pun yang menjangkau API sistem ini dengan hak akses admin tidak sedang berhadapan dengan satu perangkat, melainkan dengan konsol yang mengelola konfigurasi seluruh jaringan. Titik penjualan di cabang, jalur ke gudang, dan akses ke sistem akuntansi dari luar kantor pusat mungkin semuanya berjalan di atas jaringan yang dikendalikan sistem ini. Sistem ini layak berada di urutan teratas daftar aset kritis, sejauh apa pun ia tampak dari pengelolaan sehari-hari.

Cloud Cisco atau pusat data Anda? Itu yang menentukan siapa yang bertindak

Advisori membedakan dua cara menjalankan sistem ini, dan perbedaannya sangat praktis:

  • Di cloud Cisco: advisori menyatakan bahwa celah ini memengaruhi SD-WAN Manager apa pun konfigurasinya, dan menjelaskan dua kasus cloud. Di lingkungan Cisco Catalyst SD-WAN Cloud Hosted, Cisco sudah menerapkan mitigasi berupa pembatasan akses, tetapi mitigasi bukanlah perbaikan, sehingga pembaruan ke rilis yang sudah diperbaiki dari tabel di atas tetap diperlukan, dan Anda perlu menanyakan siapa yang melakukannya. Di Cisco SD-WAN Cloud (Cisco Managed), rilis 20.15.605 mengatasi celah ini, Cisco menyatakan tidak perlu tindakan pengguna, dan versinya dapat diperiksa melalui fungsi Help di antarmuka layanan. Hanya pada kasus terakhir inilah pembaruan menjadi tanggung jawab vendor. Tugas Anda tetap meminta konfirmasi tertulis dan meminta agar log ditinjau untuk periode sebelumnya.
  • On-premise, di lokasi Anda atau di pusat data penyedia Anda: di sini tidak ada yang akan memperbarui sistem untuk Anda kecuali kontrak menyatakannya. Hingga pembaruan dilakukan, mitigasi yang dijelaskan Cisco adalah membatasi akses ke sistem dari jaringan yang tidak aman seperti internet, dan melindungi komponen kontrol SD-WAN di balik perangkat penyaring seperti firewall.

Jadi pertanyaan pertamanya bukan apakah Anda menggunakan Cisco. Pertanyaannya adalah di mana sistem manajemen jaringan Anda berjalan dan siapa yang bertanggung jawab memperbaruinya. Jika hanya penyedia yang tahu jawabannya, itulah celah pertama yang harus ditutup, dan itu bukan celah teknis.

Pembaruan tidak memberi tahu apakah ada yang sudah masuk lebih dulu

Cisco mengetahui eksploitasi tersebut selama September dan menerbitkan perbaikan pada hari terakhir bulan itu. Dengan kata lain, celah ini sudah dieksploitasi sebelum ada pembaruan apa pun yang bisa diterapkan. Memperbarui malam ini menutup pintu. Namun itu tidak memberi tahu apakah seseorang sudah melewatinya dan meninggalkan akun atau perubahan konfigurasi.

Karena itulah Cisco menerbitkan indikator yang perlu dicari tim TI atau penyedia Anda di dua log tertentu pada sistem, serviceproxy-access.log dan vmanage-server.log:

  • Permintaan ke j_security_check dari alamat IP yang tidak dikenal atau tidak sah.
  • Karakter apa pun yang dienkode URI di jalur permintaan, seperti %6a_security_check, di mana %6a adalah huruf j yang dienkode. Begitulah eksploit menyelinap melewati aturan autentikasi. Cisco menegaskan bahwa %6a hanyalah contoh: enkode karakter tunggal apa pun dalam permintaan dapat digunakan, sehingga tim harus mencari setiap varian j_security_check yang dienkode, bukan hanya %6a.
  • Khusus di vmanage-server.log: permintaan j_security_check dari alamat tidak dikenal untuk nama pengguna yang diawali viptela-reserved-. Ini adalah akun layanan bawaan sistem, jadi munculnya nama itu di log bukanlah tanda pembobolan dengan sendirinya. Yang penting adalah sumber yang tidak dikenal.

Cisco juga memperingatkan bahwa indikator ini terkadang dapat muncul dalam operasi normal, sehingga perlu dibandingkan dengan aktivitas jaringan yang biasa sebelum menarik kesimpulan.

Pelajaran yang sama muncul minggu ini pada dua celah kritis Citrix NetScaler yang ditambahkan Badan Keamanan Siber dan Keamanan Infrastruktur AS (CISA) ke katalog Kerentanan yang Diketahui Telah Dieksploitasi (Known Exploited Vulnerabilities) pada 27 September. CISA menyatakan para pelaku ancaman mengeksploitasinya secara aktif di seluruh dunia, mendorong organisasi untuk memeriksa tanda-tanda pembobolan sebelum menambal jika memungkinkan, dan menyatakan bahwa setiap organisasi yang mencurigai adanya pembobolan harus mengamankan bukti forensik sebelum menerapkan pembaruan, karena pembaruan dapat menghapus jejak apa yang terjadi. Aturan ini juga berlaku di sini: periksa, simpan salinan log, lalu perbarui, tanpa membiarkan pemeriksaan menjadi alasan untuk menunda pembaruan berhari-hari.

Jika jaringan Anda adalah layanan terkelola: apa isi kontrak Anda?

Kontrol Keamanan Siber Esensial (Essential Cybersecurity Controls) NCA, edisi 2024, mengikat instansi pemerintah dan perusahaan afiliasinya, serta entitas sektor swasta yang memiliki, mengoperasikan, atau menjadi tuan rumah Infrastruktur Nasional Kritis. NCA sangat mendorong semua organisasi lain di Kerajaan untuk menggunakannya. Meskipun perusahaan Anda tidak terikat, kontrol ini adalah rujukan lokal paling jelas tentang apa yang harus ada dalam kontrak penyedia mana pun yang menjalankan sebagian teknologi Anda:

  • Dalam kontrak dengan pihak ketiga yang, jika terganggu, dapat memengaruhi data atau layanan Anda, termasuk perjanjian tingkat layanan: kerahasiaan dan penghapusan data Anda secara aman di akhir layanan, prosedur komunikasi ketika terjadi insiden keamanan siber, dan kewajiban pihak ketiga untuk menerapkan persyaratan dan kebijakan keamanan siber Anda (kontrol 4-1-2).
  • Khusus dalam kontrak dengan penyedia alih daya TI dan layanan terkelola: penilaian risiko keamanan siber, dengan kontrol mitigasi yang telah dipastikan, sebelum penandatanganan, dan pusat layanan terkelola keamanan siber untuk pemantauan dan operasi yang menggunakan akses jarak jauh harus berlokasi sepenuhnya di dalam Kerajaan (kontrol 4-1-3).
  • Dalam manajemen kerentanan: mengklasifikasikan kerentanan berdasarkan tingkat keparahan dan memperbaikinya sesuai klasifikasi tersebut, berlangganan sumber tepercaya untuk berita kerentanan baru, dan memverifikasi pembaruan di lingkungan non-produksi sebelum menerapkannya (kontrol 2-10-3).

Perhatikan apa yang tidak dikatakan kontrol manajemen kerentanan: kontrol ini tidak menetapkan tenggat apa pun untuk menerapkan pembaruan kritis. Angka itu harus dituliskan dalam kontrak Anda sendiri. Jika tidak, penyedia akan menambal ketika ia bisa, bukan ketika Anda membutuhkannya.

Pesan yang perlu dikirim ke penyedia Anda hari ini

Anda tidak perlu paham teknis untuk menanyakan hal-hal ini, dan tidak perlu menunggu rapat. Minta jawabannya secara tertulis:

  • Apakah jaringan kami berjalan di Cisco Catalyst SD-WAN Manager? Dan di mana sistem itu berjalan: di cloud Cisco, di lokasi kami, atau di pusat data Anda?
  • Rilis apa yang digunakan, dan kapan akan diperbarui ke rilis yang sudah diperbaiki, lengkap dengan tanggal dan jamnya?
  • Apakah antarmuka manajemen saat ini dapat dijangkau dari internet? Jika ya, apakah Anda sudah membatasi akses hingga pembaruan dilakukan?
  • Apakah Anda sudah memeriksa dua log yang disebut Cisco untuk indikator yang diterbitkan, dan menyimpan salinannya sebelum pembaruan? Apa yang Anda temukan?
  • Siapa yang pertama kali memberi tahu kami tentang peringatan ini: Anda, atau berita yang kami baca? Dan apa prosedur yang disepakati untuk memberi tahu kami di lain waktu?

Pertanyaan terakhir adalah yang paling penting. Jika Anda mengetahui peringatan ini dari sebuah artikel dan bukan dari penyedia Anda, masalahnya lebih besar daripada celah yang satu ini.

Pandangan Origami

Kami membangun sistem bisnis. Kami tidak menjual atau menjalankan perangkat jaringan. Namun setiap sistem yang kami bangun untuk klien dengan banyak cabang berjalan di atas jaringan yang tidak kami rancang: titik penjualan cabang mengirim data ke server, gudang memperbarui stok, faktur elektronik dikirim ke platform. Dan jawaban yang biasa atas pertanyaan siapa yang menambal jaringan adalah: penyedia mengurus semuanya. Itu jawaban yang menenangkan, dan itu bukan jawaban.

Bagi pemilik bisnis di Arab Saudi, kami membaca celah ini sebagai pengingat bahwa alih daya memindahkan pekerjaan, tetapi tidak memindahkan tanggung jawab. Layanan terkelola adalah pilihan yang tepat bagi banyak perusahaan, asalkan kontraknya memuat tiga hal yang terukur: tenggat yang dinyatakan untuk menerapkan pembaruan kritis, pemberitahuan tertulis atas setiap peringatan yang memengaruhi sistem Anda, dan laporan setelah setiap insiden yang menyebutkan apa yang diperiksa dan apa yang ditemukan. Klausul-klausul ini tidak merugikan penyedia yang baik sedikit pun, dan klausul ini menyingkap penyedia yang lemah sebelum sebuah kerentanan melakukannya.

Intinya

  • Jika Anda menjalankan Cisco Catalyst SD-WAN Manager di lokasi Anda atau di penyedia Anda, pembaruan ke rilis yang sudah diperbaiki adalah pekerjaan mendesak, bukan pekerjaan terjadwal, dan rilis yang lebih lama dari 20.9 harus pindah ke jalur yang sudah diperbaiki.
  • Hingga pembaruan dilakukan: blokir akses ke sistem dari internet dan tempatkan komponen kontrol di balik firewall, seperti dijelaskan dalam advisori.
  • Periksa kedua log dan simpan salinannya sebelum pembaruan, karena eksploitasi sudah dimulai sebelum perbaikan diterbitkan.
  • Jika jaringan Anda adalah layanan terkelola, kirim pertanyaan di atas hari ini, lalu tambahkan tenggat pembaruan kritis dan prosedur pemberitahuan ke dalam kontrak pada perpanjangan berikutnya.

Sumber