274 server Zimbra dibobol meski perbaikan sudah tersedia lima minggu

Per 26 Agustus 2026, sedikitnya 274 instans Zimbra yang dapat dijangkau dari internet telah dikompromikan melalui CVE-2026-73570. Help Net Security mencatat jumlah yang ditemukan Shadowserver naik dari 155 instans pada 20 Agustus, sementara pelaku di balik serangan tersebut belum diketahui.

Per 26 Agustus, perbaikan untuk celah itu sebenarnya telah tersedia selama lebih dari lima minggu. Catatan rilis resmi Zimbra menunjukkan ZCS 10.1.20 dirilis pada 20 Juli 2026 dan memperbaiki injeksi perintah pada komponen pemantauan SNMP ketika notifikasi SNMP diaktifkan. Server yang baru ditambal tetap perlu diperiksa karena pembaruan menutup celah, tetapi tidak menghapus akses atau persistensi yang mungkin dibuat sebelumnya.

Konfigurasi menentukan paparan sebenarnya

CVE-2026-73570 tidak dapat dieksploitasi pada setiap instalasi Zimbra. Kondisi yang perlu diperiksa bersama adalah versi ZCS sebelum 10.1.20, keberadaan paket opsional zimbra-snmp, dan notifikasi SNMP yang aktif. Karena paket itu opsional, admin tidak boleh menyimpulkan bahwa paket tersebut pasti tidak ada tanpa memeriksa setiap host.

Inventaris perlu mencakup seluruh node dalam lingkungan Zimbra, termasuk MTA, node pemantauan, replika, dan mesin lama yang masih menerima lalu lintas. Paket dan pengaturan dapat berbeda antarnode, terutama pada lingkungan yang telah lama beroperasi atau berpindah pengelola. Catat versi, status paket, konfigurasi notifikasi, layanan yang aktif, dan paparan internet per host.

Prioritas triase tertinggi adalah host sebelum 10.1.20 yang memasang zimbra-snmp, mengaktifkan notifikasi SNMP, dan dapat menerima lalu lintas dari internet. Instalasi lama yang tidak memenuhi seluruh kondisi eksploitasi belum tentu dapat diserang melalui celah ini, tetapi tetap perlu diperbarui karena masih memakai rilis yang tidak memuat perbaikan.

Angka 8.200 tidak sama dengan jumlah korban

Sekitar 8.200 instans masih memakai versi yang belum diperbarui. Namun, laporan IT Pro pada 26 Agustus menegaskan bahwa tidak semua instans tersebut dapat dieksploitasi karena serangan bergantung pada konfigurasi SNMP nondefault. Angka 8.200 menggambarkan populasi yang belum ditambal, sedangkan 274 merujuk pada instans yang telah ditemukan dalam keadaan terkompromi.

Perbedaan antara versi rentan, konfigurasi dapat dieksploitasi, dan kompromi terdeteksi penting untuk menentukan respons. Versi lama menempatkan host dalam cakupan pemeriksaan; paket dan konfigurasi menentukan apakah jalur eksploitasi tersedia; sementara log atau artefak lain diperlukan untuk menilai apakah eksekusi perintah benar-benar terjadi.

Zimbra menangani surat elektronik, kontak, kalender, akun, dan fungsi administratif. Karena itu, dugaan eksekusi perintah sebagai pengguna zimbra perlu diperlakukan sebagai insiden pada sebuah server komunikasi, bukan sekadar masalah satu paket. Pemeriksaan cakupan harus mempertimbangkan data, kredensial, dan sistem lain yang dapat dijangkau dari host tersebut tanpa menganggap semuanya otomatis telah diakses.

Pemeriksaan kompromi dilakukan sebelum pembersihan

Pembaruan ke versi aman tidak menjawab apakah server pernah dimasuki sebelum ditambal. Pada host yang memenuhi kondisi eksploitasi atau menunjukkan aktivitas mencurigakan, langkah awal yang lebih aman adalah membatasi akses dari internet secara terkendali dan mempertahankan bukti sebelum menghapus file, mematikan proses, atau memasang ulang sistem.

Triase dapat mencakup log Zimbra dan sistem operasi, proses yang berjalan sebagai pengguna zimbra, koneksi jaringan, tugas terjadwal, perubahan akun administratif, serta file baru atau termodifikasi di direktori aplikasi dan lokasi sementara. Temuan perlu dibandingkan dengan pola normal lingkungan sendiri dan garis waktu pemeliharaan yang sah. Perintah asing, proses anak yang tidak lazim, koneksi keluar yang tidak dikenal, atau perubahan akun merupakan alasan untuk memperluas penyelidikan, bukan bukti tunggal yang selalu memastikan eksploitasi.

Jika tanda eksekusi perintah ditemukan, pemeriksaan harus diperluas ke node Zimbra lain, akun yang dapat digunakan dari server, dan sistem yang berkomunikasi dengannya. Waktu sistem dan masa retensi log juga perlu diperhitungkan agar aktivitas lama tidak terlewat atau perubahan administratif biasa keliru dinilai sebagai serangan.

Urutan respons untuk administrator Zimbra

Urutan respons berikut memisahkan penentuan paparan, preservasi bukti, pemulihan akses, dan penambalan agar tindakan awal tidak menghapus jejak penting:

1. Periksa versi ZCS, paket zimbra-snmp, status notifikasi SNMP, layanan terkait, dan paparan internet pada setiap node.
2. Batasi atau isolasi host yang memenuhi kondisi eksploitasi atau menunjukkan aktivitas mencurigakan. Pertahankan layanan penting hanya jika dapat dilakukan tanpa membuka kembali jalur serangan.
3. Simpan log, daftar proses dan koneksi, tugas terjadwal, metadata file, konfigurasi, serta catatan perubahan akun sebelum melakukan pembersihan.
4. Telusuri artefak kompromi dan tentukan apakah aktivitas mencapai kotak surat, akun administratif, node lain, atau layanan yang mempercayai server tersebut.
5. Rotasi kata sandi, token, kunci, dan rahasia yang mungkin dapat diakses dari host terdampak. Lakukan perubahan dari perangkat administrasi yang diyakini bersih.
6. Perbarui seluruh node ke ZCS 10.1.20 atau rilis lebih baru yang memuat perbaikan, lalu verifikasi tingkat paket yang benar-benar terpasang.
7. Periksa kembali akun, koneksi keluar, konfigurasi, dan kemungkinan persistensi sebelum akses internet dan layanan penuh dipulihkan.

Jika kemampuan forensik internal terbatas, organisasi perlu menjaga bukti dan melibatkan tim respons insiden sebelum menjalankan pembersihan yang tidak dapat dibatalkan. Detail eksploitasi operasional tidak diperlukan untuk menentukan paparan, mengisolasi host, atau memulai pemeriksaan.

Yang telah diketahui adalah adanya eksploitasi aktif, sedikitnya 274 instans terkompromi, perbaikan dalam ZCS 10.1.20, dan ribuan instalasi yang masih memakai versi lama. Identitas serta tujuan pelaku belum dipastikan. Bagi admin Zimbra mandiri, insiden belum selesai hanya karena versi sudah diperbarui: penutupan baru layak dipertimbangkan setelah bukti ditinjau, kredensial berisiko diganti, dan persistensi tidak ditemukan pada server maupun sistem terkait.