Insiden ini pertama kali terungkap melalui artikel basis pengetahuan ServiceNow yang kini disembunyikan di balik layar login, tetapi telah beredar luas di forum Reddit. Dalam dokumen tersebut, ServiceNow menyatakan bahwa bug memungkinkan pengguna yang tidak terautentikasi — alias tanpa kredensial login — untuk “mendapatkan akses lebih besar” ke data yang dihosting di platform mereka daripada yang seharusnya.
Artinya, celah ini tidak memerlukan teknik peretasan rumit. Siapa pun yang mengetahui alamat instance ServiceNow milik suatu perusahaan bisa langsung mengakses database internal yang tersimpan di cloud.
ServiceNow bukanlah platform sembarangan. Raksasa cloud computing ini digunakan oleh ribuan perusahaan besar untuk membangun alur kerja otomatis yang terhubung ke berbagai aplikasi dan database — mulai dari sistem SDM, IT, hingga layanan pelanggan.
Data yang biasanya mengalir di platform ini sangat sensitif: tiket dukungan teknis yang bisa berisi kata sandi, kunci API, hingga kredensial login sistem internal. Karena itu, ServiceNow selama ini menjadi target bernilai tinggi bagi peretas dan kelompok kriminal siber.
Seorang pengguna Reddit yang mengaku bukan berasal dari Australia — negara yang disebut ServiceNow sebagai lokasi terdampak — mengklaim menemukan bukti akses tidak sah ke instance ServiceNow perusahaannya. Para pembela jaringan juga telah membagikan alamat IP 51.159.98.241 sebagai indikator kompromi yang patut diwaspadai jika muncul di log server.
Hingga berita ini ditulis, ServiceNow belum merespons permintaan konfirmasi dari TechCrunch. Perusahaan juga belum menjawab pertanyaan mendasar: berapa banyak pelanggan yang terdampak, sejak kapan bug ini aktif, dan apakah ada data yang benar-benar diambil atau hanya diakses.
Yang lebih mengkhawatirkan, karena insiden ini murni akibat celah perangkat lunak — bukan kesalahan konfigurasi dari sisi pelanggan — para korban tidak memiliki cara untuk melindungi diri sebelum ServiceNow menambal bug tersebut. Ini berbeda dengan kasus kebocoran cloud pada umumnya yang sering kali disebabkan oleh pengaturan bucket penyimpanan yang salah.
Bagi perusahaan di Indonesia yang menggunakan ServiceNow — atau platform SaaS serupa — insiden ini menjadi pengingat mahal. Meskipun data dikelola oleh vendor cloud raksasa, tanggung jawab keamanan tetap berada di pundak pengguna.
Langkah pertama yang bisa dilakukan adalah memeriksa log akses untuk mencari alamat IP mencurigakan, khususnya 51.159.98.241. Kedua, segera rotasi semua kredensial yang mungkin tersimpan di instance ServiceNow — termasuk kata sandi, token API, dan sertifikat. Ketiga, aktifkan autentikasi multi-faktor di semua titik akses yang memungkinkan.
ServiceNow berjanji telah menambal celah tersebut pada 5 Juni, tetapi tanpa transparansi soal durasi paparan dan data yang terakses, pelanggan tidak bisa bernapas lega. Di dunia keamanan siber, bug yang sudah ditambal bukan berarti risiko sudah hilang — data yang bocor, sekali tersebar, tidak bisa ditarik kembali.