zero-day ที่ยังไม่มีแพตช์ใน Magento และ Adobe Commerce ถูกใช้ฝังแบ็กดอร์ร้านค้าออนไลน์ — Sansec เปิดเผยก่อนกำหนดเพราะร้านกำลังถูกยึดอยู่ตอนนี้

สรุปสั้น

บริษัท Sansec ผู้ให้บริการความปลอดภัยด้านอีคอมเมิร์ซจากเนเธอร์แลนด์ ออกประกาศเตือนเมื่อวันที่ 5 กันยายน 2569 ว่าพบช่องโหว่ใหม่ที่ยังไม่มีแพตช์ใน Magento Open Source และ Adobe Commerce ซึ่งเปิดทางให้ผู้โจมตีรันโค้ดที่เป็นอันตรายบนเซิร์ฟเวอร์ของร้านค้าออนไลน์ได้โดยไม่ต้องล็อกอิน บริษัทตั้งชื่อช่องโหว่นี้ว่า StyleSmuggler ระบุว่าการโจมตีเริ่มขึ้นตั้งแต่วันที่ 4 กันยายน และเลือกเผยแพร่ก่อนกำหนดด้วยเหตุผลตรงไปตรงมาว่า “ร้านค้ากำลังถูกเจาะอยู่ในขณะนี้”

เมื่อโจมตีสำเร็จ ผู้โจมตีจะได้สิทธิ์รันโค้ดบนเซิร์ฟเวอร์ของร้านและติดตั้งแบ็กดอร์แบบฝังตัวถาวร Sansec ระบุว่าทุกเวอร์ชันปัจจุบันได้รับผลกระทบรวมถึง 2.4.9 และได้ทำซ้ำห่วงโซ่การโจมตีแบบไม่ต้องยืนยันตัวตนได้ครบบน Magento Open Source ที่ติดตั้งใหม่สะอาดทั้งเวอร์ชัน 2.4.7, 2.4.8 และ 2.4.9 ที่ควรบันทึกไว้คือเหยื่อรายแรกรัน 2.4.6-p15 พร้อมแพตช์ความปลอดภัยของ Adobe รอบกรกฎาคมและสิงหาคม 2569 แล้ว ซึ่งเป็นระดับแพตช์สูงสุดที่ Adobe มีให้สำหรับสายเวอร์ชันนั้น พูดอีกอย่างคือการอัปเดตครบไม่ได้ช่วยอะไรในกรณีนี้ จนถึงวันที่ 6 กันยายน Adobe ยังไม่ได้ออกประกาศเตือน ยังไม่มีเลข CVE ไม่มีแพตช์ และไม่มี workaround อย่างเป็นทางการ คำแนะนำชั่วคราวของ Sansec สำหรับร้านที่ไม่ได้ใช้ผลิตภัณฑ์ Shield ของตัวเองคือให้ปิด GraphQL ไว้ก่อนจนกว่า Adobe จะแก้ไข

รายละเอียดข่าว

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 6 กันยายน 2569 ว่า ผู้โจมตีกำลังใช้ช่องโหว่ใหม่ที่ยังไม่มีแพตช์ใน Magento Open Source และ Adobe Commerce เพื่อรันโค้ดอันตรายบนเซิร์ฟเวอร์ร้านค้าออนไลน์โดยไม่ต้องล็อกอิน ตามประกาศเตือนที่บริษัท Sansec เผยแพร่เมื่อวันที่ 5 กันยายน

Sansec ซึ่งเป็นผู้ค้นพบช่องโหว่และตั้งชื่อว่า StyleSmuggler ระบุว่าการโจมตีเริ่มขึ้นเมื่อวันที่ 4 กันยายน และเขียนไว้ตรง ๆ ว่า “Sansec เผยแพร่เร็วเพราะร้านค้ากำลังถูกเจาะอยู่ในขณะนี้” จนถึงวันที่ 6 กันยายน Adobe ยังไม่ได้เผยแพร่ประกาศเตือน เลข CVE แพตช์ หรือ workaround ใด ๆ และดัชนีประกาศความปลอดภัยของ Adobe Commerce ก็ยังไม่มีรายการใดหลังการอัปเดตวันที่ 11 สิงหาคม

