สรุปสั้น

Drupal Commerce Core คือ โมดูลที่เปลี่ยนเว็บไซต์ Drupal ให้เป็นร้านค้าออนไลน์ มีทั้งตะกร้าสินค้า หน้าชำระเงิน และ API สำหรับแอปแยกส่วน เมื่อวันที่ 29 ตุลาคม 2569 ทีมความปลอดภัยของ Drupal ประกาศว่าช่องโหว่ CVE-2026-118539 ในโมดูลนี้ ซึ่งจัดระดับ “Highly Critical” กำลังถูกโจมตีจริง สาเหตุ คือ โมดูลไม่ป้องกันบาง route และบางฟิลด์ของข้อมูลมากพอ ผู้โจมตีจึงข้ามการตรวจสิทธิ์ได้ และ Drupal ระบุว่าอาจกระทบผู้ขายทางการเงิน ช่องโหว่กระทบเวอร์ชันก่อน 2.41 และ 3.0.0 ถึง 3.3.13 แต่ Drupal ไม่เผยว่าการโจมตีเป็นแบบไหนหรือกว้างแค่ไหน

อีกด้านหนึ่ง PHP2Shell ช่องโหว่วิกฤต 2 ตัวในตัวภาษา PHP ที่ทั่วโลกเฝ้าระวังอยู่ ก็ยังถูกพยายามโจมตีต่อเนื่อง แต่บริษัท Wiz พบว่าการเปลี่ยน PoC สาธารณะเป็นเครื่องมือที่ได้ผลเสถียรยังไม่ง่าย เพราะความต่างของ build และการตั้งค่าหน่วยความจำของ PHP ผู้ดูแลร้านค้าที่ใช้ Drupal ควรอัปเกรด Commerce Core ทันที และตรวจคำสั่งซื้อหรือราคาที่ผิดปกติย้อนหลัง

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

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 30 ตุลาคม 2569 ว่า Drupal ออกประกาศ SA-CONTRIB-2026-254 ยอมรับว่าช่องโหว่ถูกใช้โจมตี “ในวงกว้าง” แต่ไม่ได้ให้รายละเอียดเพิ่มเติม ช่องโหว่ยังไม่มีคะแนน CVSS กำกับ ผู้รายงาน คือ นาย Dan Puccetti นาย Marcus Johansson และนาย Robert Snyder ทางแก้ คือ อัปเกรดสาย 3.x เป็น Commerce Core 3.3.13 และสายเก่าเป็น 8.x-2.41 ตามที่ Drupal ระบุ

ในช่วงเดียวกัน Wiz บริษัทความปลอดภัยคลาวด์ในเครือ Google อัปเดตสถานการณ์ PHP2Shell (CVE-2026-109618 และ CVE-2026-109619 คะแนน CVSS 9.2 ทั้งคู่) ว่า ณ วันที่ 25 ตุลาคม สัดส่วนองค์กรที่ได้รับผลกระทบอย่างมีนัยสำคัญลดลงเหลือ 52.1% Wiz เห็นกิจกรรม 2 แบบ แบบแรกเป็นความพยายามใช้กลไก exploit PHP2Shell ที่ตรงกับ PoC สาธารณะ แบบที่สองเป็นเครื่องมือที่ตั้งชื่อตาม PHP2Shell แต่ไม่ได้ใช้ช่องโหว่นี้จริง กลับอาศัย session poisoning และช่องโหว่ local file inclusion (LFI) ของแอปแทน (ภูมิหลัง PHP2Shell อ่านได้ที่ 2026/10/215 และกรณีถูกนำไปเจาะไฟร์วอลล์ใน 2026/10/326 )

ข้อจำกัดของหลักฐาน คือ Drupal ไม่ได้ระบุว่า route หรือฟิลด์ใดที่เปิดช่อง และไม่ได้บอกว่าความเสียหายทางการเงินที่อาจเกิดเป็นลักษณะใด ส่วนตัวเลขของ Wiz สะท้อนเฉพาะลูกค้าที่ Wiz มองเห็น

รายละเอียดช่องโหว่

