SharePoint RCE masuk CISA KEV: checklist cepat untuk tim IT Indonesia

Update keamanan: CISA memasukkan CVE-2026-45659, celah remote code execution pada Microsoft SharePoint Server, ke katalog Known Exploited Vulnerabilities pada 1 Juli 2026. CISA menjelaskan celah ini terkait deserialization of untrusted data dan dapat memungkinkan attacker yang berwenang menjalankan kode lewat jaringan. Microsoft juga mencatat isu ini pada Security Update Guide untuk SharePoint Server.

Pembaruan: CVE-2026-50522 menambah alasan untuk memeriksa SharePoint on-premises

Microsoft mencatat CVE-2026-50522 pada SharePoint Server. NVD menjelaskannya sebagai deserialization of untrusted data yang dapat memungkinkan penyerang tidak sah menjalankan kode melalui jaringan. Bagi tim IT, fokusnya bukan mengejar detail exploit: konfirmasi apakah SharePoint on-premises berada dalam scope, terapkan update Microsoft melalui change window, dan review machine key, akun administratif, serta perubahan yang tidak dapat dijelaskan bila ada indikasi aktivitas berisiko.

Ini adalah pembaruan untuk advisory SharePoint yang sudah ada, bukan klaim bahwa semua tenant Microsoft 365 atau semua SharePoint telah disusupi. Microsoft 365 cloud service dan SharePoint Server on-premises perlu dibedakan saat menentukan scope tindakan.

Bagi tim IT, bagian pentingnya bukan hanya “ada CVE baru”. Pertanyaannya lebih praktis: apakah masih ada SharePoint Server yang terekspos, belum dipatch, atau punya akses terlalu luas ke sistem internal?

Artikel ini bisa dipakai sebagai checklist awal untuk menurunkan risiko tanpa membuat tim panik.

Kenapa SharePoint perlu diprioritaskan

SharePoint sering berada di posisi yang sensitif. Ia menyimpan dokumen, workflow internal, portal karyawan, dan kadang terhubung ke Active Directory, file server, atau aplikasi bisnis lain.

Jika celah RCE pada SharePoint berhasil dieksploitasi, risikonya bisa melebar ke beberapa area:

• akses tidak sah ke server aplikasi;
• pencurian dokumen internal;
• penyalahgunaan akun service;
• pergerakan lateral ke sistem lain;
• gangguan operasional jika server harus dimatikan mendadak.

Tidak semua organisasi masih memakai SharePoint Server on-premise. Namun banyak lingkungan Microsoft di Indonesia bersifat hybrid: ada Microsoft 365, ada server lama, ada portal internal, dan ada integrasi yang sudah berjalan bertahun-tahun. Di situlah inventaris menjadi penting.

Checklist 1: pastikan aset SharePoint benar-benar terdata

Mulai dari pertanyaan sederhana:

• Apakah organisasi masih menjalankan SharePoint Server on-premise?
• Versi apa yang digunakan?
• Apakah server tersebut bisa diakses dari internet?
• Apakah ada portal lama yang masih aktif tetapi jarang dipantau?
• Siapa owner teknis dan owner bisnis dari server tersebut?
• Apakah server masuk dalam proses patch rutin?

Jika jawabannya tidak jelas, treat itu sebagai risiko. Banyak insiden dimulai dari sistem yang “sepertinya sudah tidak dipakai”, tetapi masih menyala dan masih punya akses ke jaringan internal.

Checklist 2: cek status patch dan mitigasi

Karena laporan ini sudah masuk CISA KEV setelah eksploitasi aktif, patching perlu diprioritaskan.

Yang perlu dicek:

• apakah update Microsoft terkait sudah diterapkan;
• apakah server sudah reboot setelah patch jika diperlukan;
• apakah ada dependency aplikasi yang membuat patch tertunda;
• apakah ada pengecualian firewall atau reverse proxy yang membuka akses SharePoint;
• apakah tim punya catatan perubahan setelah patch.

Jika patch belum bisa diterapkan langsung, dokumentasikan alasannya dan pasang mitigasi sementara. Misalnya pembatasan akses, inspeksi traffic, monitoring log, atau isolasi server dari akses publik. Jangan biarkan statusnya menggantung tanpa owner.

Checklist 3: lihat ulang akses dan akun service

SharePoint jarang berdiri sendiri. Biasanya ada integrasi dengan direktori, database, file share, atau aplikasi internal. Karena itu, akun service perlu dicek.

• akun service yang dipakai SharePoint;
• hak akses akun tersebut;
• apakah password atau secret sudah lama tidak diganti;
• apakah akun memiliki hak admin yang tidak perlu;
• apakah login mencurigakan muncul di log;
• apakah akses admin memakai MFA.

Prinsipnya sederhana: jika server terkena, blast radius harus tetap dibatasi.

