Kiteworks meminta server dimatikan sembilan jam—serangan belum terbukti terjadi

Pada 25 September 2026, Kiteworks melalui peringatan resminya meminta pelanggan menyiapkan penghentian preventif sistem selama sembilan jam pada akhir pekan, sesuai zona waktu setempat. Perusahaan menyatakan belum menemukan indikasi bahwa sistemnya atau sistem pelanggan telah dikompromikan. Peringatan yang diterbitkan di San Mateo, California, itu menanggapi informasi dari otoritas intelijen federal tentang kemungkinan sebagian sistem pelanggan menjadi sasaran.

Dalam laporan TechCrunch, kepala keamanan Kiteworks Frank Balonis mengatakan seluruh kerentanan yang diketahui telah ditangani dalam rilis 9.5.1; FBI menolak berkomentar, sementara juru bicara CISA tidak memberikan komentar yang dapat dikutip. Administrator yang mengelola instalasi sendiri perlu menjalankan penghentian sesuai pemberitahuan untuk lingkungannya. Untuk sistem yang di-hosting Kiteworks, perusahaan menangani penghentian tersebut.

Apa yang memicu peringatan Kiteworks

Informasi ancaman yang diterima perusahaan menunjukkan seorang pelaku mungkin mencoba menargetkan sebagian sistem Kiteworks milik pelanggan. Itu menjelaskan mengapa penghentian direkomendasikan sebelum ada insiden yang terkonfirmasi: sistem yang tidak beroperasi selama jendela risiko tidak melayani transfer seperti biasanya. Konsekuensinya juga nyata bagi pengguna, karena pengiriman, penerimaan, atau proses otomatis yang bergantung pada layanan dapat tertunda.

Ada perbedaan antara informasi tentang kemungkinan serangan, kerentanan yang telah diketahui, dan bukti akses tanpa izin. Rilis terbaru menangani masalah yang diketahui perusahaan, tetapi klaim itu tidak memastikan bahwa setiap kemungkinan jalur serangan telah tertutup. Email pelanggan yang dikutip dalam pemberitaan menyinggung kekhawatiran terhadap celah yang belum diketahui. Kekhawatiran tersebut tidak membuktikan adanya celah zero-day tertentu atau bahwa celah semacam itu sudah dieksploitasi.

Penghentian preventif juga bukan hasil pemeriksaan keamanan. Server yang sengaja dimatikan tidak serta-merta bersih dari aktivitas sebelumnya, dan layanan yang kembali menyala belum dengan sendirinya membuktikan tidak ada akses mencurigakan. Karena itu, status yang dapat dinyatakan dari pengumuman publik adalah belum ada indikasi kompromi yang ditemukan perusahaan, bukan jaminan bahwa seluruh lingkungan pelanggan telah diperiksa dan dinyatakan aman.

Siapa yang harus menghentikan sistem

Pembagian tanggung jawab mengikuti siapa yang mengoperasikan instalasi, bukan semata-mata lokasi infrastrukturnya. Bagi administrator, pembedaan ini menentukan apakah mereka perlu mematikan sistem sendiri atau menunggu Kiteworks melakukannya.

• Instalasi di lokasi organisasi: pelanggan yang mengelola sistemnya sendiri bertanggung jawab menghentikannya dalam jendela yang diberitahukan. Tim TI perlu memperhitungkan transfer berkas dan integrasi yang akan terhenti selama layanan tidak tersedia.
• Instalasi di AWS atau Azure yang dikelola pelanggan: tanggung jawab penghentian tetap pada pelanggan. Menjalankan server di infrastruktur awan tidak menjadikannya sistem yang di-hosting dan dioperasikan oleh Kiteworks.
• Sistem yang di-hosting Kiteworks: perusahaan menangani penghentian atas nama pelanggan. Pelanggan dalam kelompok ini tidak diminta mematikan instalasi sendiri, meskipun pekerjaan yang bergantung pada transfer berkas tetap dapat tertunda.

Pemberitahuan melalui email memuat jam khusus bagi pelanggan serta rentang penghentian yang direkomendasikan. Pengumuman publik tidak memberikan satu jam mulai yang dapat langsung diterapkan pada semua instalasi di Indonesia. Untuk menentukan kapan layanan tertentu harus berhenti dan kembali berjalan, rujukan operasionalnya adalah pemberitahuan yang diterima organisasi tersebut; jika rinciannya tidak jelas, administrator dapat menghubungi dukungan teknis Kiteworks.

