CVE-2026-48356 PolyShell: Celah Magento Skor 9.3 Sudah Dipakai Menyerang, Cara Cek dan Patch Hari Ini

Jawaban langsung: CVE-2026-48356, yang Sansec beri nama PolyShell, adalah celah unggah file di REST APIAPIPintu resmi yang dipakai 2 sistem untuk saling mengirim data, tanpa orang menyalin data secara manual.Buka glosarium Magento Open Source dan Adobe Commerce. Skornya CVSS 9.3, dan CISA memasukkannya ke katalog KEV pada 27 Oktober 2026. Toko 2.4.x tanpa isolated patch Juli 2026 masih rentan. Hari ini, cek versi, cek folder unggahan, pasang patch, lalu cari tanda serangan.

Penyerang sudah memakai celah ini sejak 19 Maret 2026. Menurut laporan Sansec, pada 30 Maret 79,5% toko yang Sansec lindungi menjadi target. Penyerang memasang backdoor dan script pencuri data kartu di toko yang berhasil mereka masuki.

Kondisi utama: Adobe tidak menerbitkan versi Composer baru untuk patch ini. Patch datang sebagai berkas isolated patch bulanan di atas versi -p terakhir. Jadi nomor versi 2.4.8-p5 saja belum aman. Batas: Artikel ini tidak memuat isi request, payload, atau urutan serangan.

Kami membaca catatan CVE Adobe, NVD, bulletin APSB26-73, APSB26-153, KB isolated patch Oktober 2026, KB hotfix APSB26-146, laporan Sansec, dan CISA KEV pada 31 Oktober 2026, pukul 06.30 sampai 07.40 WIB. Skrip di langkah 1, 2, 4, dan 5 kami jalankan di container podman dengan image resmi php, nginx, debian, dan mariadb pada tanggal yang sama. Uji versi memakai composer.lock asli dari 4 versi Magento Open Source. Server uji tidak memuat data pelanggan.

Masalah: celah ini dipakai menyerang 7 bulan sebelum masuk KEV

Serangan pertama terjadi pada 19 Maret 2026, tetapi patch untuk cabang 2.4.8 dan lebih lama baru datang pada 14 Juli 2026.

Menurut laporan Sansec, Adobe memperbaiki kode ini di cabang pra-rilis 2.4.9 pada Oktober 2025. Sansec memberi peringatan publik pada 17 Maret 2026. Dua hari kemudian, serangan pertama terjadi, dan pemindaian massal mulai pada 23 Maret.

Adobe menerbitkan bulletin APSB26-73 pada 14 Juli 2026 dengan prioritas 2. Saat itu Adobe menulis tidak tahu ada eksploit liar. CISA baru memasukkan CVE ini ke CISA KEV pada 27 Oktober 2026, dengan batas 10 November 2026 untuk lembaga federal AS.

Magento berjalan di PHP, jadi toko Magento juga perlu patch PHP terbaru. Baca juga celah PHP2Shell di PHP. Bedanya, PolyShell ada di kode Magento, bukan di PHP.

Cara kerja: REST API keranjang tamu menyimpan file tanpa cek jenis file

Celah ini membuat toko menerima file dari pengunjung tanpa login dan menyimpannya di folder media.

Bagian ini memakai ringkasan resmi. Tujuannya membantu Anda memilih langkah yang tepat, bukan menjelaskan cara menyerang.

Ringkasan dari Adobe dan Sansec

Menurut catatan CVE Adobe, Adobe Commerce terdampak celah unggah file berbahaya tanpa batas (CWE-434). Celah ini bisa berujung eksekusi kode. NVD memberi skor yang sama, yaitu 9.3, dengan status Analyzed.

Menurut laporan Sansec, REST API keranjang belanja tamu menerima file sebagai bagian dari opsi produk. Magento menyimpan file itu di pub/media/custom_options/quote/. Magento tidak memeriksa ekstensi file, jadi file PHP yang menyamar sebagai gambar bisa tersimpan. Mutasi GraphQL memakai jalur lain dan tidak terdampak.

File yang tersimpan menjadi berbahaya bila web server menjalankan atau melayani file di folder itu. Sansec menulis bahwa banyak toko memakai konfigurasi web server dari penyedia hosting, bukan contoh resmi Magento.