Sansec ยังไม่ได้เผยแพร่การทำซ้ำบน Adobe Commerce หรือ Adobe Commerce on Cloud และ Adobe ก็ยังไม่ได้ยืนยันว่าเวอร์ชันใดได้รับผลกระทบบ้าง อีกทั้ง Sansec ไม่ได้ระบุจำนวนร้านค้าที่ถูกเจาะไปแล้ว คำแนะนำชั่วคราวของบริษัทสำหรับร้านที่ไม่ได้ใช้ผลิตภัณฑ์ Shield คือปิดการใช้งาน GraphQL ชั่วคราวจนกว่า Adobe จะออกตัวแก้ไข ขณะที่บริษัท Disrex Group ผู้ให้บริการโฮสติงและพัฒนา Magento ตั้งข้อสังเกตว่าหน้าร้านแบบ headless และ progressive web app จำเป็นต้องใช้ GraphQL ในขณะที่หน้าร้านแบบคลาสสิกและ Hyvä ส่วนใหญ่ไม่ต้องใช้ ทั้งนี้ Sansec ระบุว่ารอบปล่อยแพตช์ตามกำหนดถัดไปของ Adobe คือวันที่ 8 กันยายน แต่ยังไม่ทราบว่ารอบนั้นจะครอบคลุมบั๊กตัวนี้หรือไม่

หลักฐานการถูกโจมตีจริงจากภายนอก Sansec มาจาก Disrex ซึ่งเผยแพร่ที่เก็บข้อมูลสำหรับการตอบสนองเหตุการณ์เมื่อวันที่ 5 กันยายน โดยระบุว่าบริษัทรับมือร้านค้าที่ถูกเจาะ 2 ร้าน และอีก 1 ร้านที่ถูกโจมตีแต่ไม่สำเร็จ กฎสำหรับเว็บเซิร์ฟเวอร์ที่บริษัทเผยแพร่นั้นสร้างจากทราฟฟิกการโจมตีที่ดักจับได้จากร้านหนึ่งในสองร้านนั้น Disrex ตอบคำถามของ The Hacker News ว่าทั้งสองร้านใช้ Magento Open Source ไม่ใช่ Adobe Commerce และบริษัทเป็นผู้โฮสต์เองผ่านแบรนด์โฮสติงชื่อ RexHosting

ร้านที่ Disrex เรียกว่า Store A ใช้ Magento Open Source 2.4.8 และเป็นลูกค้า Sansec Shield โดยติดตั้งโมดูล เปิดใช้งาน และมีไลเซนส์ครบ ถูกโจมตีเมื่อเวลา 23:10 UTC ของวันที่ 4 กันยายน ซึ่งเป็นเวลาหลายชั่วโมงก่อนที่กฎบล็อกชุดแรกของ Sansec สำหรับช่องโหว่นี้จะเริ่มทำงาน และ Disrex ระบุว่าขณะนั้น Shield ทำงานอยู่และบล็อกทราฟฟิกอันตรายอื่น ๆ ต่อร้านนี้ได้ตามปกติ ส่วน Store B ซึ่งไม่ได้เป็นลูกค้า Shield ใช้ Magento 2.4.7-p2 ซึ่งเป็นระดับแพตช์ที่ประวัติเวอร์ชันของ Adobe ระบุว่าเป็นของเดือนสิงหาคม 2567 ตามหลังระดับปัจจุบันคือ 2.4.7-p10 อยู่ 8 ระดับ ถูกโจมตีครั้งแรกเวลา 00:55 UTC ของวันที่ 5 กันยายน

ทั้งสองร้านถูกเจาะภายในช่วงเวลาราว 8 ชั่วโมงระหว่างการโจมตีครั้งแรกที่ Sansec สังเกตเห็น กับช่วงเวลาที่เริ่มมีเครื่องมือป้องกันสำหรับช่องโหว่นี้ Disrex บอกกับ The Hacker News ว่า “สถานะแพตช์ไม่มีความหมายในกรณีนี้ ซึ่งเป็นส่วนที่พ่อค้าแม่ค้าออนไลน์จำเป็นต้องได้ยินมากที่สุด” อย่างไรก็ตาม ที่เก็บข้อมูลของ Disrex เองมีคำเตือนกำกับไว้ว่า “ที่เก็บนี้เขียนขึ้นโดยมี AI ช่วย ระหว่างเหตุการณ์ที่กำลังเกิดขึ้นจริง ภายในเวลาไม่กี่ชั่วโมง” พร้อมระบุว่ายังไม่ผ่านการทบทวน กฎสำหรับ Apache ไม่เคยถูกรันกับเซิร์ฟเวอร์ Apache จริง และคำสั่งทำความสะอาดส่วนใหญ่เป็นสิ่งที่เขียนไว้แต่ยังไม่ได้ลงมือรัน