Checklist 4: cek indikator eksploitasi, bukan hanya patch

Patching penting, tetapi tidak cukup jika eksploitasi sudah terjadi sebelum patch dipasang.

Tim IT sebaiknya mengecek:

• log web server;
• log SharePoint;
• event log Windows;
• perubahan file yang tidak biasa;
• proses mencurigakan;
• koneksi keluar yang tidak dikenal;
• akun baru atau privilege escalation;
• alert dari EDR, firewall, atau SIEM.

Jika ada indikasi kompromi, jangan langsung hanya “bersihkan dan lanjut”. Simpan bukti log, batasi akses, dan lakukan review root cause. Untuk sistem yang menyimpan dokumen sensitif, asumsi awal sebaiknya konservatif.

Checklist 5: pastikan backup bisa dipakai saat dibutuhkan

Vulnerability management dan backup tidak boleh dipisahkan. Jika server penting terkena ransomware atau harus direbuild, pertanyaan berikut akan muncul cepat:

• kapan backup terakhir berhasil;
• apakah backup mencakup konfigurasi, database, dan file yang dibutuhkan;
• apakah restore pernah diuji;
• berapa lama estimasi pemulihan;
• apakah backup terisolasi dari akun domain biasa;
• apakah ada salinan immutable atau offline.

Backup yang belum pernah diuji sering memberi rasa aman palsu. Untuk sistem seperti SharePoint, restore test kecil lebih berguna daripada sekadar melihat status “backup success”. Lihat juga artikel kami tentang kenapa backup sukses belum cukup tanpa uji recovery dan layanan Backup & Disaster Recovery berbasis Veeam.

Checklist 6: siapkan komunikasi internal

Insiden patching biasanya gagal bukan karena tim tidak tahu risikonya, tetapi karena tidak ada keputusan yang jelas.

Minimal tentukan:

• siapa yang menyetujui maintenance window;
• siapa yang menghubungi user bisnis;
• siapa yang memegang akses admin;
• siapa yang memantau log setelah patch;
• kapan status dilaporkan ke manajemen.

Untuk organisasi dengan operasional padat, patch darurat tetap perlu dibuat rapi. Cepat bukan berarti asal jalan.

Prioritas 24-72 jam

Jika tim Anda memakai SharePoint Server, urutan kerja yang masuk akal:

1. Inventaris semua server SharePoint, termasuk yang lama.
2. Cek apakah ada yang terekspos ke internet.
3. Validasi status patch untuk CVE-2026-45659.
4. Batasi akses publik jika patch tertunda.
5. Review log untuk tanda eksploitasi.
6. Cek akun service dan hak akses admin.
7. Pastikan backup terakhir dapat direstore.
8. Dokumentasikan status dan owner setiap tindakan.

Checklist ini tidak menggantikan incident response. Namun cukup untuk membantu tim mengambil langkah pertama dengan lebih terarah.

Kapan perlu meminta bantuan eksternal

Pertimbangkan bantuan eksternal jika:

• server SharePoint terbuka ke internet;
• patch belum bisa diterapkan karena aplikasi lama;
• log menunjukkan aktivitas mencurigakan;
• tidak ada kepastian soal backup dan restore;
• tim internal tidak punya waktu untuk review mendalam;
• lingkungan Microsoft terhubung ke banyak sistem bisnis.

myBATICloud dapat membantu melakukan review singkat untuk lingkungan Microsoft, prioritas patch, akses, dan kesiapan backup/DR. Tujuannya bukan membuat proyek besar dari awal, tetapi membantu tim tahu mana yang harus ditutup dulu.

Sumber

• CISA Known Exploited Vulnerabilities Catalog - entri CVE-2026-45659, dateAdded 2026-07-01.
• Microsoft Security Update Guide: CVE-2026-45659.
• The Hacker News RSS item dan BleepingComputer RSS item sebagai sinyal editorial awal.

Decision table sebelum patch window ditutup

Pertanyaan yang sering muncul

Apakah Microsoft 365 cloud terkena dengan cara yang sama?

Jangan menyamakan tenant Microsoft 365 dengan SharePoint Server on-premises tanpa scope dari advisory yang sesuai. Mulai dari inventaris produk dan deployment yang benar-benar digunakan.

Apakah semua kredensial harus dirotasi setelah patch?

Rotasi perlu mengikuti evidence of exposure, prosedur incident response, dan panduan vendor. Patch tetap perlu, tetapi keputusan rotasi tidak boleh menjadi klaim universal tanpa pemeriksaan lingkungan.

Apakah backup saja cukup untuk menghadapi insiden SharePoint?

Backup membantu pemulihan data, tetapi kesiapan operasi juga memerlukan owner restore, dependency aplikasi, identity, dan bukti bahwa layanan dapat digunakan kembali.