Tim yang menjalankan Metabase secara mandiri perlu memeriksa versinya sekarang, bukan menunggu jadwal patch rutin berikutnya. Metabase mengonfirmasi adanya kerentanan zero-day yang telah dipakai untuk menyerang Metabase Cloud. Pada instalasi self-hosted yang rentan, penyerang tanpa autentikasi dapat menyuntikkan SQL ke database aplikasi Metabase dan kemudian memperoleh akses administrator.
Risikonya tidak berhenti pada satu dashboard. Dengan akses administrator, pelaku dapat mengubah konfigurasi aplikasi, melihat atau mengambil kredensial yang tersimpan untuk database terhubung, membaca data yang dapat diakses melalui koneksi tersebut, serta mengekspor data. Dampak nyata bergantung pada cara Metabase dipasang, jaringan yang dapat dijangkaunya, dan hak akses setiap konektor data.
Apa yang sudah dikonfirmasi vendor
Dalam pembaruan keamanan resminya, Metabase menyatakan bahwa serangan memanfaatkan kerentanan yang sebelumnya belum diketahui pada versi 1.58 dan yang lebih baru. Metabase Cloud sudah diperbarui. Peringatan ini terutama penting bagi organisasi yang mengelola instance Metabase sendiri.
GitHub Security Advisory untuk proyek Metabase menilai isu ini Critical dengan skor CVSS 10.0. Advisory tersebut menjelaskan bahwa celahnya adalah SQL injection melalui endpoint tanpa autentikasi yang dapat berujung pada akses administrator. Advisory tidak mencantumkan CVE ID. Karena itu, tim sebaiknya menggunakan versi produk dan rilis perbaikan sebagai penanda utama saat melakukan inventarisasi, bukan hanya mencari nomor CVE.
Versi yang perlu diperiksa
| Rangkaian versi terdampak | Rilis minimum yang aman |
|---|---|
| 0.58.0 sampai sebelum 0.58.23 | 0.58.24 |
| 0.59.0 sampai sebelum 0.59.20 | 0.59.21 |
| 0.60.0 sampai sebelum 0.60.16 | 0.60.17 |
| 0.61.0 sampai sebelum 0.61.10 | 0.61.11 |
| 0.62.0 sampai sebelum 0.62.8 | 0.62.9 |
| 0.63.0 sampai sebelum 0.63.3 | 0.63.5 |
Metabase menyarankan upgrade ke point release terbaru dari jalur versi yang sedang digunakan. Jika organisasi menjalankan versi lebih lama dari 58, pernyataan vendor menyebut versi tersebut tidak terdampak oleh isu ini. Tetap catat hasil pemeriksaan dan tinjau advisori keamanan lain yang mungkin berlaku untuk versi lama.
Prioritas 30 menit pertama
- Temukan seluruh instance. Periksa deployment Docker, Kubernetes, VM, lingkungan pengujian, dan instance yang dibuat oleh tim produk atau analitik secara mandiri. Catat versi, URL, pemilik layanan, dan database yang terhubung.
- Nilai paparan endpoint. Fokus pada apakah endpoint
/api/session/reset_passworddapat diakses publik. Vendor menyarankan endpoint ini diblokir sementara bila patch belum dapat dilakukan. - Jadwalkan upgrade. Gunakan rilis minimum aman pada tabel di atas atau point release terbaru yang kompatibel. Siapkan backup database aplikasi dan prosedur rollback sebelum mengubah produksi.
- Batasi jalur masuk. Jika instance hanya untuk pengguna internal, batasi akses melalui VPN, allowlist, reverse proxy, atau kontrol identitas yang sesuai. Pembatasan ini bukan pengganti patch, tetapi dapat mengurangi permukaan serangan saat perbaikan berjalan.
- Libatkan pemilik data. Beri tahu pemilik warehouse, database operasional, dan sistem analitik yang kredensialnya tersimpan di Metabase. Mereka perlu siap melakukan rotasi bila ada indikasi akses tidak sah.
Setelah patch: tentukan apakah respons insiden diperlukan
Upgrade menghentikan kerentanan pada versi yang diperbaiki, tetapi tidak otomatis membatalkan akses yang mungkin sudah diperoleh sebelumnya. Metabase menyarankan beberapa langkah pasca-patch jika endpoint reset password terekspos ke internet: cabut sesi aktif, tinjau API key, periksa akun administrator, rotasi kredensial database yang terhubung, serta telaah log warehouse dan riwayat aktivitas Metabase.
Vendor juga menjelaskan pola log yang patut diperhatikan: panggilan POST /api/session/reset_password dengan respons 400, diikuti GET /api/user/current dengan respons 200. Pola itu bukan bukti tunggal untuk menyimpulkan insiden, tetapi cukup kuat untuk menjadi alasan eskalasi ke tim keamanan dan pemeriksaan konteks log yang lebih luas.
| Temuan | Tindakan yang proporsional |
|---|---|
| Instance rentan, tidak terpapar publik, tanpa pola log mencurigakan | Patch secepatnya, dokumentasikan versi dan hasil validasi, lalu tinjau kontrol akses. |
| Instance rentan dengan endpoint publik | Blokir endpoint sementara jika patch belum selesai, percepat patch, dan lakukan review sesi, API key, serta akun admin. |
| Pola log sesuai indikator vendor atau perubahan akun/API key yang tidak dikenal | Aktifkan prosedur respons insiden, amankan bukti log, cabut sesi, rotasi kredensial relevan, dan nilai cakupan data yang dapat diakses. |
Jangan lupa konektor data
Metabase sering berada di titik yang dekat dengan data bisnis: data warehouse, database aplikasi, atau sumber data pelaporan lainnya. Saat mengaudit dampak, jangan berasumsi bahwa akses Metabase sama dengan akses penuh ke seluruh perusahaan. Tinjau kredensial yang benar-benar disimpan di instance tersebut, role database yang digunakan, dan data yang dapat dibaca oleh role itu.
Pendekatan ini membantu tim membedakan dua pekerjaan: memperbaiki aplikasi Metabase dan mengurangi risiko pada jalur data di belakangnya. Prinsip least privilege, segmentasi jaringan, serta kredensial terpisah untuk layanan analitik mengurangi dampak jika satu aplikasi administratif disusupi.
Checklist untuk pemilik layanan
- Versi Metabase setiap instance telah dicatat.
- Instance yang masuk rentang terdampak telah di-upgrade ke rilis aman atau lebih baru.
- Akses publik ke endpoint dan reverse proxy telah ditinjau.
- Backup dan rollback untuk upgrade telah tersedia.
- Sesi aktif, API key, dan administrator telah diperiksa setelah patch bila instance terpapar publik.
- Kredensial database terhubung telah dinilai untuk rotasi berdasarkan hasil investigasi.
- Log ingress, activity, dan query telah disimpan dan ditinjau bila ada indikator yang relevan.
FAQ
Apakah Metabase Cloud perlu ditangani manual?
Menurut pembaruan keamanan Metabase, instance Metabase Cloud sudah diperbarui dan dipatch. Tim pelanggan tetap dapat mengonfirmasi status lingkungan serta meninjau konfigurasi akses mereka sendiri bila diperlukan.
Apakah semua versi Metabase terdampak?
Tidak. Advisory resmi mencantumkan rentang terdampak pada lini 0.58 hingga 0.63. Periksa versi tepat yang berjalan, karena setiap lini memiliki point release minimum yang aman.
Apakah memblokir endpoint cukup?
Tidak. Pemblokiran endpoint adalah langkah sementara ketika patch belum dapat diterapkan. Perbaikan utama tetap upgrade ke rilis yang sudah ditambal, disertai pemeriksaan akses dan log sesuai tingkat paparan.
Haruskah semua kredensial database langsung dirotasi?
Rotasi perlu diprioritaskan bila instance terpapar dan ada tanda kompromi atau jika hasil investigasi tidak dapat menyingkirkan akses tidak sah. Keputusan sebaiknya mempertimbangkan konektor yang tersimpan, dampak operasional, dan prosedur respons insiden organisasi.
Butuh second opinion untuk lingkungan analitik Anda?
Jika tim Anda perlu memetakan instance Metabase, mengecek paparan, atau menyusun urutan patch dan rotasi kredensial yang aman, myBATI dapat membantu melalui asesmen keamanan terarah. Fokusnya adalah memperjelas prioritas dan bukti yang diperlukan, bukan mengganggu operasi pelaporan saat insiden masih ditangani.