Mengapa durasinya disebut enam dan sembilan jam

The Record menggambarkan email pelanggan sebagai permintaan penghentian selama enam jam pada Sabtu, 26 September 2026. Angka itu berbeda dari jendela preventif sembilan jam dalam pernyataan publik Kiteworks. Kedua laporan membahas bentuk komunikasi yang berbeda—email pelanggan dan pengumuman umum—tetapi belum ada penjelasan publik yang memastikan bagaimana kedua rentang tersebut saling berkaitan.

Perbedaan itu penting untuk penjadwalan, bukan alasan untuk memilih angka yang tampak lebih mudah dijalankan. Jam dalam email untuk suatu lingkungan tidak boleh diganti dengan perkiraan dari pernyataan umum, terutama ketika administrator harus memberi tahu pengguna dan menghentikan proses transfer otomatis. Artikel ini juga tidak dapat memastikan bahwa setiap pelanggan menerima jam yang identik. Yang dapat dipastikan ialah rekomendasi umum perusahaan berdurasi sembilan jam, sedangkan laporan tentang email menyebut jendela enam jam.

Urutan pemeriksaan ketika layanan pulih

Sesudah jendela penghentian, administrator perlu membedakan pemulihan fungsi dari penilaian keamanan. Urutan berikut adalah pemeriksaan operasional yang relevan dengan gangguan transfer berkas ini, bukan daftar persyaratan pemulihan tambahan yang diumumkan Kiteworks. Rincian dalam pemberitahuan langsung tetap menentukan kapan instalasi yang dikelola pelanggan boleh dinyalakan kembali.

1. Periksa pemberitahuan terbaru untuk instalasi yang bersangkutan sebelum menyalakan layanan. Pastikan tidak ada perubahan jam penghentian, syarat pemulihan, atau instruksi pembaruan yang berlaku khusus untuk lingkungan tersebut.
2. Cocokkan versi yang terpasang dengan rilis yang direkomendasikan dan pastikan fungsi pengiriman serta penerimaan berkas kembali tersedia. Layanan yang dapat diakses belum tentu telah menyelesaikan pekerjaan yang tertunda selama penghentian.
3. Periksa antrean transfer, kegagalan pengiriman, dan integrasi otomatis terhadap catatan sebelum layanan berhenti. Berkas yang perlu dikirim ulang merupakan akibat operasional yang mungkin terjadi; kegagalan transfer saja bukan bukti serangan.
4. Tinjau catatan akses dan perubahan konfigurasi di sekitar periode peringatan. Aktivitas yang tidak dapat dijelaskan perlu ditangani melalui prosedur respons insiden organisasi, dengan catatan terkait tetap disimpan untuk pemeriksaan.

Untuk layanan yang di-hosting Kiteworks, pemeriksaan pelanggan berpusat pada pemberitahuan pemulihan serta nasib transfer dan integrasi yang bergantung pada layanan itu. Pelanggan tidak mengambil alih proses mematikan server milik penyedia, tetapi tetap perlu mengetahui apakah pekerjaan yang tertunda telah selesai.

Apa yang belum diungkap

Peringatan publik belum mengidentifikasi otoritas yang menyampaikan informasi ancaman, pelaku yang diduga, metode serangan, atau instalasi pelanggan yang secara khusus menjadi sasaran. Tidak ada rincian teknis dalam pengumuman tersebut yang memungkinkan pembaca menyimpulkan bahwa eksploitasi zero-day telah terjadi. Penolakan atau ketiadaan komentar dari lembaga pemerintah juga tidak mengonfirmasi maupun membantah keberhasilan serangan.

Status cerita ini tetap berupa rekomendasi penghentian preventif setelah peringatan ancaman yang dinilai kredibel. Hasil pemantauan setelah jendela penghentian dan penjelasan teknis tentang ancaman masih diperlukan untuk mengetahui apakah ada percobaan serangan, celah tertentu, atau dampak pada pelanggan. Sampai ada temuan semacam itu, keterlambatan layanan dan dugaan serangan harus dicatat sebagai hal yang berbeda.

Baca juga:

• Server Vite terbuka sedang dipindai—rahasia .env ikut menjadi sasaran
• Celah Cisco AsyncOS memberi akses root—patch belum menutup jejak serangan
• Dua celah SharePoint kini dirangkai—8.700 server terlihat di internet