Skor dari setiap sumber

Skor berbeda per sumber, jadi tulis skor bersama sumbernya.

Sumber	Skor	Catatan
Catatan CVE Adobe (CNA)	CVSS 3.1 9.3	Interaksi pengguna dibutuhkan, scope berubah, availability tidak terdampak
NVD	CVSS 3.1 9.3	Status Analyzed, data KEV tercatat
Bulletin APSB26-73	CVSS 3.1 9.6	Critical, tanpa autentikasi, dampak privilege escalation
Prioritas Adobe	2	Ditulis pada 14 Juli 2026, sebelum KEV
CISA KEV	Masuk 27 Oktober 2026	Sudah dipakai menyerang

Status eksploitasi per 31 Oktober 2026

CISA KEV mencatat CVE ini sebagai celah yang sudah dipakai menyerang. Sansec melaporkan file PHP berbahaya di 82% toko yang Sansec pantau pada 14 April 2026. Sesudah masuk, penyerang memasang backdoor accesson.php dan loader JavaScript di blok CMS.

Analisa Rama Digital: celah ini sudah berumur 7 bulan di tangan penyerang. Jadi anggap toko yang belum dipatch sebelum April 2026 sudah dipindai. Patch saja belum memadai untuk toko itu, jadi langkah 5 wajib.

Siapa yang paling berisiko

Toko Magento 2.4.x tanpa patch Juli 2026, dengan web server yang menjalankan file PHP di folder media, paling berisiko.

Tabel ini merangkum laporan Sansec, bulletin APSB26-73, dan contoh konfigurasi nginx resmi Magento.

Kondisi toko	Risiko	Alasan
Magento 2.4.x tanpa isolated patch Juli 2026	Tinggi	REST API aktif secara default, jadi file bisa terunggah
nginx custom yang mengirim semua file .php ke PHP-FPM	Tertinggi	Sansec: file unggahan bisa berjalan sebagai kode
Apache atau LiteSpeed tanpa .htaccess di custom_options	Tinggi	File di folder bisa terbaca atau berjalan
Toko yang pindah server atau ganti konfigurasi	Tambahan	File lama tetap ada di disk dan bisa terbuka nanti
Magento Open Source 2.4.6 dan lebih lama	Tinggi	Patch Open Source terbaru hanya untuk 2.4.7 ke atas
nginx dengan contoh resmi Magento 2.3 ke atas dan patch terbaru	Rendah	Contoh resmi menolak folder ini dan hanya menjalankan file entry point

Toko headless yang memakai GraphQL untuk keranjang tetap punya REST API aktif. Jadi toko headless tetap butuh patch.

Versi rentan dan versi aman

Pakai tabel cabang, karena label aman dari Adobe seperti 2.4.8-2026-jul bukan nomor versi Composer.

Produk atau cabang	Rentan	Aman per 31 Oktober 2026
Adobe Commerce dan Magento Open Source 2.4.9	2.4.9	2.4.9 + isolated patch 2026-jul atau lebih baru
2.4.8	2.4.8-p5 dan lebih lama	2.4.8-p5 + isolated patch 2026-jul atau lebih baru
2.4.7	2.4.7-p10 dan lebih lama	2.4.7-p10 + isolated patch 2026-jul atau lebih baru
2.4.6	2.4.6-p15 dan lebih lama	Commerce: 2.4.6-p15 + patch. Open Source: upgrade ke 2.4.7 atau lebih baru
Adobe Commerce 2.4.5 dan 2.4.4	2.4.5-p17, 2.4.4-p18 dan lebih lama	-p terakhir + isolated patch 2026-jul atau lebih baru
Adobe Commerce B2B	1.5.3, 1.5.2-p5, 1.4.2-p10, 1.3.4-p17, 1.3.3-p18	Versi yang sama + patch 2026-jul
Adobe Commerce Events	1.6.0 sampai 1.20.0	1.21.0
Magento Open Source 2.4.5 dan lebih lama	Tanpa patch	Upgrade ke 2.4.7 atau lebih baru

