Celah Bernilai 10 dari 10 di Magento dan Adobe Commerce: Apa yang Sebenarnya Terjadi

Jawaban langsungnya dulu: pada 4 September 2026, penyerang mulai mengeksploitasi celah yang belum ditambal di Magento Open Source dan Adobe Commerce, yang tercatat sebagai CVE-2026-75650 dengan skor keparahan 10.0 — tertinggi yang mungkin. Celah ini memungkinkan perintah dijalankan di server toko tanpa login dan tanpa hak akses apa pun, dan Adobe merilis perbaikannya pada malam 7 September. Artinya ada tiga hari penuh ketika toko-toko terbuka tanpa perlindungan sama sekali. Justru karena itulah memasang patch saja tidak cukup: jika toko Anda berjalan di platform ini, asumsi yang aman adalah Anda mungkin sudah dibobol sebelum perbaikan tersedia, dan respons yang tepat adalah mencari tanda-tanda penyusupan serta mengganti kunci enkripsi dan setiap kredensial — bukan memasang pembaruan lalu melanjutkan hari seperti biasa.

Siapa tepatnya yang terdampak

Daftarnya luar biasa luas, karena mencakup rilis terbaru yang tersedia saat celah ditemukan:

  • Magento Open Source dan Adobe Commerce: versi 2.4.4 hingga 2.4.9, termasuk semua pembaruan patch hingga Agustus 2026.
  • Adobe Commerce B2B: versi 1.3.3 hingga 1.5.3, sampai pembaruan Agustus 2026.
  • Apa pun yang lebih lama dari 2.4.4: sudah tidak didukung, dan merupakan kategori paling berbahaya karena hotfix resmi tidak mencakupnya.

Terus terang saja: jika per 1 September Anda menjalankan Magento yang sudah diperbarui sepenuhnya, Anda tetap terbuka terhadap serangan. Ini bukan skenario kelalaian yang biasa kami peringatkan — ini zero-day sungguhan yang tidak bisa diantisipasi siapa pun.

Cara serangan bekerja tanpa kata sandi

Serangan ini berjalan dalam dua tahap dan menyalahgunakan kemampuan Magento untuk menyusun template email. Pada tahap pertama, penyerang mengirim permintaan yang direkayasa ke jalur respons pembayaran, dan seluruh isi permintaan itu ditulis ke sebuah file laporan error di server. Pada tahap kedua, permintaan ke endpoint GraphQL merujuk kembali ke file yang sudah diracuni itu, dan isinya dieksekusi saat email pengingat pembayaran gagal sedang disiapkan.

Bagian yang patut diperhatikan pemilik bisnis bukanlah detail teknisnya, melainkan apa yang diungkapkannya: jalur publik yang tampak sepenuhnya tidak berbahaya — respons payment gateway, endpoint kueri untuk etalase toko, email otomatis — digabungkan menjadi rute lengkap menuju server. Kerentanan serius jarang berupa satu pintu yang terbuka lebar; jauh lebih sering berupa rangkaian pintu kecil, yang masing-masing tampak sangat wajar jika dilihat sendiri.

Apa yang ditanam penyerang setelah masuk

Di sinilah perbedaan antara perusak iseng dan operasi terorganisir terlihat. Payload yang teramati bukan pesan ransomware yang mencolok, melainkan perangkat persistensi yang senyap:

  • Backdoor yang ditulis dalam Rust yang menyamar sebagai salah satu proses kernel sistem operasi, sehingga tidak menonjol bagi siapa pun yang sekadar melihat sekilas daftar proses.
  • Lalu lintas command-and-control yang disamarkan melalui port sinkronisasi waktu, sehingga aktivitasnya terlihat seperti penyetelan jam rutin di log jaringan.
  • Web shell PHP yang ditulis di dalam folder cache gambar produk — tempat yang biasanya tidak pernah diperiksa karena penuh file sementara.
  • Perangkat akses jarak jauh tambahan dari penyerang kedua dengan perangkat yang tidak berkaitan, yang berarti celah ini dieksploitasi oleh lebih dari satu kelompok pada saat yang sama.

Tujuan payload seperti ini di toko online yang dikenal adalah bertahan lama dan membaca data pesanan serta pembayaran saat data itu lewat — bukan menjatuhkan situs. Toko yang terinfeksi tetap beroperasi dengan sepenuhnya normal, dan itulah bagian yang meresahkan.