วิธีการโจมตี

ตามโครงที่ Sansec วางไว้ การโจมตีทำงานเป็น 2 ขั้น ขั้นแรกคือฝังโค้ด PHP ลงในไฟล์ที่ Magento เขียนขึ้นเอง เช่น ตอนสร้างรายงานความผิดพลาด จากนั้นขั้นที่สองคือทำให้ Magento รันไฟล์นั้นด้วยการกระตุ้นอีเมลมาตรฐานของแพลตฟอร์มชื่อ “Payment Transaction Failed Reminder” โดยโค้ดจะทำงานระหว่างที่ Magento เรนเดอร์ข้อความ ทำให้ไม่ต้องมีใครเปิดอีเมล และการโจมตีสำเร็จได้แม้การส่งอีเมลจะล้มเหลว ทั้งนี้ Sansec ยังไม่ได้เผยแพร่ห่วงโซ่การโจมตีฉบับเต็ม โดยระบุว่าจะตามมาในอัปเดตภายหลัง

การอ่านห่วงโซ่ของ Disrex ซึ่งเผยแพร่ในเอกสารอธิบายกลไกควบคู่กับกฎของตัวเอง ระบุว่าคำสั่งพิเศษที่แทรกอยู่ในข้อความจะขับเคลื่อนคลาสต่าง ๆ ของ Magento เองต่อกันเป็นทอด ๆ ไปจนถึงโค้ดที่มีไว้รับใช้ตัวคอมไพล์ dependency injection สำหรับบรรทัดคำสั่งโดยเฉพาะ ปลายทางของโค้ดส่วนนั้นคือการ include ไฟล์ตามเส้นทางที่ผู้โจมตีเลือก ซึ่งก็คือล็อกที่เพิ่งถูกวางยาไปเมื่อครู่ จากนั้น dropper ที่เป็น PHP จะไล่เรียกฟังก์ชัน PHP 6 ตัวตามลำดับเพื่อเปิดกระบวนการใหม่ แล้วดาวน์โหลดและเรียกใช้แบ็กดอร์ Disrex ระบุจุดจบของห่วงโซ่ไว้ที่ไฟล์ 3 ไฟล์ใต้ setup/src/Magento/Setup/Module/Di/Code/ และบอกว่าค้นพบจุดนั้นเองจากการอ่านซอร์สโค้ด Magento บนร้านที่ถูกเจาะ ทั้งนี้ Sansec ยังไม่ได้ยืนยันการอ่านดังกล่าว และ Disrex ไม่ได้เผยแพร่คำร้องขอฉบับประกอบเสร็จ

จุดที่ต้องระวังในการไล่ตรวจคือตำแหน่งของขั้นแรกมี 2 แห่ง คำสั่งตรวจสอบที่ Sansec เผยแพร่จะค้นหาเครื่องหมาย X_TRACE_ ในโฟลเดอร์ var/report/ แต่ Disrex ระบุว่าการติดเชื้อทั้งสองกรณีของตัวเองถูกวางยาผ่าน var/log/system.log แทน ซึ่งจะหลุดจากการตรวจแบบนั้น จึงต้องค้นทั้งสองโฟลเดอร์ ยิ่งกว่านั้นเครื่องหมายดังกล่าวเปลี่ยนรูปไปแล้ว โดย Disrex เห็นเฮดเดอร์ที่ใช้กระตุ้นในรูปแบบ X-TRACE- ตามด้วยอักขระฐานสิบหก 10 ตัวในเช้าวันที่ 5 กันยายน และเห็นเฮดเดอร์เดียวกันโดยไม่มีคำว่า TRACE ในช่วงบ่ายวันเดียวกัน การค้นหาจึงควรจับที่รูปทรงของสตริงมากกว่าสตริงตรงตัว หลักฐานว่าการโจมตีสำเร็จคือข้อความ TypeError จาก array_merge() ที่ได้อาร์กิวเมนต์เป็นจำนวนเต็มปรากฏใน system.log ทันทีหลังการ include แต่ Disrex เตือนว่ามีตัวแปรที่เงียบกว่าซึ่งคืนค่าเป็นอาร์เรย์ว่างและไม่ทิ้งร่องรอยในล็อกเลย