CVE-2026-118539 สาเหตุ — เป็นช่องโหว่ประเภท missing authorization คือ ระบบไม่ตรวจว่าผู้ร้องขอมีสิทธิ์ทำสิ่งนั้นหรือไม่ Drupal อธิบายว่าโมดูลไม่ป้องกันบาง route (เส้นทาง URL หรือ API) และบางฟิลด์ของ entity (ข้อมูลอย่างคำสั่งซื้อหรือรายการสินค้า) มากพอ ผู้โจมตีจึงเข้าถึงหรือแก้ข้อมูลที่ไม่ควรเข้าถึงได้

เงื่อนไขและผลลัพธ์ — กระทบ Commerce Core เวอร์ชัน 0.0.0 ถึงก่อน 2.41 และ 3.0.0 ถึงก่อน 3.3.13 ร้านค้าที่เปิดใช้งานผ่านหน้าชำระเงินในตัวหรือผ่าน API แบบ decoupled ล้วนเกี่ยวข้อง Drupal ระบุผลลัพธ์ไว้กว้าง ๆ ว่าการข้ามสิทธิ์ “อาจกระทบทางการเงินต่อผู้ขาย” เช่น อาจเกิดคำสั่งซื้อหรือข้อมูลราคาที่ผิดไปจากที่ร้านกำหนด แม้ Drupal จะยังไม่ยืนยันรูปแบบที่ถูกใช้จริง

PHP2Shell ทำไมยังยิงยาก — นักวิจัยของ Wiz ระบุว่าการทำให้หน่วยความจำหมด (memory exhaustion) อย่างเดียวไม่พอให้ห่วงโซ่ exploit จบ เพราะความต่างของ build ของ PHP ค่า memory limit และพฤติกรรมของ worker ทำให้ขั้นถัดไปล้มได้ ผู้โจมตีแบบหว่านแหจึงยังต้องพัฒนา PoC สาธารณะให้เป็นเครื่องมือที่เสถียรเอง

ผลกระทบ

กลุ่มที่เสี่ยงโดยตรง คือ ร้านค้าออนไลน์และระบบขายบริการที่สร้างบน Drupal Commerce ซึ่งยังไม่อัปเกรด การข้ามสิทธิ์ในระบบที่จัดการคำสั่งซื้อและการชำระเงินแปลว่าความเสียหายอาจเป็นเงินจริงโดยตรง ไม่ใช่แค่ข้อมูลรั่ว และเมื่อมีการโจมตีจริงแล้ว ร้านที่ช้าจะเสี่ยงมากขึ้นทุกวัน

สำหรับ PHP2Shell ข้อมูลของ Wiz ช่วยปรับภาพความเสี่ยงให้สมจริงขึ้น แต่ไม่ใช่เหตุผลให้ชะลอแพตช์ เพราะเครือข่ายที่ใช้ build หรือการตั้งค่าตรงกับ PoC ยังโดนได้ และมีกรณีจริงที่ถูกใช้เจาะลึกถึง Active Directory แล้ว

คำแนะนำ

  • อัปเกรด Drupal Commerce Core เป็น 3.3.13 (สาย 3.x) หรือ 8.x-2.41 (สายเก่า) ทันทีตามประกาศ SA-CONTRIB-2026-254
  • ตรวจคำสั่งซื้อ ราคา ส่วนลด และสถานะการชำระเงินย้อนหลังหาความผิดปกติ เช่น คำสั่งซื้อที่ยอดไม่ตรงกับราคาสินค้า หรือคำสั่งซื้อที่ถูกแก้โดยผู้ใช้ไม่มีสิทธิ์
  • ตรวจล็อกเว็บหาคำขอจำนวนมากไปยัง route ของ Commerce และ API จากผู้ใช้ที่ไม่ได้ล็อกอิน
  • อัปเดต PHP เป็นเวอร์ชันที่แก้ PHP2Shell แล้วบนทุกเซิร์ฟเวอร์ แม้ข้อมูลของ Wiz จะชี้ว่ายิงให้สำเร็จยาก และตรวจหาช่องโหว่ LFI ในแอปที่เครื่องมือแอบอ้างชื่อ PHP2Shell ใช้แทน

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