Bagi banyak perusahaan ritel dan distributor di Indonesia, Magento Open Source dan Adobe Commerce masih menjadi tulang punggung kanal penjualan digital: katalog puluhan ribu SKU, integrasi ERP, sampai checkout yang terhubung ke payment gateway lokal. Karena itu, ketika sebuah kerentanan dengan skor CVSS 10.0 pada platform tersebut dieksploitasi di dunia nyata sebelum vendor punya perbaikan, dampaknya bukan sekadar isu teknis, tetapi risiko langsung terhadap data pelanggan dan kelangsungan transaksi.
Kerentanan itu bernama StyleSmuggler, kini terdaftar sebagai CVE-2026-75650. Ia memungkinkan penyerang yang tidak terautentikasi menjalankan kode arbitrer (remote code execution/RCE) di server toko. Artikel ini membedah cara kerjanya, indikator kompromi yang sudah dipublikasikan, serta urutan respons yang benar bagi tim di Indonesia, termasuk kewajiban hukum yang menyertainya.
Kronologi Singkat: Eksploitasi Mendahului Patch
Perusahaan keamanan e-commerce asal Belanda, Sansec, mengonfirmasi eksploitasi pertama pada 4 September 2026 dan mempublikasikan temuannya sehari berikutnya. Pada tanggal itu Adobe belum memiliki perbaikan resmi. Adobe baru menerbitkan advisory APSB26-146 beserta hotfix VULN-39341 pada 7 September 2026, dengan peringkat prioritas 1 — level tertinggi milik Adobe.
Detail yang paling perlu dicatat oleh tim operasional: korban pertama yang dikonfirmasi menjalankan Magento 2.4.6-p15 dengan patch keamanan Juli dan Agustus 2026 sudah terpasang. Artinya, disiplin patching yang baik pun tidak melindungi toko selama jendela zero-day berlangsung. Sansec juga berhasil mereproduksi rantai serangan lengkap pada Magento 2.4.7, 2.4.8, dan 2.4.9.
Versi terdampak menurut advisory Adobe mencakup Adobe Commerce 2.4.4–2.4.9 (termasuk rilis Agustus 2026 dan sebelumnya di setiap cabang), Adobe Commerce B2B 1.3.3–1.5.3, serta Magento Open Source 2.4.6–2.4.9.
Bagaimana StyleSmuggler Bekerja
Yang membuat StyleSmuggler menarik secara teknis adalah ia tidak memerlukan ekstensi jahat, akun administrator, atau kredensial apa pun. Penyerang justru meminjam mekanisme internal Magento sendiri. Rantai serangannya berjalan dalam dua tahap.
Tahap 1: Menyelundupkan kode ke data yang dikendalikan Magento
Penyerang mengirim permintaan yang dirancang khusus ke endpoint /graphql dengan parameter bergaya styles[...]. Nilai yang dikirim mengandung potongan kode PHP. Magento tidak langsung mengeksekusinya, tetapi menuliskannya ke data yang ia kelola sendiri — misalnya berkas laporan di var/report/ atau log di var/log/. Pada tahap ini payload masih berstatus "data tak berbahaya" di mata pemindai malware biasa, karena berada di dalam berkas log Magento yang sah.
Tahap 2: Memaksa Magento memproses data itu sebagai template
Tahap kedua memancing Magento merender email Payment Transaction Failed Reminder. Proses rendering itu melewati sistem template Magento dan pemindai kode dependency injection (DI) — komponen yang normalnya hanya dipakai saat setup:di:compile dijalankan dari CLI. Ketika data yang sudah "diselundupkan" ikut diproses di jalur ini, kode PHP tersebut dieksekusi.
Menurut analisis Disrex, StyleSmuggler "mengubah kode pemrosesan template dan dependency injection milik Magento sendiri menjadi rantai RCE tanpa autentikasi". Perlu dicatat: korban tidak perlu membuka email apa pun — kode berjalan saat Magento merender pesan tersebut.
Dari perspektif klasifikasi kelemahan, ini adalah kombinasi klasik antara improper neutralization pada input yang dipercaya sebagai data internal (CWE-94, Code Injection) dan asumsi batas kepercayaan yang salah: kode yang dirancang untuk konteks CLI ternyata dapat dijangkau dari konteks web.
Apa yang Ditanam Penyerang
Setidaknya dua aktor berbeda memanfaatkan pintu masuk yang sama.
Aktor pertama menanam backdoor Linux yang ditulis dalam Rust. Implan ini menyamarkan diri dengan nama proses yang tampak wajar. Varian awal muncul sebagai [kworker/u:8:0], lalu berkembang menjadi fc-cache dan chronyd. Yang lebih licik: lalu lintas command-and-control dibentuk agar menyerupai NTP di UDP port 123 — port yang di banyak organisasi diizinkan keluar tanpa pertanyaan. Persistensinya memakai entri cron seperti pemanggilan berkala ke ~/.cache/fontconfig/fc-cache atau /tmp/.chrony-<hex>/chronyd, meski varian 7 September juga teramati mampu bangkit kembali tanpa entri cron sama sekali.
Aktor kedua, dengan perkakas yang tidak berkaitan, menjatuhkan PHP web shell berukuran hanya 485 byte ke dalam cache gambar produk, dengan pola seperti pub/media/catalog/product/cache/ss_<hex>/sync_<hex>.php. Shell ini mengumpulkan detail server, menguji apakah pub/media dapat ditulisi, lalu mengeksfiltrasi datanya ke subdomain oast.site — infrastruktur yang biasa dipakai perkakas pengujian keamanan Interactsh, dan sering dipilih penyerang justru karena terlihat seperti aktivitas pemindaian rutin.
Satu poin arsitektural penting: implan dipasang di luar document root Magento, yaitu di direktori home pengguna atau /tmp. Pemindaian malware yang hanya menyisir folder pub/ atau public_html/ akan melaporkan toko "bersih" sementara implan tetap berjalan. Pada satu investigasi, proses jahat bahkan tidak membuka koneksi keluar yang mencurigakan — ia berkomunikasi melalui instans Redis milik toko itu sendiri.
Memeriksa Toko Anda: Urutan yang Benar
Ada tiga pekerjaan yang harus dipisahkan dan tidak boleh ditukar urutannya: (1) memeriksa apakah server sudah dikompromikan, (2) menutup jalur serangan, (3) membersihkan dan mengaudit. Kesalahan paling umum adalah langsung memblokir /graphql lalu menganggap masalah selesai. Memblokir jalur masuk mencegah serangan berikutnya; ia tidak menghapus implan yang sudah berjalan.
Langkah 1: Pemeriksaan read-only
Jalankan pemeriksaan yang tidak mengubah apa pun terlebih dahulu. Jangan me-reboot, jangan menghapus berkas, jangan menjalankan redeploy.
# Proses mencurigakan dan jalur eksekutabelnya
ps -eo user,pid,ppid,stat,comm,args | grep -iE '[k]worker|[f]c-cache|[c]hronyd'
for PID in $(pgrep -x fc-cache; pgrep -x chronyd); do
echo "=== PID $PID ==="; ps -o user,pid,ppid,args -p "$PID"
echo -n "EXE: "; readlink -f /proc/$PID/exe 2>/dev/null
done
# Persistensi cron (termasuk spool, karena sebagian varian menulis langsung)
crontab -l 2>/dev/null | grep -Ei 'gvfsd|fc-cache|chronyd|\.chrony-|\.cache/fontconfig'
sudo grep -RniE 'gvfsd|fc-cache|chronyd|\.chrony-|\.cache/fontconfig' /var/spool/cron* /etc/cron* 2>/dev/null
# Jejak tahap 1 di data Magento
grep -Ril 'x_trace_' var/report/ var/log/ 2>/dev/null
# Web shell di direktori media
find pub/media -type f -name '*.php' -print
# Jejak permintaan eksploitasi di access log
grep -acE 'styles(\[|%5B)|generatorClass|with_resolved|cdnflare' /path/to/access.log
Perlu kehati-hatian dalam menafsirkan hasil. Server Linux normal memang memiliki kernel worker, fc-cache, dan sering chronyd. Yang membedakan bukan nama proses, melainkan jalur eksekutabel: /usr/bin/fc-cache dan /usr/sbin/chronyd wajar, sedangkan /tmp/fc-cache atau ~/.cache/fontconfig/fc-cache tidak. Demikian pula, penanda X_TRACE_ di system.log tidak berarti berkas log itu malware — ia berarti jalur eksploitasi kemungkinan telah tersentuh, sehingga proses, cron, dan berkas yang dijatuhkan harus diperiksa. Sinyal non-teknis yang berguna: lonjakan email Payment Transaction Failed Reminder yang tidak wajar.
Langkah 2: Amankan barang bukti sebelum membersihkan
Ini bagian yang paling sering dilewati dan paling mahal akibatnya. Dalam kerangka forensik digital (lihat prinsip order of volatility pada NIST SP 800-86), data paling mudah hilang harus dikumpulkan lebih dahulu. Jika eksekutabel implan sudah dihapus dari disk, /proc/<pid>/exe mungkin satu-satunya salinan yang tersisa — dan itu hilang begitu proses dimatikan atau server di-reboot.
Q=~/incident-$(date +%Y%m%d-%H%M); mkdir -p "$Q"; chmod 700 "$Q"
ps -eo pid,ppid,user,lstart,rss,args > "$Q/processes.txt"
cp /proc/$PID/exe "$Q/implant.bin" 2>/dev/null && sha256sum "$Q/implant.bin"
crontab -l > "$Q/crontab.txt" 2>&1
(ss -tanp 2>/dev/null || netstat -tanp) > "$Q/connections.txt"
cp -a var/log "$Q/magento-log"; cp -a var/report "$Q/magento-report"
Langkah 3: Perbaikan dan penahanan
Tindakan definitifnya adalah memasang hotfix resmi Adobe (VULN-39341 melalui APSB26-146). Adobe mencatat bahwa hotfix ini baru diuji terhadap rilis Agustus 2026 dari tiap cabang produk; kompatibilitas dengan rilis lain belum dikonfirmasi, jadi ujilah di staging lebih dahulu. Sebagai penahanan sementara — atau jika jendela pemeliharaan belum tersedia — pemblokiran /graphql di lapisan tepi (WAF/CDN) atau web server jauh lebih aman dan mudah dibalik dibandingkan menonaktifkan modul Magento_GraphQl secara paksa, yang berisiko merusak graf dependensi modul.
# Nginx: hanya jika toko memang tidak memakai GraphQL
location ^~ /graphql { return 403; }
# Verifikasi lebih dulu apakah GraphQL dipakai (storefront headless/PWA bergantung padanya)
grep -c '"POST /graphql' /path/to/access.log
Setelah hotfix terpasang, Adobe merekomendasikan urutan: aktifkan maintenance mode, hentikan cron, rotasi seluruh secret, lalu flush cache, kembalikan cron, dan matikan maintenance mode. Rotasi harus mencakup kata sandi admin, token integrasi GraphQL, client secret OAuth, kredensial API payment gateway, kredensial database, kunci SSH, dan API key lain. Prinsipnya sederhana: rotasi dilakukan setelah penahanan berhasil — mengganti kredensial saat penyerang masih punya eksekusi di server hanya membocorkan kredensial baru.
Jika kompromi terkonfirmasi, hapus persistensi cron sebelum mematikan proses jahat (kalau tidak, cron akan menghidupkan salinan baru), lalu bersihkan berkas implan, web shell, dan konten log yang terinjeksi. Jangan berhenti di situ: audit authorized_keys, systemd user timer, auto_prepend_file pada konfigurasi PHP, akun di tabel admin_user, tabel integration dan oauth_token, serta core_config_data untuk skrip yang disuntikkan. Bila Redis dipakai untuk sesi, invalidasi database sesi tersebut dengan FLUSHDB pada nomor database yang tepat — bukan FLUSHALL.
Konteks Kepatuhan Indonesia
Sebuah toko Magento yang dikompromikan bukan hanya insiden IT. Server tersebut memproses nama, alamat, nomor telepon, riwayat pesanan, dan sering kali data pembayaran pelanggan — semuanya data pribadi menurut UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi. Ketika terjadi kegagalan pelindungan data pribadi, Pasal 46 UU PDP mewajibkan Pengendali Data Pribadi menyampaikan pemberitahuan tertulis kepada subjek data dan lembaga pengawas paling lambat 3x24 jam, memuat data yang terungkap, kapan dan bagaimana kejadiannya, serta upaya penanganan dan pemulihannya.
Konsekuensi praktisnya: tenggat 3x24 jam itu berjalan bersamaan dengan pekerjaan teknis di atas. Tanpa barang bukti yang terkumpul rapi pada Langkah 2, organisasi akan kesulitan menjawab pertanyaan paling dasar dari regulator — data apa yang benar-benar terakses. Bagi merchant yang menyimpan atau memproses data kartu, kewajiban notifikasi ke acquirer dan penilaian ulang kepatuhan PCI DSS juga berlaku. Selain itu, pelaporan insiden ke BSSN melalui kanal CSIRT sektoral membantu memperluas visibilitas ancaman secara nasional. Perlu ditegaskan pula bahwa memindai atau menguji eksploit terhadap sistem milik pihak lain tanpa izin tertulis berpotensi melanggar UU ITE — pemeriksaan seperti di atas hanya sah dilakukan pada infrastruktur yang menjadi tanggung jawab Anda atau dengan mandat kontraktual yang jelas.
Pelajaran yang Bisa Dibawa Pulang
StyleSmuggler menegaskan beberapa hal yang berlaku jauh melampaui Magento. Pertama, patching mutakhir adalah syarat perlu, bukan syarat cukup; organisasi tetap membutuhkan kemampuan deteksi di lapisan host dan jaringan untuk jendela zero-day. Kedua, kode yang dirancang untuk satu konteks kepercayaan (CLI) menjadi kerentanan kritis ketika dapat dijangkau dari konteks lain (web) — pola ini layak dijadikan pertanyaan rutin dalam threat modeling aplikasi. Ketiga, penyamaran C2 sebagai NTP di UDP/123 mengingatkan bahwa kebijakan egress yang longgar adalah aset bagi penyerang; kendali keluar berbasis daftar-izin dan pemantauan siapa pemilik proses di balik koneksi lebih berguna daripada mempercayai nama proses. Keempat, kompromi seperti ini harus diperlakukan sebagai kompromi terhadap akun sistem Unix, bukan sekadar satu berkas PHP jahat di dalam instalasi Magento.
Bagi tim yang mengelola storefront Magento di Indonesia, prioritas hari ini jelas: verifikasi versi, jalankan pemeriksaan read-only, pasang hotfix VULN-39341, rotasi secret, dan pastikan proses pelaporan internal siap memenuhi tenggat 3x24 jam apabila indikator kompromi ditemukan.
Siberindo membantu organisasi melakukan pemeriksaan kompromi, forensik digital, dan penguatan infrastruktur aplikasi web. Untuk diskusi lebih lanjut, hubungi tim kami melalui siberindo.io.