Mengapa memasang pembaruan saja tidak cukup

Karena jika penyerang sudah masuk sebelum 7 September, kini mereka memegang salinan kunci enkripsi dan kredensial yang tersimpan. Patch menutup pintu yang mereka lewati; patch tidak mengusir mereka dari dalam. Panduan Adobe sendiri tegas soal ini: terapkan perbaikannya lalu ganti kunci enkripsi, kata sandi panel admin, token API, kredensial payment gateway, kata sandi database, dan kunci akses server.

Patch menghentikan pendarahan. Mengganti kunci itulah yang mengeluarkan tamu tak diundang dari rumah.

Rencana tindakan praktis bagi pemilik toko

  • Pertama — pastikan perbaikannya benar-benar terpasang, bukan sekadar ada yang bilang sudah. Minta tim Anda bukti dari log patch di server itu sendiri, bukan pesan yang menenangkan.
  • Kedua — periksa jejak penyusupan: proses berjalan yang mencurigakan dengan nama yang meniru proses sistem, file PHP di dalam folder media dan gambar, serta file laporan error yang tidak biasa.
  • Ketiga — tinjau log email keluar. Lonjakan mendadak email pengingat pembayaran gagal adalah indikator langsung upaya eksploitasi, dan setiap kepala operasional bisa membacanya tanpa keahlian keamanan yang mendalam.
  • Keempat — ganti setiap kunci tanpa kecuali, terutama kredensial payment gateway. Ini memerlukan jendela pemeliharaan yang terencana, bukan keputusan dadakan di jam sibuk.
  • Kelima — jika versi Anda lebih lama dari 2.4.4, berhentilah menunggu patch resmi yang tidak akan datang. Tetapkan rencana upgrade dengan tanggal yang nyata, dan sementara itu letakkan toko di balik web application firewall.
  • Keenam — dokumentasikan apa yang Anda lakukan. Jika ternyata data pelanggan bocor, Anda akan memerlukan kronologi tentang apa yang Anda lakukan dan kapan.

Sisi regulasi di Arab Saudi: data pelanggan bukan sekadar urusan teknis

Toko online yang menyimpan nama, alamat, nomor ponsel, dan riwayat pesanan pelanggan sedang memproses data pribadi yang diatur oleh Undang-Undang Pelindungan Data Pribadi. Kebocoran tidak berhenti sebagai urusan internal antara toko dan penyedia hostingnya; kebocoran menimbulkan kewajiban terhadap otoritas yang berwenang dan terhadap pemilik data itu sendiri. Jadi pertanyaan yang semestinya diajukan pemilik toko hari ini bukan hanya "apakah server sudah di-patch", tetapi "dapatkah saya membuktikan bahwa data pelanggan saya tidak tersentuh".

Jika toko Anda berjalan di platform cloud terkelola seperti Salla atau Zid, Anda berada di luar cakupan celah yang satu ini, karena menambal platform bukan tanggung jawab Anda. Tetapi pelajaran yang sama berlaku untuk setiap ekstensi atau integrasi pihak ketiga yang Anda sambungkan ke toko: tanggung jawab menambal mengikuti siapa pun pemilik servernya.

Cara kami menangani insiden seperti ini di Origami

Prinsip yang kami pegang dalam membangun sistem klien adalah bahwa insiden keamanan bukan kemungkinan yang jauh, melainkan peristiwa yang tertunda. Dalam praktiknya itu berarti tiga hal: kredensial disimpan di luar basis kode dalam vault terpisah sehingga menggantinya cukup beberapa menit, bukan proyek seminggu; log operasional disimpan di luar server itu sendiri sehingga penyerang tidak bisa menghapus jejaknya; dan cadangan yang benar-benar sudah diuji dengan cara dipulihkan, bukan sekadar dijadwalkan.

Dan jika Anda menjalankan toko Magento tanpa tim teknis khusus, langkah yang tepat hari ini sederhana: minta penyedia hosting atau mitra teknis Anda membuat laporan tertulis yang hanya menjawab tiga pertanyaan — kapan tepatnya perbaikan dipasang, apa hasil pemindaian pembobolan, dan apakah kunci-kuncinya sudah diganti. Tiga pertanyaan itu mengungkap kesiapan mitra teknis lebih banyak daripada presentasi apa pun.

Sumber