ตัวแบ็กดอร์เองถูกออกแบบมาให้กลืนไปกับระบบ Sansec อธิบายว่าเป็นกระบวนการเบื้องหลังที่ปลอมชื่อเป็น [kworker/u:8:0] ซึ่งเป็นชื่อของเธรดเคอร์เนลลินุกซ์ โดยไบนารีถูกติดตั้งไว้ที่ ~/.local/share/.gvfsd/gvfsd-user ใต้โฮมไดเรกทอรีของผู้ใช้ที่เป็นเจ้าของเว็บไซต์ ไม่ใช่ใน web root และมีรายการ cron ที่รีสตาร์ตมันทุก 5 นาที Disrex อธิบายเพิ่มว่าไบนารีเป็นโปรแกรมภาษา Rust ที่ strip แล้วและลิงก์แบบสแตติก ขนาดราว 1.9 MB สร้างสำหรับ x86-64 และ arm64 ส่วนรายการ cron ถูกเขียนตรงลงไฟล์ spool ใต้ /var/spool/cron/crontabs/ ทำให้ล็อกของระบบไม่แสดงการแทนที่ crontab เลย ร้านหนึ่งมีบรรทัดเดียวกันซ้ำถึง 1,728 ครั้ง และแบ็กดอร์เขียนกลับเข้าไปใหม่ภายในเวลาไม่ถึงวินาทีหลังถูกลบ

พฤติกรรมด้านเครือข่ายก็หักล้างความคาดหมายเช่นกัน บนร้านหนึ่งในสองร้าน แบ็กดอร์ไม่ได้เชื่อมต่อออกภายนอกเลยแม้แต่ครั้งเดียว มันคง 28 การเชื่อมต่อไปยัง Redis ของร้านเองที่พอร์ต 6379 และอ่านที่เก็บเซสชันของ Magento จากตรงนั้น โดย Disrex ระบุว่าไฟล์ดักจับแพ็กเก็ตทั้งสองไฟล์ซึ่งแต่ละไฟล์ใหญ่กว่า 200 MB และเก็บระหว่างที่แบ็กดอร์ทำงานอยู่ ไม่มีแพ็กเก็ตใดเลยที่วิ่งไปยังโฮสต์ดาวน์โหลดหรือที่อยู่ command-and-control ที่ Sansec ระบุไว้ นอกจากนี้ Disrex ยังพบว่าไบนารีที่รันอยู่ในหน่วยความจำบนร้านหนึ่งเป็นคนละบิลด์กับไฟล์บนดิสก์ จึงแนะนำให้แฮชกระบวนการที่กำลังรันจาก /proc/<pid>/exe ควบคู่กับไฟล์ด้วย และเตือนว่าเธรดเคอร์เนลของจริงจะเป็นของ root และไม่มีหน่วยความจำ resident ดังนั้นชื่อในวงเล็บเหลี่ยมที่เป็นของผู้ใช้เว็บไซต์และกินหน่วยความจำจริงคือตัวปลอม อีกทั้งแบ็กดอร์ตั้งค่า command line ของตัวเองเป็นสตริงในวงเล็บนั้น การตรวจที่เขียนไว้ให้จับ field comm ของกระบวนการจึงจับไม่ได้เลย

สัญญาณเตือนล่วงหน้าที่ใช้ได้จริงที่สุดกลับเป็นอีเมล Sansec ระบุว่าอีเมล “Payment Transaction Failed Reminder” ที่ทะลักออกมาผิดปกติเป็นเหตุให้ต้องสอบสวน แม้รายการชำระเงินที่ถูกปฏิเสธตามปกติจะสร้างการแจ้งเตือนแบบเดียวกันก็ตาม การถูกเจาะ 1 ใน 2 กรณีของ Disrex ถูกพบด้วยอีเมลฉบับนี้พอดี โดย นาย Rick Bouma ผู้ร่วมก่อตั้ง Disrex เล่ากับ The Hacker News ว่าร้านส่งอีเมลแจ้งรายการชำระเงินล้มเหลวไปหาเจ้าของร้านเอง โดยตัวแปรในเทมเพลตไม่ถูกแทนค่า เนื้ออีเมลเต็มไปด้วยแท็ก {{var ...}} ดิบ ๆ ที่อยู่ลูกค้าเป็นโดเมน .invalid และยอดรวมเป็นศูนย์ ซึ่งอ่านดูเหมือนคำสั่งซื้อที่พัง แต่แท้จริงคือไอเสียจากความพยายามโจมตีที่วิ่งผ่านตัวกรองเทมเพลตของ Magento และการที่เจ้าของร้านส่งต่ออีเมลฉบับนั้นมาให้ คือจุดเริ่มของการสอบสวนที่พบแบ็กดอร์ภายในหนึ่งชั่วโมง

