Magento ditambal tiga hari terlambat—periksa jejak StyleSmuggler setelah patch

FAQ StyleSmuggler dari Tenable mencatat eksploitasi aktif CVE-2026-75650 mulai 4 September 2026, sedangkan hotfix VULN-39341 baru tersedia pada 7 September 2026—tiga hari kemudian—dengan beberapa toko menjadi korban dalam kampanye berbeda.

Konsekuensinya langsung bagi pengelola Adobe Commerce dan Magento Open Source: pemasangan hotfix menutup jalur kerentanan, tetapi tidak membuktikan bahwa host aman selama jendela sebelum perbaikan. Pemeriksaan harus mengikuti urutan versi, waktu paparan, persistensi, lalu indikator kompromi pada setiap mesin yang melayani toko.

Cocokkan versi sebelum menilai status patch

Buletin Adobe APSB26-146 tertanggal 7 September 2026 menetapkan CVE-2026-75650 sebagai kerentanan kritis tanpa autentikasi dengan dampak eksekusi kode arbitrer dan skor CVSS 10,0; daftar terdampaknya mencakup cabang Adobe Commerce 2.4.4 hingga 2.4.9, Magento Open Source 2.4.6 hingga 2.4.9, serta versi Adobe Commerce B2B yang tercantum dari 1.3.3 sampai 1.5.3, pada paket 2026-aug atau yang lebih lama sesuai cabangnya.

Nomor versi produk saja belum cukup. Inventaris perlu menyertakan paket pembaruan keamanan yang terpasang dan bukti bahwa hotfix VULN-39341 benar-benar diterapkan, bukan sekadar diunduh atau dimasukkan ke antrean deployment.

Pada lingkungan dengan beberapa node, pemeriksaan harus mencakup seluruh mesin aplikasi, host siaga, dan citra yang dapat dipakai untuk mengganti server aktif. Satu node yang telah ditambal tidak mewakili node lain, sementara citra lama dapat mengembalikan kode rentan ke lingkungan produksi setelah penggantian mesin.

Bangun garis waktu paparan untuk setiap host

Sesudah versi dan hotfix dipastikan, pertanyaannya berubah dari “apakah celah sudah ditutup” menjadi “apakah mesin sempat menerima aktivitas berbahaya”. Catat waktu mulai dan berakhirnya setiap host, periode ketika host menerima trafik, serta waktu pemasangan hotfix yang terverifikasi.

1. Petakan semua node yang melayani permintaan sebelum hotfix terpasang.
2. Selaraskan waktu pada log aplikasi, sistem operasi, proxy, orkestrasi, dan jaringan.
3. Cari perubahan berkas, proses baru, tugas terjadwal, serta koneksi keluar yang muncul dalam jendela paparan.
4. Simpan log dan artefak terkait sebelum melakukan pembersihan jika ditemukan indikator mencurigakan.

Urutan ini penting karena status patch saat ini tidak menjawab kondisi server sebelumnya. Host yang sudah tidak aktif pun tetap masuk cakupan apabila sempat melayani trafik, memiliki penyimpanan persisten, atau menjadi sumber citra dan volume yang kemudian dipakai mesin lain.

Log sebelum jendela paparan berguna sebagai pembanding. Sebuah proses atau koneksi tidak otomatis berbahaya hanya karena namanya tidak dikenal; perubahan waktu kemunculan, lokasi biner, proses induk, pemilik berkas, argumen, dan tujuan jaringan memberi konteks yang lebih kuat.

Cari proses tersamar, cron, dan PHP di cache produk

Penyelidikan teknis Sansec tentang StyleSmuggler mendokumentasikan implant yang tampil sebagai proses [kworker/u:8:0], fc-cache, atau chronyd, biner pada direktori tersembunyi dan /tmp, persistensi melalui spool cron, serta web shell PHP dari pelaku lain di cache gambar produk.

Nama fc-cache dan chronyd juga digunakan oleh perangkat lunak Linux yang sah, sehingga kecocokan nama tidak boleh diperlakukan sebagai putusan tunggal. Periksa jalur executable, hash, waktu pembuatan, proses induk, pengguna yang menjalankannya, dan koneksi jaringan; nama yang tampak normal tetapi berjalan dari direktori sementara atau tersembunyi memerlukan penyelidikan lebih lanjut.

Spool cron perlu diperiksa secara langsung, bukan hanya melalui daftar tugas milik pengguna. Pada aktivitas yang diamati, entri dapat ditulis ke spool tanpa alur perubahan biasa, dan varian lain mampu meluncurkan kembali dirinya meskipun entri cron tidak ditemukan. Karena itu, crontab kosong juga bukan bukti bahwa host bersih.

Direktori media Magento memerlukan pemeriksaan terpisah untuk berkas PHP yang tidak semestinya berada dalam cache produk. Temuan web shell pada kampanye lain menunjukkan bahwa menghentikan satu proses latar belakang tidak otomatis menghapus jalur akses lain. Sebaliknya, ketiadaan satu nama proses atau satu jalur berkas tidak menyingkirkan kompromi karena muatan dapat berubah atau sudah dihapus.

Lonjakan surel Payment Transaction Failed Reminder dapat membantu mempersempit waktu pencarian karena aktivitas tersebut berkaitan dengan perenderan templat surel transaksi. Namun, notifikasi itu bukan indikator tunggal: transaksi sah yang gagal dapat menghasilkan surel serupa, sedangkan eksekusi berbahaya tidak bergantung pada keberhasilan pengiriman pesan.

Temuan indikator mengubah penanganan menjadi insiden

Jika pemeriksaan menemukan proses, biner, persistensi, web shell, atau trafik yang sesuai dengan konteks serangan, pemasangan hotfix bukan lagi akhir pekerjaan. Host perlu diisolasi, artefak dipertahankan, hubungan akses ke sistem lain dipetakan, dan integritas mesin dinilai sebelum layanan dipulihkan.

Kredensial yang dapat dijangkau dari host terdampak juga harus dianggap berisiko sampai cakupan akses diketahui. Ini dapat mencakup akun administrator, token integrasi, rahasia OAuth, kredensial basis data dan gateway pembayaran, serta kunci deployment. Rotasi sebaiknya dilakukan dari lingkungan yang dipercaya bersih setelah bukti yang diperlukan diamankan.

Hingga kini, hotfix resmi telah tersedia dan eksploitasi sebelum perbaikan sudah terkonfirmasi, tetapi atribusi publik kepada kelompok tertentu belum tersedia. Lebih dari satu pola pascaeksploitasi juga telah ditemukan. Dengan demikian, keputusan bahwa toko bersih harus bertumpu pada kecocokan versi, bukti waktu deployment, pemeriksaan indikator, dan penilaian host—bukan pada status patch saja.

Baca juga:

• Patch pertama PaperCut bisa dilewati—admin harus memasang Release 2
• CVE-2026-8452 aktif dieksploitasi, tenggat patch NetScaler sangat sempit
• Laba naik, kas tertinggal: tiga laporan yang wajib dibaca investor teknologi