Data tabel berasal dari bulletin APSB26-73 dan APSB26-153. Menurut KB isolated patch Oktober 2026, patch bulanan datang sebagai berkas isolated patch tanpa paket Composer. Toko harus berada di versi -p terakhir, lalu memasang patch bulanan secara berurutan. Build terbaru per 31 Oktober 2026 adalah 2026-oct dari 13 Oktober 2026.

Adobe juga menerbitkan hotfix APSB26-146 pada 7 September 2026 untuk CVE-2026-75650, celah Magento lain yang sudah dipakai menyerang. Hotfix itu tidak ada di isolated patch Oktober, jadi pasang terpisah. Sansec menulis bahwa 2.4.9 rilis 12 Mei sudah memuat perbaikan PolyShell. Adobe tetap mencatat 2.4.9 sebagai rentan, jadi artikel ini mengikuti Adobe.

Prasyarat sebelum mulai

• Akses SSH ke server toko, dengan hak sudo atau user pemilik folder Magento.
• Path folder Magento, contoh /var/www/toko, dan URL toko.
• Akses ke database toko. Nama database ada di app/etc/env.php.
• Backup kode dan database yang baru, dan server staging bila ada.
• Untuk Adobe Commerce 2.4.6 dan lebih lama: kunci Composer dari akun Adobe, karena unduhan patch meminta kunci itu.

Langkah 1: Cek versi Magento dan patch bulanan

Simpan skrip ini sebagai cek-versi.sh. Skrip membaca edisi dan versi dari composer.lock, lalu mencari Commerce Version Tool dari patch Juli 2026.

#!/usr/bin/env bash
# Cek versi Magento dan patch Juli 2026 untuk CVE-2026-48356 (APSB26-73).
# Pakai: bash cek-versi.sh /var/www/toko
root="${1:-.}"
lock="$root/composer.lock"
if [ ! -f "$lock" ]; then echo "composer.lock tidak ada di $root"; exit 1; fi

# Baca versi 1 paket dari composer.lock.
pkg() {
  php -r '$l = json_decode(file_get_contents($argv[1]), true);
    foreach (array_merge($l["packages"] ?? [], $l["packages-dev"] ?? []) as $p)
      if ($p["name"] === $argv[2]) { echo ltrim($p["version"], "v"); exit; }' "$lock" "$1"
}

ee=$(pkg magento/product-enterprise-edition)
ce=$(pkg magento/product-community-edition)
if [ -n "$ee" ]; then edisi="Adobe Commerce"; versi=$ee; else edisi="Magento Open Source"; versi=$ce; fi
echo "Edisi: $edisi"
echo "Versi: ${versi:-tidak ditemukan}"

# Versi -p terakhir per cabang pada 31 Oktober 2026 (APSB26-73 dan APSB26-153).
case "$versi" in
  2.4.9) cabang=2.4.9; akhir=2.4.9 ;;
  2.4.9-*) cabang=pra; akhir=2.4.9 ;;
  2.4.8*) cabang=2.4.8; akhir=2.4.8-p5 ;;
  2.4.7*) cabang=2.4.7; akhir=2.4.7-p10 ;;
  2.4.6*) cabang=2.4.6; akhir=2.4.6-p15 ;;
  2.4.5*) cabang=2.4.5; akhir=2.4.5-p17 ;;
  2.4.4*) cabang=2.4.4; akhir=2.4.4-p18 ;;
  *) cabang=lama ;;
esac

if [ "$cabang" = lama ]; then
  echo "HASIL: RENTAN. Cabang ini tidak mendapat patch lagi. Upgrade ke 2.4.7 atau lebih baru."
elif [ "$cabang" = pra ]; then
  echo "HASIL: versi pra-rilis. Pindah ke 2.4.9, lalu pasang isolated patch Juli sampai Oktober 2026."
elif [ "$edisi" = "Magento Open Source" ] && [[ "$cabang" =~ ^2\.4\.[4-6]$ ]]; then
  echo "HASIL: RENTAN. Patch Open Source terbaru hanya untuk 2.4.7 ke atas. Upgrade ke 2.4.7-p10 atau lebih baru."
elif [ "$versi" != "$akhir" ]; then
  echo "HASIL: RENTAN. Naik dulu ke $akhir, lalu pasang isolated patch Juli sampai Oktober 2026."