ผลกระทบ

ผู้ที่ได้รับผลกระทบคือร้านค้าออนไลน์ทุกร้านที่รัน Magento Open Source หรือ Adobe Commerce ในเวอร์ชันที่ยังใช้งานอยู่ทั้งหมด และเนื่องจากยังไม่มีแพตช์ ความเสี่ยงจึงไม่ได้ลดลงตามระดับแพตช์ที่ติดตั้งไว้ เหยื่อรายแรกที่ Sansec พบอัปเดตครบทุกรอบที่ Adobe มีให้แล้ว

ประเด็นที่หนักที่สุดสำหรับผู้ประกอบการคือการเจาะครั้งนี้ทำให้ผู้โจมตีได้สิทธิ์รันโค้ดบนเซิร์ฟเวอร์ที่ประมวลผลคำสั่งซื้อและข้อมูลลูกค้าโดยตรง แม้ในสองกรณีที่ Disrex รับมือจะยังไม่พบการดึงข้อมูลออก ไม่พบบัญชีผู้ดูแลระบบแปลกปลอม ไม่พบสคริปต์ดักข้อมูลบัตร และไม่พบแบ็กดอร์ในฐานข้อมูล แต่แบ็กดอร์อ่านที่เก็บเซสชันของ Magento จาก Redis ได้ ซึ่งหมายถึงเซสชันของผู้ใช้ที่กำลังใช้งานอยู่ตกอยู่ในความเสี่ยง Disrex จึงยกเลิกเซสชันทั้งหมดและเริ่มหมุนข้อมูลรับรองเป็นการป้องกันล่วงหน้า

อีกบทเรียนที่ควรบันทึกไว้คือขอบเขตของการสแกนสำคัญไม่แพ้ตัวสแกนเนอร์ เครื่องมือ eComscan ของ Sansec รันบน Store A เมื่อเวลา 10:00 UTC วันที่ 5 กันยายน ซึ่งเป็นเวลาราว 11 ชั่วโมงหลังแบ็กดอร์เริ่มทำงานและขณะที่มีบรรทัด cron อยู่ถึง 1,728 บรรทัด แต่กลับรายงานว่าร้านสะอาด Disrex ระบุว่าสาเหตุคือขอบเขตการสแกนไม่ใช่ความผิดพลาดของตัวสแกนเนอร์ เพราะการสแกนตามกำหนดถูกชี้ไปที่ document root ของร้าน ขณะที่แบ็กดอร์ติดตั้งตัวเองอยู่สูงขึ้นไปหนึ่งไดเรกทอรีใต้โฮมของบัญชี ปัจจุบัน Disrex ได้ขยายเส้นทางการสแกนแล้ว

ในแง่โครงสร้างการโฮสต์ ข่าวนี้ให้ตัวอย่างที่ชัดว่าการแยกบัญชีช่วยจำกัดความเสียหายได้จริง Disrex ระบุว่าแต่ละร้านทำงานในบัญชีที่แยกออกจากกัน มีเจ้าของเว็บไซต์รายเดียว ไม่มีสิทธิ์ sudo และไม่มีเส้นทางไปยังลูกค้ารายอื่น แบ็กดอร์จึงรันในสิทธิ์ของผู้ใช้เว็บไซต์ที่ไม่มีสิทธิ์พิเศษและเข้าถึงอะไรนอกร้านนั้นไม่ได้ บริษัทยืนยันว่าไม่มีการเคลื่อนที่ข้ามระบบและไม่มีเว็บไซต์อื่นบนแพลตฟอร์มได้รับผลกระทบ ทั้งสองร้านถูกควบคุมสถานการณ์ได้ในวันเดียวกัน ราว 11 และ 14 ชั่วโมงหลังการติดต่อครั้งแรกตามลำดับ

คำแนะนำ