elif [ -f "$root/vendor/bin/patch-status" ]; then
  echo "Commerce Version Tool ada. Baris untuk CVE-2026-48356:"
  (cd "$root" && php vendor/bin/patch-status | grep -i 'CVE-2026-48356') || echo "Baris CVE tidak ada. Baca output lengkap php vendor/bin/patch-status."
else
  echo "HASIL: RENTAN. $versi belum memuat patch Juli 2026, karena vendor/bin/patch-status tidak ada."
fi

# Modul tambahan Adobe Commerce, bila terpasang.
b2b=$(pkg magento/extension-b2b)
events=$(pkg magento/commerce-eventing)
[ -n "$b2b" ] && echo "B2B $b2b: pasang juga isolated patch B2B untuk versi ini."
if [ -n "$events" ]; then
  if [ "$(printf '%s\n' "$events" 1.21.0 | sort -V | head -1)" = 1.21.0 ]; then
    echo "Commerce Events $events: memuat patch."
  else
    echo "Commerce Events $events: RENTAN. Update ke 1.21.0."
  fi
fi

Jalankan skrip di folder toko. Anda juga bisa membaca versi dengan perintah Magento atau Composer.

cd /var/www/toko
bash cek-versi.sh /var/www/toko
# Cara lain untuk melihat versi
php bin/magento --version
composer show magento/product-community-edition    # Open Source
composer show magento/product-enterprise-edition   # Adobe Commerce

Commerce Version Tool hanya ada sesudah isolated patch Juli 2026 terpasang. Bila tool ada, skrip menjalankan php vendor/bin/patch-status dan menampilkan baris CVE-2026-48356. Status yang benar adalah PROTECTED.

Cek hasil: "Naik dulu ke" berarti toko belum di versi -p terakhir. "patch-status tidak ada" berarti patch Juli belum terpasang. "Upgrade ke 2.4.7-p10" berarti cabang Open Source Anda tidak mendapat patch lagi. Semua hasil itu berarti lanjut ke langkah 2, 3, dan 4.

Langkah 2: Cek folder unggahan dan aturan web server

Langkah ini menjawab 1 pertanyaan: apakah web server Anda melayani atau menjalankan file di pub/media/custom_options/?

Simpan skrip ini sebagai cek-folder.sh. Skrip menghitung file di folder, membaca .htaccess, lalu menulis 2 file uji tanpa kode dan memanggilnya dari web. Skrip menghapus file uji sesudahnya.

#!/usr/bin/env bash
# Cek folder unggahan custom_options dan aturan web server (CVE-2026-48356).
# Pakai: sudo -u www-data bash cek-folder.sh /var/www/toko https://toko-anda.com
root="${1:-.}"
url="${2%/}"
dir="$root/pub/media/custom_options"

echo "File di custom_options selain .htaccess: $(find "$dir" -type f ! -name .htaccess 2>/dev/null | wc -l)"
if [ ! -f "$dir/.htaccess" ]; then
  echo ".htaccess: tidak ada. Apache bisa melayani file di folder ini."
elif grep -qiE 'deny from all|require all denied' "$dir/.htaccess"; then
  echo ".htaccess: ada dan menolak akses. Berkas ini hanya berlaku di Apache."
else
  echo ".htaccess: ada, tetapi tidak menolak akses."
fi
if [ -z "$url" ]; then echo "Isi URL toko sebagai argumen ke-2 untuk uji dari web."; exit 0; fi

# Uji dari web dengan 2 file tanpa kode, lalu hapus file itu.
mkdir -p "$dir/quote"
nama="rd-cek-$$"
printf 'uji akses\n' > "$dir/quote/$nama.txt"
printf 'uji akses\n' > "$dir/quote/$nama.php"
terbuka=0
for f in "$nama.txt" "$nama.php"; do
  for p in media pub/media; do
    kode=$(curl -s -o /dev/null -w '%{http_code}' "$url/$p/custom_options/quote/$f")
    echo "/$p/custom_options/quote/$f -> HTTP $kode"
    case "$kode" in 403|404) ;; *) terbuka=1 ;; esac
  done
done
rm -f "$dir/quote/$nama.txt" "$dir/quote/$nama.php"
if [ "$terbuka" = 1 ]; then
  echo "HASIL: TERBUKA. Web server melayani atau menjalankan file di folder ini. Pasang langkah 4."
else
  echo "HASIL: tertutup. Semua permintaan mendapat 403 atau 404."
fi

# Jalankan sebagai user web server, agar file uji bisa ditulis
sudo -u www-data bash cek-folder.sh /var/www/toko https://toko-anda.com
# nginx: cari aturan untuk folder ini
sudo nginx -T 2>/dev/null | grep -n custom_options

Di uji kami, file teks mendapat HTTP 200 dan file .php mendapat 418 dari blok PHP tiruan. Di server asli, file .php yang mendapat 200 berarti PHP menjalankan file di folder itu. Berkas .htaccess hanya berlaku di Apache dan LiteSpeed, bukan di nginx.

Cek hasil: "tertutup" berarti semua permintaan mendapat 403 atau 404. "TERBUKA" berarti pasang langkah 4 hari ini. Jumlah file di atas 0 berarti jalankan langkah 5.

Langkah 3: Pasang versi -p terakhir, isolated patch, dan hotfix APSB26-146

Hanya patch dari Adobe yang menutup celah ini, dan patch harus terpasang di versi -p terakhir cabang Anda.

Urutan ini mengikuti KB isolated patch Oktober 2026 dan panduan Adobe untuk memasang isolated patch. Contoh memakai cabang 2.4.8 dan Magento Open Source.

# 0. Backup kode dan database. Uji dulu di staging.
php bin/magento maintenance:enable
# 1. Naik ke versi -p terakhir cabang Anda. Contoh: cabang 2.4.8.
composer require magento/product-community-edition=2.4.8-p5 --no-update
composer update
php bin/magento setup:upgrade
# 2. Pasang isolated patch Juli, Agustus, September, dan Oktober 2026, berurutan.
#    Pola nama berkas dari Adobe: <versi>-<tahun>-<bulan>-<urutan>-<komponen>.patch
patch -p1 --dry-run < 248p5-2026-07-001-CE.patch
patch -p1 < 248p5-2026-07-001-CE.patch
#    Ulangi untuk berkas bulan berikutnya. Adobe Commerce: berkas CE, lalu EE.
# 3. Pasang hotfix CVE-2026-75650 dari APSB26-146 dengan cara yang sama.
# 4. Cek hasil, lalu buka toko lagi.
php vendor/bin/patch-status
php bin/magento cache:flush
php bin/magento maintenance:disable

Unduh berkas patch dari KB isolated patch Oktober 2026 dan KB bulan Juli, Agustus, dan September. Setiap berkas ZIP bisa memuat beberapa berkas per komponen. Pasang hanya berkas yang cocok dengan versi komponen yang terpasang. Bila -p1 gagal, panduan Adobe untuk memasang isolated patch menyarankan -p2.

Untuk Adobe Commerce, ganti nama paket dengan magento/product-enterprise-edition. Untuk Adobe Commerce on Cloud, taruh berkas patch di folder m2-hotfixes lalu deploy, atau pakai paket cloud-patches terbaru. Untuk Commerce Events, update modul ke 1.21.0.

Cek hasil: php vendor/bin/patch-status mencetak PROTECTED untuk CVE-2026-48356 dan tidak mencetak patch Juli sampai Oktober di daftar missing. Lalu jalankan cek-versi.sh lagi.

Langkah 4: Pasang mitigasi sementara sampai patch terpasang

Langkah ini menahan file di folder unggahan agar tidak terbaca atau berjalan, tetapi tidak menghentikan unggahan.

Analisa Rama Digital: Kami menyusun 3 langkah dari laporan Sansec dan contoh konfigurasi nginx resmi Magento. Kondisi: toko belum bisa dipatch hari ini. Batas: file tetap bisa tersimpan di disk, jadi langkah ini tidak menutup celah.

4a. nginx: tolak folder custom_options di atas blok PHP

Contoh resmi Magento sudah memakai location /media/custom_options/ { deny all; } dan hanya mengirim file entry point ke PHP-FPM. Banyak hosting mengirim semua file .php ke PHP-FPM. Untuk konfigurasi itu, tambah blok ini dari Sansec.

# Taruh di dalam blok server, DI ATAS semua blok location untuk PHP.
location ~* ^/(pub/)?media/custom_options/ {
    deny all;
    return 403;
}