• ปิดการใช้งาน GraphQL ชั่วคราวตามคำแนะนำของ Sansec หากหน้าร้านไม่ได้เป็นแบบ headless หรือ progressive web app ซึ่งจำเป็นต้องใช้
• เพิ่ม proc_open เข้าไปใน disable_functions ของ PHP และเมานต์ /tmp, /var/tmp และ /dev/shm ด้วยตัวเลือก noexec เพื่อไม่ให้ไบนารีที่ดาวน์โหลดมารันได้ โดย Disrex จัดสองอย่างนี้ไว้เหนือกว่ากฎทุกข้อในที่เก็บของตัวเอง เพราะไม่ต้องพึ่งความรู้เรื่องห่วงโซ่การโจมตี
• ค้นหาร่องรอยทั้งใน var/report/ และ var/log/system.log โดยจับที่รูปทรงของเฮดเดอร์กระตุ้นมากกว่าสตริงตรงตัว เนื่องจากเครื่องหมายเปลี่ยนรูปภายในวันเดียว
• ตรวจกระบวนการที่ใช้ชื่อในวงเล็บเหลี่ยมแบบเธรดเคอร์เนลแต่เจ้าของไม่ใช่ root และมีหน่วยความจำ resident จริง พร้อมแฮชไบนารีจาก /proc/<pid>/exe ควบคู่กับไฟล์บนดิสก์
• ขยายขอบเขตการสแกนให้ครอบคลุมโฮมไดเรกทอรีของบัญชี ไม่ใช่แค่ document root ของเว็บไซต์
• หากพบว่าถูกเจาะแล้ว ให้ทำตามลำดับที่ Disrex วางไว้คือเก็บหลักฐานก่อน ลบรายการ cron ก่อนฆ่ากระบวนการเพราะกระบวนการจะเขียน cron กลับ ห้ามรีบูตเพราะสำเนาใน /proc อาจเป็นไบนารีชิ้นสุดท้ายที่เหลือ และห้ามรัน composer install เพื่อทำความสะอาดเพราะจะทับ timestamp ที่บอกว่ามีอะไรถูกแตะบ้าง
• หลังทำความสะอาด ให้ล้างที่เก็บเซสชันเนื่องจากแบ็กดอร์อ่านข้อมูลจากตรงนั้น และหมุน crypt/key ใน app/etc/env.php รวมถึงรหัสผ่านผู้ดูแลระบบทุกบัญชี กุญแจ API ของผู้ให้บริการชำระเงินทุกราย และข้อมูลรับรองของระบบเชื่อมต่ออื่น ๆ ในไฟล์นั้น
• เฝ้าระวังอีเมล “Payment Transaction Failed Reminder” ที่ผิดปกติ โดยเฉพาะฉบับที่มีแท็ก {{var ...}} ดิบ ที่อยู่โดเมน .invalid หรือยอดรวมเป็นศูนย์ ซึ่งเป็นสัญญาณเตือนที่ไม่ต้องใช้เครื่องมือใดเลย
• สำหรับแพตช์ที่ไม่เป็นทางการจาก Disrex, ProxiBlue และ Graycore ให้ประเมินก่อนใช้ โดย Disrex เตือนว่าแพตช์ของตนกับของ ProxiBlue เป็นตัวแก้เดียวกันและห้ามใช้ซ้อนกัน ส่วน Graycore ระบุเองว่าสิ่งที่ทำคือการเสริมความแข็งแรง ไม่ใช่การแก้ไข และเส้นทางอื่นของช่องโหว่ยังเปิดอยู่ นอกจากนี้การแก้ไฟล์ ClassesScanner.php จะทำให้หน้าจอผู้ดูแลระบบของโมดูล mageplaza/module-admin-permissions ใช้งานไม่ได้ จึงต้องตรวจไดเรกทอรี vendor ก่อน

Indicators of Compromise (IoCs)

ตัวบ่งชี้ด้านล่างมาจาก Sansec และรายการของ Disrex โดยโดเมนและหมายเลขไอพียังคงรูปแบบ defang ตามต้นฉบับ

ข้อควรระวังคือการบล็อกเฉพาะไอพีของผู้โจมตีรายเดียวที่ระบุในประกาศของ Sansec จะหยุดทราฟฟิกได้ไม่ถึงหนึ่งในสี่ของที่ Disrex พบ เนื่องจาก Disrex บันทึกที่อยู่ต้นทางที่ไม่ซ้ำกันได้ 26 รายการจากล็อก nginx ของร้านทั้งสอง โดยมี 2 รายการเป็นโครงสร้างพื้นฐานโฮสติงที่ยิงเป็นจำนวนมาก และที่เหลือเป็นพูล residential proxy ที่ยิงรายละ 2 ถึง 6 คำร้องขอ

แหล่งอ้างอิง

• Unpatched Magento and Adobe Commerce Zero-Day Exploited to Backdoor Online Stores — The Hacker News
• StyleSmuggler — Sansec Research
• stylesmuggler-mitigation — Disrex Group (GitHub)
• Adobe Commerce security bulletins