sudo nginx -t && sudo systemctl reload nginx
sudo -u www-data bash cek-folder.sh /var/www/toko https://toko-anda.com

Uji kami membuktikan bahwa urutan menentukan hasil. Aturan di bawah blok PHP memberi 403 untuk file teks, tetapi file .php tetap masuk ke blok PHP. Aturan di atas blok PHP memberi 403 untuk semua file.

4b. Apache dan LiteSpeed: cek .htaccess

Pastikan pub/media/custom_options/.htaccess ada. Isi resmi Magento memakai 6 baris pertama di bawah. Sansec menambah blok php_flag engine 0.

<IfVersion < 2.4>
    order deny,allow
    deny from all
</IfVersion>
<IfVersion >= 2.4>
    Require all denied
</IfVersion>
<IfModule mod_php.c>
    php_flag engine 0
</IfModule>

Berkas ini hanya berlaku bila AllowOverride mengizinkannya. Jalankan cek-folder.sh sesudahnya untuk membuktikan hasilnya. Kami tidak menguji Apache dan LiteSpeed di artikel ini.

4c. WAF: blokir unggahan file lewat rute REST keranjang tamu

Menurut laporan Sansec, hanya WAF yang memblokir panggilan API itu yang menghentikan unggahan. Minta penyedia WAF Anda aturan untuk PolyShell atau CVE-2026-48356. Pada pembaruan terakhir Sansec, Cloudflare belum menerbitkan aturan khusus. Uji tombol beli dan checkout sesudah aturan aktif, karena toko headless memakai rute REST keranjang.

Cek hasil: cek-folder.sh mencetak "tertutup". Batas: file yang sudah tersimpan tetap ada di disk. Konfigurasi baru atau migrasi server bisa membukanya lagi.

Langkah 5: Periksa tanda toko sudah disentuh

Patch tidak menghapus file yang penyerang tanam, jadi periksa disk, log, dan database.

Simpan skrip ini sebagai cek-tanda.sh. Skrip mencari file di folder unggahan, file PHP dan gambar berisi kode PHP, backdoor accesson.php, dan baris log yang mencurigakan.

#!/usr/bin/env bash
# Cek tanda serangan CVE-2026-48356 (PolyShell) di disk dan di log web server.
# Pakai: sudo bash cek-tanda.sh /var/www/toko /var/log/nginx/access.log
root="${1:-.}"
log="${2:-}"
dir="$root/pub/media/custom_options"
tampil() { if [ -n "$1" ]; then printf '%s\n' "$1" | sed 's/^/   /'; else echo "   tidak ada"; fi; }

echo "1. File di custom_options selain .htaccess:"
tampil "$(find "$dir" -type f ! -name .htaccess 2>/dev/null | head -20)"
echo "2. File berekstensi PHP di custom_options:"
tampil "$(find "$dir" -type f -iregex '.*\.\(php[0-9]?\|phtml\|phar\|pht\|phps\)' 2>/dev/null)"
echo "3. File berisi kode PHP di custom_options, termasuk gambar:"
tampil "$(grep -rlE '<\?(php|=)' "$dir" 2>/dev/null)"
echo "4. accesson.php dan file PHP di folder assets/images:"
tampil "$(find "$root" -type f \( -name accesson.php -o -path '*/assets/images/*.php' \) 2>/dev/null)"
echo "5. File PHP lain di pub/media:"
tampil "$(find "$root/pub/media" -type f -iname '*.ph*' ! -path "$dir/*" 2>/dev/null)"
if [ -n "$log" ]; then
  echo "6. Respons 200 dari folder custom_options di log:"
  tampil "$(grep -E '/(pub/)?media/custom_options/' "$log" | awk '$9 == 200' | tail -5)"
  echo "7. POST atau PUT ke item keranjang tamu: $(grep -cE '"(POST|PUT) [^"]*guest-carts/[^/ ]+/items' "$log")"
fi

sudo bash cek-tanda.sh /var/www/toko /var/log/nginx/access.log
# Apache: /var/log/apache2/access.log atau log domain di panel hosting

Lalu simpan query ini sebagai cek-cms.sql. Query mencari tag script di blok dan halaman CMS, nama domain loader dari laporan Sansec, dan 5 akun admin terbaru.

-- Cek blok CMS, halaman CMS, dan akun admin (CVE-2026-48356).
-- Tambah prefix tabel bila toko Anda memakai prefix.
SELECT block_id, identifier, update_time FROM cms_block WHERE content LIKE '%<script%';
SELECT page_id, identifier, update_time FROM cms_page WHERE content LIKE '%<script%';
-- Nama domain loader dari laporan Sansec.
SELECT 'cms_block' AS tabel, block_id AS id, identifier FROM cms_block
  WHERE content REGEXP 'lanhd6549tdhse|jslibrary|canevaslab|deepveindrilling'
UNION ALL
SELECT 'cms_page', page_id, identifier FROM cms_page
  WHERE content REGEXP 'lanhd6549tdhse|jslibrary|canevaslab|deepveindrilling';
SELECT user_id, username, email, created, logdate, is_active FROM admin_user
  ORDER BY created DESC LIMIT 5;

# Baca nama database dari app/etc/env.php, lalu jalankan:
mysql -t -u USER_DB -p NAMA_DB < cek-cms.sql      # atau mariadb -t

Tag script di blok CMS bisa sah, contoh script chat atau analitik. Cocokkan setiap hasil dengan perubahan yang tim Anda buat. POST ke item keranjang tamu juga normal di toko headless, jadi bandingkan jumlahnya dengan hari biasa.

Cek hasil: 0 file di custom_options selain .htaccess, 0 accesson.php, 0 script asing di CMS, dan tidak ada admin yang tidak Anda kenal. Bila ada 1 tanda saja, aktifkan mode maintenance dan simpan log serta salinan disk. Lalu ganti kredensial sesuai daftar di KB hotfix APSB26-146: kunci enkripsi, password admin, token integrasi, API key pembayaran di penyedia, password database, dan kunci SSH. Pasang ulang kode dari sumber bersih, lalu pasang patch.

Contoh: 1 pagi respons untuk 3 toko

Simulasi ini memakai data dummy. Nama toko, waktu, dan hasil bukan data pelanggan.

Waktu (WIB)	Toko dummy	Yang dicek	Hasil	Tindakan
07.00	toko-fashion (Open Source 2.4.8-p3, nginx hosting)	Langkah 1 dan 2	RENTAN, folder TERBUKA	Langkah 4a pagi ini, patch malam ini
07.40	toko-grosir (Adobe Commerce 2.4.7-p10, B2B)	Langkah 1	patch-status tidak ada	Patch CE, EE, dan B2B Juli sampai Oktober, lalu hotfix
08.30	toko-lama (Open Source 2.4.6-p15, Apache)	Langkah 2 dan 5	Folder tertutup, 1 file .php di custom_options, 1 admin baru	Respons insiden, ganti kredensial, upgrade ke 2.4.7-p10
10.00	Semua toko	Langkah 5	Hasil disimpan bersama log	Ulangi langkah 5 setiap minggu

Pelajaran dari simulasi: folder yang tertutup tidak membuktikan toko bersih. Toko-lama tertutup di langkah 2, tetapi langkah 5 tetap menemukan file dan admin baru.

Siapa yang memasang patch

Tanggung jawab patch berbeda per cara hosting, jadi tabel ini membantu Anda tahu siapa yang bergerak hari ini.

Cara hosting	Pemegang patch	Yang Anda kerjakan
VPS atau server sendiri	Tim IT atau developer Anda	Langkah 1 sampai 5
Adobe Commerce on Cloud	Tim Anda, lewat cloud-patches atau m2-hotfixes	Deploy patch, lalu langkah 1 dan 5
Hosting Magento terkelola	Penyedia untuk server, tim Anda untuk kode Magento	Minta output patch-status tertulis, lalu langkah 5
Agensi atau developer pihak ketiga	Agensi sesuai kontrak	Minta output langkah 1, 2, dan 5 tertulis

Rekomendasi Rama Digital: toko yang memegang API key payment gateway harus memperlakukan setiap tanda di langkah 5 sebagai insiden. Untuk daftar cek server toko online, baca juga checklist keamanan server dan payment gateway toko online.

Checklist hari ini

1. Buat daftar semua toko Magento dan Adobe Commerce, termasuk staging. Pemilik: tim IT. Bukti: daftar URL dan path.
2. Cek versi dengan langkah 1. Pemilik: developer. Bukti: output skrip per toko.
3. Cek folder dengan langkah 2. Pemilik: admin server. Bukti: output skrip per toko.
4. Pasang langkah 4 di setiap toko yang TERBUKA. Pemilik: admin server. Bukti: output langkah 2 sesudah aturan aktif.
5. Pasang versi -p terakhir, patch Juli sampai Oktober 2026, dan hotfix APSB26-146. Pemilik: developer. Bukti: output patch-status.
6. Periksa tanda dengan langkah 5. Pemilik: admin server. Bukti: output skrip dan query, disimpan bersama log.
7. Cek bulletin Adobe setiap bulan, karena patch berikutnya datang sebagai isolated patch baru.

Tanya jawab

Toko saya sudah 2.4.8-p5. Apakah toko saya aman?

Belum. Versi 2.4.8-p5 adalah versi rentan terakhir di bulletin Adobe. Toko aman sesudah isolated patch Juli 2026 atau lebih baru terpasang di atas 2.4.8-p5.

Kenapa Composer tidak menawarkan versi 2.4.8-2026-jul?

Adobe mengirim patch bulanan sebagai berkas isolated patch, bukan paket Composer. Nomor versi Composer tetap 2.4.8-p5. Cek patch dengan php vendor/bin/patch-status.

Toko saya Magento Open Source 2.4.6. Apa yang saya lakukan?

Pasang langkah 4 hari ini, lalu jalankan langkah 5. Rencanakan upgrade ke 2.4.7-p10 atau lebih baru, karena patch Open Source terbaru hanya untuk 2.4.7 ke atas.

Folder sudah ditolak di nginx. Apakah toko saya aman?

Belum. Aturan hanya menahan akses web ke file. Unggahan tetap bisa masuk ke disk, dan konfigurasi baru bisa membuka file itu lagi. Pasang patch.

Apakah toko headless dengan GraphQL terdampak?

Sansec menulis bahwa mutasi GraphQL tidak terdampak. Tetapi REST API tetap aktif secara default di toko headless. Jadi patch tetap perlu.

Apakah patch menghapus backdoor yang sudah tertanam?

Tidak. Patch hanya menutup celah. Jalankan langkah 5 untuk mencari file, script CMS, dan akun admin yang penyerang tambahkan.

Kenapa skor ada 9.3 dan 9.6?

Catatan CVE dan NVD memberi 9.3 tanpa dampak ke availability. Bulletin APSB26-73 memberi 9.6 dengan dampak rendah ke availability. Keduanya Critical.

Apakah plugin keamanan Magento memadai tanpa patch?

Tidak. Pemindai dan WAF membantu menemukan dan menahan serangan, tetapi kode rentan tetap ada sampai patch Adobe terpasang.

Langkah berikutnya

Batas yang tetap berlaku: mitigasi di langkah 4 tidak menutup celah, dan patch tidak menghapus file yang sudah tertanam. Bila toko Anda menunjukkan tanda di langkah 5, atau Anda butuh bantuan memasang patch dan memeriksa toko, pakai Vibe Code Rescue untuk audit dan stabilisasi. Untuk 1 kendala yang mendesak hari ini, jadwalkan sesi 30 menit.

Sumber

• catatan CVE Adobe: ringkasan celah, CWE-434, skor 9.3, dan versi terdampak.
• NVD: skor 9.3, status Analyzed, dan data KEV.
• bulletin APSB26-73: skor 9.6, prioritas 2, versi terdampak, dan label versi aman.
• APSB26-153: build 2026-oct dan catatan hotfix APSB26-146.
• KB isolated patch Oktober 2026: isolated patch, urutan pemasangan, dan Commerce Version Tool.
• KB hotfix APSB26-146: CVE-2026-75650 dan daftar kredensial yang harus diganti.
• panduan Adobe untuk memasang isolated patch: perintah patch -p1.
• laporan Sansec: nama PolyShell, linimasa serangan, tanda serangan, dan aturan web server.
• CISA KEV: CVE-2026-48356 masuk katalog 27 Oktober 2026.
• contoh konfigurasi nginx resmi Magento: aturan resmi untuk folder custom_options.